On Sun, Jul 06, 2008 at 06:58:10PM +0200, Ingo Molnar wrote: > > * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815 > > > Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0 > > > Submitter : Alexey Dobriyan <adobriyan@xxxxxxxxx> > > > Date : 2008-05-27 09:23 (41 days old) > > > References : http://lkml.org/lkml/2008/5/27/9 > > > http://lkml.org/lkml/2008/6/14/87 > > > Handled-By : Oleg Nesterov <oleg@xxxxxxxxxx> > > > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > > > Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> > > > Patch : http://lkml.org/lkml/2008/5/28/16 > > > > This one is the same thing that is reported as unresolved, and no, I > > don't think that existing patch was ever really tested to fix > > anything. Paul? > > > > I suspect SRCU will need to be simply marked BROKEN for now, because > > nobody knows what the problem Alexey sees is. Apparently it's been > > seen by a few other people too. > > I'm not sure it's directly related to SRCU - it can change timings and > freeing patterns enough to tickle other bugs. Since Alexey Dobriyan has > reported it - are perhaps namespaces in use during this stress-test? > Maybe it's some namespaces related bug that is more easily reproduced > under SRCU - namespaces is not a commonly tested feature. I have CONFIG_NAMESPACES=y. Should I also set one or more of CONFIG_UTS_NS, CONFIG_IPC_NS, CONFIG_USER_NS, or CONFIG_PID_NS? What the heck, I will just set them all and pound away on kernbenchx170 and rcutorture. Thanx, Paul > Also, i've been running rcutorture stress-tests on a number of > test-systems ever since this got reported (and they are running > currently as well) and cannot see it - neither could Paul reproduce it. > > ( and Paul is very good in producing RCU related problems - he's > triggered and fixed many RCU related problems that no-one else saw > before. ) > > Ingo -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
