lkml.org 
[lkml]   [1998]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:1.051 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site