On Mon, Nov 02, 2015 at 04:01:37PM +0100, Michal Hocko wrote: ... > which is perfectly suited for the stable backport, OOM sysrq resp. any > sysrq which runs from the WQ context should be as robust as possible and > shouldn't rely on all the code running from WQ context to issue a sleep > to get unstuck. So I definitely support something like this patch. Well, sysrq wouldn't run successfully either on a cpu which is busy looping with preemption off. I don't think this calls for a new flag to modify workqueue behavior especially given that missing such flag would lead to the same kind of lockup. It's a shitty solution. If the possibility of sysrq getting stuck behind concurrency management is an issue, queueing them on an unbound or highpri workqueue should be good enough. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>