linux-kernel - Re: [PATCH printk v1 11/13] printk: reimplement console

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: <YhdBWBxL15j4Bq3h@alley>
Date:   Thu, 24 Feb 2022 09:27:04 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH printk v1 11/13] printk: reimplement console_lock for
 proper kthread support

On Wed 2022-02-23 18:26:54, John Ogness wrote:
> On 2022-02-22, Petr Mladek <pmladek@...e.com> wrote:
> >> With a mutex there is an owner. When another task tries to lock a
> >> mutex, the scheduler knows which task must be scheduled to resolve
> >> this true lock contention. (There are also other benefits relating to
> >> priority inheritance, but I chose not to mention this.)
> >
> > This sounds interesting. Does scheduler wake up or prioritize
> > mutex owners?
> 
> Sorry, the only example of this is priority inheritance. But for
> non-PREEMPT_RT there is no priority inheritance. The lock would need to
> be an rtmutex for this ability, which probably doesn't make sense for
> printk.

Good to know.

> The v2 commit message will focus on:
> 
> - the motivation for per-console locks is parallel printing
> 
> - explain about how disabling preemption is only necessary for direct
>   printing via printk() because the caller may be holding
>   system-critical and/or timing-sensitive locks (and also to allow the
>   console owner/waiter logic to work correctly)
> 
> - correctly clarifying why the various types
>   (semaphore/mutex/flag/atomic) were chosen to implement the printing
>   sychronization between atomic-direct, non-atomic-direct, and kthreads
>   (and I will explicitly remind the audience that mutex_trylock() cannot
>   be used in atomic context)

Sounds great.

Thanks a lot for the hard work. It is very appreciated.

Best Regards,
Petr