linux-kernel - Re: [PATCH -next] mm/hotplug: silence a lockdep splat with printk()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 15 Jan 2020 10:52:53 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Qian Cai <cai@....pw>
Cc:     Michal Hocko <mhocko@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        akpm@...ux-foundation.org, sergey.senozhatsky.work@...il.com,
        rostedt@...dmis.org, peterz@...radead.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] mm/hotplug: silence a lockdep splat with printk()

On Tue 2020-01-14 16:40:49, Qian Cai wrote:
> 
> 
> > On Jan 14, 2020, at 4:02 PM, Michal Hocko <mhocko@...nel.org> 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