Cc: Matthew Wilcox <matthew@...>, <Valdis.Kletnieks@...>, Willy Tarreau <w@...>, Adrian Bunk <bunk@...>, James Bottomley <James.Bottomley@...>, Ingo Molnar <mingo@...>, Peter Osterlund <petero2@...>, <linux-kernel@...>, Andrew Morton <akpm@...>, Al Viro <viro@...>
Indeed. If it's some race condition, or dependent on memory pressure at
just the right time, or a use-after-free that corrupts some memory that
normally nobody will even notice (it's freed, after all, and not
necessarily re-allocated), reproduction can be really very hard.
It's happily not exactly *common*, but it's certainly not unheard of
either, when you need to run some specific workload for hours to trigger
the bug - and then when it doesn't happen, you have to ask yourself: "was
I just lunky, punk?"
Some of those things also go away magically between kernel versions or
subtly different configurations. A use-after-free problem might be obvious
in one config, but then another configuration might change the size of a
structure, and suddenly the two kmalloc's that used to be in the same slab
(and made the problem more visible) end up in different slabs, and now you
suddenly cannot reproduce it with that particular load at all any more!
These things *are* fairly rare (most bugs by _far_ are of the trivial
stupid kind), but some of those things can stay around for a long time,
and it can take months of different people reporting similar problems
until somebody finally puts two and two together and sees the pattern.
When we get a good bug-reporter that is willing and able to reproduce and
test kernels, that's wonderful, but when we get some "background noise" of
bad bug-reports, that's usually good too - even if it's good only in the
long run (ie sometimes we just have to accept that the bug-report didn't
contain enough information for us to really do anythign about it, and just
let it be - and hope that future events will clarify things)
Linus
--
