Re: What exactly are the issues with 2.6.0-test10 preempt?

[Linus Torvalds <torvalds@osdl.org>]

On Mon, 24 Nov 2003, Bradley Chapman wrote:
>
> Indeed. Do the same subsystems usually show the memory corruption issue with
> preempt active, or does it just pop up all over the place, unpredictably?

There are a few reports of "predictable" memory corruption, in the sense
that the same people tend to see the same kinds of oopses _without_ any
other signs of memory corruption (ie no random SIGSEGV's in user space
etc).

There's the magic slab corruption thing, there's a strange thread data
corruption (one person), and there's the sunrpc timer bug. All are
"impossible" bugs that would indicate a small amount of data corruption in
some core data structure.

They are hard to trigger, which makes me personally suspect some
user-after-free thing, where the bug happens only when somebody else
allocates (and uses) the entry immediately afterwards (so that the old
user overwrites stuff that just got initialized for the new user).

It's not likely to be a wild pointer: those tend to corrupt random memory,
and that in turn is a lot more likely to result in _user_ corruptions
(causing SIGSEGV's, corrupted files that magically become ok again when
re-read, etc), since 99% of all memory tends to be non-kernel data
structures.

The PAGEFREE debug option works well for page allocations, but the slab
cache is not very amenable to it. For slab debugging, it would be
wonderful if somebody made a _truly_ debugging slab allocator that didn't
use the slab cache at all, but used the page allocator (and screw the fact
that you use too much memory ;) instead.

(Sadly, some slab users actually use that stupid "initialize" crap. We
should rip it out: it's a disaster from a data cache standpoint too, since
it tends to do all the wrong things there, even though it's literally
meant to help).

		Linus