Messages in this thread | | | Date | Wed, 14 Oct 1998 14:42:06 +0000 (/etc/localtime) | From | Rik van Riel <> | Subject | Re: 2.1.125 Show stopper list: Draft |
| |
On Wed, 14 Oct 1998, Andrea Arcangeli wrote: > On Tue, 13 Oct 1998, Rik van Riel wrote: > > >Damnit, Andrea! I have outlined the _theoretical_ > >possibility of it happening _and_ the easy yet > > If the possiblity is theorical it' s also doable in practice and you > are really allowed to use the theory to discover a way to cause my > OOM patch to fail.
"Unfortunately", this is one of those one-in-a-million bugs that are hard to reproduce and that will happen at just the wrong moment...
Like the APIC timing issues and the soundcard fast-DMA-stuff, this is not generally reproducible and hardly ever happens. When it _does_ happen, it strikes badly though...
> According to me the OOM problem of 2.1 is not more an issue and you > can convince me that I am wrong _only_ causing my code to fail. If > my code it' s so obviously buggy and obviously wrong, should be > trivial for you to find _the_ way to reproduce failed allocation.
Your code works in most (probably all) cases, but there are some corner-cases where things might go awry. I pointed out these situations and provided a fix. All you did was ask for a quick&dirty test program showing you the bug (which isn't possible, as I explained) and rudely reject my description of the problem, without ever taking the theoretical aspects of the code into account.
As long as there are some deficiencies with the code, even theoretical ones, it can't be ready for prime-time. The fix I proposed doesn't take _any_ CPU time in normal situations and prevents the bug from happening. There is just no way you can keep opposing this fix without ever giving a good argument against it.
> And btw I _only_ had very good report so far.
I'm sure about that, your patch should work great in almost every machine and I reccoment it to everybody. In most aspects it's better than the current kernel code, and the point I pointed out very unlikely, at least more unlikely than the deadlocks that are in the kernel right now...
> >What is wrong with that approach? > > I don' t agree to add new features to workaround bugs.
It's not a feature, it is a check to make certain we really are out of memory before calling oom(tsk). On 'normal' systems it can happen that a task is oom()ed when there is still free swap left. With your patch the chance of that happening is increased from virtually impossible to just very unlikely, but the chance of the bug manifesting itself _has_ increased with your patch.
Considering the other good things your patch does, that probably is OK; with my fix applied that last nasty bug is removed too, but for some strange reason you keep ignoring my description of the problem.
It almost seems like a bug doesn't exist until you can see it with your own eyes -- this is a completely unacceptable point of view since we are programming code that is to be used by millions of users on thousands of different hardware/load combinations.
When programming for such a wide usage pattern, we just _have_ to take theoretical bugs into account as well... (QED)
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |