From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH printk v2 04/18] printk: nbcon: Introduce printing kthreads
Date: Wed, 12 Jun 2024 10:57:11 +0206 [thread overview]
Message-ID: <87sexipmrk.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <ZmhkVAC_3FMohrEr@pathway.suse.cz>
On 2024-06-11, Petr Mladek <pmladek@suse.com> wrote:
>> During normal operation, the inner safety (console context) will never
>> be contended. That really only exists to synchronize the atomic case.
>
> I see. For example, the spin_lock_irqsave() in __uart_port_lock_irqsave()
> will be sleeping lock in RT => preserving RT guarantees. And it will
> make sure that the inner nbcon_context_try_acquire() would never
> have to spin => never break the RT guarantees.
>
> It makes perfect sense. Do I get it correctly?
Yes.
> Well, I would still like to describe the role of device_lock()
> for write_kthread(). It would help even me to create a better
> mental model ;-)
>
> What about the following?
>
> <proposal-2>
> /**
> * @write_thread:
> *
> * NBCON callback to write out text in task context.
> *
> * This callback must be called only in task context with both
> * device_lock() and the nbcon console acquired with
> * NBCON_PRIO_NORMAL.
> *
> * The same rules for console ownership verification and unsafe
> * sections handling applies as with write_atomic().
> *
> * The console ownership handling is necessary for synchronization
> * against write_atomic() which is synchronized only via the context.
> *
> * The device_lock() provides the primary serialization for operations
> * on the device. It might be as relaxed (mutex)[*] or as tight
> * (disabled preemption and interrupts) as needed. It allows
> * the kthread to operate in the least restrictive mode[**].
> *
> * [*] Standalone nbcon_context_try_acquire() is not safe with
> * the preemption enabled, see nbcon_owner_matches(). But it
> * can be safe when always called in the preemptive context
> * under the device_lock().
> *
> * [**] The device_lock() makes sure that nbcon_context_try_acquire()
> * would never need to spin which is important especially with
> * PREEMPT_RT.
> */
> </proposal-2>
OK. I will use this.
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -3995,6 +3995,8 @@ static int unregister_console_locked(struct console *console)
>> if (res > 0)
>> return 0;
>>
>> + __pr_flush(console, 1000, true);
>> +
>> /* Disable it unconditionally */
>> console_srcu_write_flags(console, console->flags & ~CON_ENABLED);
>
> Makes sense.
>
> And it actually means that it is too late to flush messages
> when kthread_should_stop() returns true. So, it does not matter if
> we check it in the while(backlog) loop or not. Well, it might be
> worth a comment in the code.
I will add a comment for this.
>> The thread failing to start is a serious issue. Particularly for
>> PREEMPT_RT.
>
> I agree.
>
>> Probably it should be something like:
>>
>> if (WARN_ON(IS_ERR(kt))) {
>
> Might make sense.
I will add this for v2.
> Honestly, if the system is not able to start the kthread then
> it is probably useless anyway. I would prefer if printk keeps working
> so that people know what is going on ;-)
OK. For v2 I will change it to fallback to the legacy printing for those
consoles that do not have a kthread.
> After all, I would add two comments, like these:
>
> <proposal-2>
> /*
> * Any access to the console device is serialized either by
> * device_lock() or console context or both.
> */
> kt = kthread_run(nbcon_kthread_func, con, "pr/%s%d", con->name,
> con->index);
> [...]
>
> /*
> * Some users check con->kthread to decide whether to flush
> * the messages directly using con->write_atomic(). But they
> * do so only when the console is already in @console_list.
> */
I do not understand how @console_list is related to racing between
non-thread and thread. kthreads are not only created during
registration. For example, they can be created much later when the last
boot console unregisters.
I am OK with the first comment of this proposal. I do not understand the
second comment.
> con->kthread = kt;
> </proposal-2>
John
next prev parent reply other threads:[~2024-06-12 8:51 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 23:24 [PATCH printk v2 00/18] add threaded printing + the rest John Ogness
2024-06-03 23:24 ` [PATCH printk v2 01/18] printk: Add function to replay kernel log on consoles John Ogness
2024-06-03 23:24 ` [PATCH printk v2 02/18] tty/sysrq: Replay kernel log messages on consoles via sysrq John Ogness
2024-06-03 23:24 ` [PATCH printk v2 03/18] printk: Rename console_replay_all() and update context John Ogness
2024-06-03 23:24 ` [PATCH printk v2 04/18] printk: nbcon: Introduce printing kthreads John Ogness
2024-06-07 13:17 ` Petr Mladek
2024-06-10 12:09 ` John Ogness
2024-06-11 14:51 ` Petr Mladek
2024-06-12 8:51 ` John Ogness [this message]
2024-06-12 9:24 ` Petr Mladek
2024-06-12 11:18 ` John Ogness
2024-06-12 11:33 ` Petr Mladek
2024-06-13 15:21 ` John Ogness
2024-06-14 7:40 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 05/18] printk: Atomic print in printk context on shutdown John Ogness
2024-06-13 12:32 ` Petr Mladek
2024-06-13 12:44 ` atomic_flush vs boot consoles - was: " Petr Mladek
2024-06-13 12:52 ` [PATCH] printk: nbcon_atomic_flush_pending() is safe only when there is no boot console Petr Mladek
2024-06-13 15:10 ` Petr Mladek
2024-06-25 20:53 ` John Ogness
2024-06-28 15:51 ` how to flush consoles: was: " Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 06/18] printk: nbcon: Add context to console_is_usable() John Ogness
2024-06-13 13:22 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 07/18] printk: nbcon: Add printer thread wakeups John Ogness
2024-06-13 15:08 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 08/18] printk: nbcon: Stop threads on shutdown/reboot John Ogness
2024-06-17 15:21 ` Petr Mladek
2024-06-25 19:56 ` John Ogness
2024-06-26 12:14 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 09/18] printk: nbcon: Start printing threads John Ogness
2024-06-18 15:34 ` Petr Mladek
2024-06-19 15:13 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 10/18] printk: Provide helper for message prepending John Ogness
2024-06-20 10:28 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 11/18] printk: nbcon: Show replay message on takeover John Ogness
2024-06-20 13:02 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 12/18] printk: Add kthread for all legacy consoles John Ogness
2024-06-28 11:46 ` Petr Mladek
2024-06-28 12:22 ` John Ogness
2024-06-28 13:32 ` Petr Mladek
2024-06-28 14:11 ` John Ogness
2024-06-28 15:56 ` John Ogness
2024-07-01 15:33 ` Petr Mladek
2024-07-01 21:01 ` John Ogness
2024-07-02 9:11 ` Petr Mladek
2024-07-01 14:50 ` Petr Mladek
2024-07-02 9:30 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 13/18] proc: consoles: Add notation to c_start/c_stop John Ogness
2024-07-01 15:43 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 14/18] proc: Add nbcon support for /proc/consoles John Ogness
2024-07-01 15:47 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 15/18] tty: sysfs: Add nbcon support for 'active' John Ogness
2024-06-04 11:48 ` Greg Kroah-Hartman
2024-07-01 15:50 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 16/18] printk: Provide threadprintk boot argument John Ogness
2024-07-02 12:12 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 17/18] printk: Avoid false positive lockdep report for legacy printing John Ogness
2024-07-02 13:26 ` Petr Mladek
2024-06-03 23:24 ` [PATCH printk v2 18/18] printk: nbcon: Add function for printers to reacquire ownership John Ogness
2024-07-02 14:31 ` Petr Mladek
2024-06-04 13:31 ` [PATCH printk v2 00/18] add threaded printing + the rest Juri Lelli
2024-06-05 8:09 ` John Ogness
2024-06-05 9:32 ` Juri Lelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sexipmrk.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®