linux-kernel - Re: [PATCH v2] mm/page_isolation: fix a deadlock 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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 8 Oct 2019 09:13:49 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Qian Cai <cai@....pw>, Michal Hocko <mhocko@...nel.org>,
        sergey.senozhatsky.work@...il.com, peterz@...radead.org,
        linux-mm@...ck.org, john.ogness@...utronix.de,
        akpm@...ux-foundation.org, david@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()

On Tue, 8 Oct 2019 10:15:10 +0200
Petr Mladek <pmladek@...e.com> wrote:

> There are basically three possibilities:
> 
> 1. Do crazy exercises with locks all around the kernel to
>    avoid the deadlocks. It is usually not worth it. And
>    it is a "whack a mole" approach.
> 
> 2. Use printk_deferred() in problematic code paths. It is
>    a "whack a mole" approach as well. And we would end up
>    with printk_deferred() used almost everywhere.
> 
> 3. Always deffer the console handling in printk(). This would
>    help also to avoid soft lockups. Several people pushed
>    against this last few years because it might reduce
>    the chance to see the message in case of system crash.
> 
> As I said, there has finally been agreement to always do
> the offload few weeks ago. John Ogness is working on it.
> So we might have the systematic solution for these deadlocks
> rather sooner than later.

Another solution is to add the printk_deferred() in these places that
cause lockdep splats, and when John's work is done, it would be easy to
grep for them and remove them as they would no longer be needed.

This way we don't play whack-a-mole forever (only until we have a
proper solution) and everyone is happy that we no longer have these
false positive or I-don't-care lockdep splats which hide real lockdep
splats because lockdep shuts off as soon as it discovers its first
splat.

-- Steve