On Sat, 2014-05-03 at 16:19 +0200, Nicholas Mc Guire wrote: > On Sat, 03 May 2014, Mike Galbraith wrote: > > > On Sat, 2014-05-03 at 14:31 +0200, Nicholas Mc Guire wrote: > > > On Sat, 03 May 2014, Mike Galbraith wrote: > > > > > > If this is in fact safe, you should be able to move each and every > > > > migrate_disable() to post acquisition. > > > > > > yup > > > > Having just seen working -> brick transition, color me skeptical. > > > > > > I have a virtual nickle that > > > > says your box will have a severe allergic reaction to such a patch. > > > > > > > Actually that is what the pushdowns in the read_lock/write_lock api did and > > > I did not notice any of the systems having problems with that. > > > > If you had tested hotplug, you would have met the deadlock, and would > > have verified that the change to read_lock() was the culprit instead of > > me doing that. Steven also verified that. You too can flip back and > > forth, drive boxen into the wall as many times as it take to convince > > yourself that that change really really did induce the breakage. > > > > I did not test hotplug - I did try and understand the code to Not testing hotplug was obviously a mistake given what you were changing. Nor is that a tiny change, it's a glaringly huge order change... for read_lock(), with no order change to write_lock(). Things that make ya go hmmm. > verify the assumptions - but before looking at details of some code > path (which in my opinion has a few problems of its own) I think it > would be best to clarify first if the assumptions made for the > migrate pushdown patches is right or not - if it is not there is no point > in discussing individual code paths but then that patch set simply needs to > go out, if the assumptions are right then we can discuss where the fix is > needed. If your assumptions were correct, there would have been no breakage. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
