Re: Regression in v4.19.106 breaking waking up of readers of /proc/kmsg and /dev/kmsg

[Sergey Senozhatsky]

On (20/02/28 15:53), Theodore Y. Ts'o wrote:
> > So, I would still prefer to _revert_ the commit 15341b1dd409749f
> > ("char/random: silence a lockdep splat with printk()"). It calmed
> > down lockdep report. The real life danger is dubious. The warning
> > is printed early when the system is running on single CPU where
> > it could not race.
> 
> I'm wondering now if we should revert this commit before 5.6 comes out
> (it landed in 5.6-rc1).  "Is much less likely to happen given the
> other random initialization patches" is not the same as "guaranteed
> not to happen".
> 
> What do folks think?

Well, my 5 cents, there is nothing that prevents "too-early"
printk_deferred() calls in the future. From that POV I'd probably
prefer to "forbid" printk_deffered() to touch per-CPU deferred
machinery until it's not "too early" anymore. Similar to what we
do in printk_safe::queue_flush_work().

	-ss