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]
Message-ID: <YqcWd16LNnFPRJHg@alley>
Date:   Mon, 13 Jun 2022 12:50:31 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     john.ogness@...utronix.de, linux-kernel@...r.kernel.org,
        frederic@...nel.org
Subject: Re: [BUG] 8e274732115f ("printk: extend console_lock for per-console
 locking")

On Fri 2022-06-10 13:50:38, Paul E. McKenney wrote:
> Hello, John,
> 
> I have started getting rcutorture shutdown-time hangs when running
> against recent mainline, and bisected back to the 8e274732115f ("printk:
> extend console_lock for per-console locking") commit.  These hangs go
> away (or at least their probability drops dramatically) if I build with
> CONFIG_PREEMPTION=n -and- CONFIG_NO_HZ=y (not n!), at least assuming
> that I also boot with "nohz_full=0-N".

This means that the kthreads are probably more often sleeping with
con->lock when the pre-emtion is done by regular ticks.

We might want to wake them if we could call pr_flush().
But we could not do this in the generic panic() path.
It might cause deadlock when panic() is called from
scheduler code.

Pest Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ