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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
