On Wednesday, July 27, 2011, Andrew Morton wrote: > On Wed, 27 Jul 2011 00:24:11 +0200 > "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: > > > > Hi Rafael, > > > > > > I had a problem with the kernel stopping the machine forever because I got an > > > oops while tasks were frozen. It seems to me that we should thaw when this > > > happens. How about this approach? > > > > Well, we do something like this already for the OOM killer (see > > oom_killer_disable() and friends), so I think it would be better to > > simply extend/modify that mechanism instead of adding a new one > > doing almost exactly the same thing. > > > > I have no complaints about adding thaw_in_oops(), though, so long as > > Andrew thinks it makes sense. > > mm... The patch as proposed is very simple, direct, explicit. I > suspect that trying to embed this operation within some other one would > end up producing a less clear result. Sometimes we do exceptional and > weird things, and leaving the code exceptional and weird-looking is > better than hiding it in some framework, if you follow what I mean. My point is that instead of using the oom_killer_disabled variable in page_alloc.c, we could use a oom_killer_disabled() function returning the value of the new tasks_are_frozen variable. Then, oom_killer_disable/enable() won't be necessary any more. > It does need some code comments to explain to people what it's doing > and more importantly why it's doing it. Also, something which doesn't > break the build when CONFIG_FREEZER=n would be nice. Right. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
