On Tue 2020-01-14 16:40:49, Qian Cai wrote: > > > > On Jan 14, 2020, at 4:02 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > Yeah, that was a long discussion with a lot of lockdep false positives. > > I believe I have made it clear that the console code shouldn't depend on > > memory allocation because that is just too fragile. If that is not > > possible for some reason then it has to be mentioned in the changelog. > > I really do not want us to add kludges to the MM code just because of > > printk deficiencies unless that is absolutely inevitable. > > I don’t know how to convince you, but both random number generator > and printk() maintainers agreed to get ride of printk() with > zone->lock held as you can see in the approved commit mentioned I neither acked nor blocked the fix in the random generator. I believe that it was false positive. But the fix was trivial and I did not have any better solution in the pocket. > in this patch description because it is a whac-a-mole to fix other > places. This is misleading. Using printk_deferred() in _warn_unseeded_randomness() is whack-a-mole approach as well. The most realistic real solution is to deffer consoles into kthreads. It is being discussed for years. There is finally an agreement to get this upstream. But the priority is to add lockless ringbuffer first. I could understand that Michal is against hack in -mm code that would just hide a false positive warning. If you really need a solution before the console offload gets upstream then I suggest to do something really simple. For example, disable lockdep around the allocation in console registration code that is proven to produce the false positive chain. Best Regards, Petr
