On 05/02/2014 04:05 PM, Andrew Morton wrote: > On Fri, 2 May 2014 15:09:14 -0700 John Stultz <john.stu...@linaro.org> wrote: > >> Recently, Jiri pointed out a potential deadlock when calling printk >> while holding the timekeeping seqlock. >> >> Annoyingly, the seqlock lockdep enablement doesn't catch this, as >> printk disables lockdep. >> >> When looking for possible solutions, one idea was to use a local buffer >> and defer the printk to later. Ends up there is already similar >> functionality in printk_sched() to avoid similar style deadlocks w/ >> the scheduler. >> >> Thus this patchset (based on next/akpm) renames printk_sched to >> printk_deferred and then moves the affected timekeeping printks to make >> use of it. >> >> There were some points in the discussion between Jan and Peter that >> made it seem that there may still be problems lurking in the console >> layer, and I'm not sure I fully understand their point, so this solution >> may be incomplete. >> >> Additionally, the same issue likely affects any WARN_ONs as well, but >> I wanted to get some thoughts on this approach before trying to remove >> or convert affected WARN_ONS. >> >> Your thoughts and feedback are greatly appreciated! > All look pretty simple and sane to me. printk is a crazy hotspot > lately but this patchset looks like it won't get singed. > > Would "printk_deferred_once" be more logical than > "printk_once_deferred"? Think so. It's (((printk(deferred(once))), > not (((printk(once(deferred))).
Sounds good. Will update the set with this. thanks! -john -- 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/