linux-kernel - Re: [PATCH v2] locking/semaphore: Use wake_q to wake up processes outside lock critical section

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:   Fri, 22 Sep 2023 21:47:04 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Waiman Long <longman@...hat.com>
Cc:     Ingo Molnar <mingo@...hat.com>, Will Deacon <will.deacon@....com>,
        Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] locking/semaphore: Use wake_q to wake up processes
 outside lock critical section

On Fri, Sep 22, 2023 at 02:45:04PM -0400, Waiman Long wrote:

> I believe early_printk should only be used in the non-SMP boot process. The
> use of printk() is frequently used for debugging purpose and the insertion
> of printk at some lock critical section can cause the lockdep splat to come
> out obscuring the debugging process.

By default early_printk is disabled somewhere early, but it has a keep
argument to keep it around.

Anyway, printk() as it exists today is wholly unsuited for debugging.
There are too many contexts where it will flat out not work. When you
use early_print with keep then you can use early_printk() instead of
printk() to debug.

Also, see the patches I pointed John at. Perf would not be what it is
without those patches.

Serial lines and early printk are not optional. That is, I flat out
refuse to develop on machines without them.