linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Helge Deller <deller@gmx.de>
Cc: John Ogness <john.ogness@linutronix.de>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: [PATCH printk-rework 08/14] printk: add syslog_lock
Date: Mon, 22 Feb 2021 17:28:26 +0100	[thread overview]
Message-ID: <YDPbqhi6wVwGa5rF@alley> (raw)
In-Reply-To: <db43de06-3183-7401-30f2-0e9302cc48e0@gmx.de>

On Sun 2021-02-21 22:39:42, Helge Deller wrote:
> On 2/19/21 5:33 PM, John Ogness wrote:
> > Added CC: linux-parisc@vger.kernel.org
> > 
> > On 2021-02-19, John Ogness <john.ogness@linutronix.de> wrote:
> > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > index 20c21a25143d..401df370832b 100644
> > > > > --- a/kernel/printk/printk.c
> > > > > +++ b/kernel/printk/printk.c
> > > > > +/* Return a consistent copy of @syslog_seq. */
> > > > > +static u64 read_syslog_seq_irq(void)
> > > > > +{
> > > > > +	u64 seq;
> > > > > +
> > > > > +	raw_spin_lock_irq(&syslog_lock);
> > > > > +	seq = syslog_seq;
> > > > > +	raw_spin_unlock_irq(&syslog_lock);
> > > > 
> > > > Is there any particular reason to disable interrupts here?
> > > > 
> > > > It would make sense only when the lock could be taken in IRQ
> > > > context. Then we would need to always disable interrupts when
> > > > the lock is taken. And if it is taken in IRQ context, we would
> > > > need to safe flags.
> > > 
> > > All other instances of locking @syslog_lock are done with interrupts
> > > disabled. And we have:
> > > 
> > > register_console()
> > >    logbuf_lock_irqsave()
> > >      raw_spin_lock(&syslog_lock)
> > > 
> > > I suppose I need to go through all the console drivers to see if any
> > > register in interrupt context. If not, that logbuf_lock_irqsave()
> > > should be replaced with logbuf_lock_irq(). And then locking
> > > @syslog_lock will not need to disable interrupts.
> > 
> > I found a possible call chain in interrupt context. From arch/parisc
> > there is the interrupt handler:
> > 
> > handle_interruption(code=1) /* High-priority machine check (HPMC) */
> >    pdc_console_restart()
> >      pdc_console_init_force()
> >        register_console()
> > 
> > All other register_console() calls in the kernel are either during init
> > (within __init sections and probe functions) or are clearly not in
> > interrupt context (using mutex, kzalloc, spin_lock_irq, etc).
> > 
> > I am not familiar with parisc, but I am assuming handle_interruption()
> > is always called with interrupts disabled (unless the HPMC interrupt is
> > somehow an exception).
> 
> Yes, handle_interruption() is the irq handler, running with irqs off.
> HPMC is the crash handler - it's called when the kernel will stop
> anyway. pdc_console is a very basic firmware console which prints
> the last messages before the machine halts on fatal errors.
> So, this code it's not the typical use case....

Thanks for information.

Is this code supposed to work only during early boot or anytime,
please?

Note that it is not safe because register_console() takes
console_lock() which is a sleeping lock.

That said, we are going to rework the console handling a lot. We are
trying to remove as many locks from the printk path as possible.
I guess that the list of consoles will be synchronized using
rcu at the end. But it is still a long way to go.

Best Regards,
Petr

  reply	other threads:[~2021-02-22 16:32 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18  8:18 [PATCH printk-rework 00/14] printk: remove logbuf_lock John Ogness
2021-02-18  8:18 ` [PATCH printk-rework 01/14] printk: limit second loop of syslog_print_all John Ogness
2021-02-18 16:15   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 02/14] printk: kmsg_dump: remove unused fields John Ogness
2021-02-18 16:18   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 03/14] printk: refactor kmsg_dump_get_buffer() John Ogness
2021-02-18  8:18 ` [PATCH printk-rework 04/14] printk: consolidate kmsg_dump_get_buffer/syslog_print_all code John Ogness
2021-02-19 12:28   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 05/14] printk: introduce CONSOLE_LOG_MAX for improved multi-line support John Ogness
2021-02-19 12:44   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 06/14] printk: use seqcount_latch for clear_seq John Ogness
2021-02-18  8:18 ` [PATCH printk-rework 07/14] printk: use atomic64_t for devkmsg_user.seq John Ogness
2021-02-19 12:59   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 08/14] printk: add syslog_lock John Ogness
2021-02-19 13:30   ` Petr Mladek
2021-02-19 14:45     ` John Ogness
2021-02-19 16:33       ` John Ogness
2021-02-21 21:39         ` Helge Deller
2021-02-22 16:28           ` Petr Mladek [this message]
2021-02-23 12:22             ` Helge Deller
2021-02-23 14:23               ` Petr Mladek
2021-02-23 14:45                 ` Helge Deller
2021-02-22 16:05       ` Petr Mladek
2021-02-22 16:43         ` John Ogness
2021-02-23 14:38           ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 09/14] printk: introduce a kmsg_dump iterator John Ogness
2021-02-19 15:56   ` Petr Mladek
2021-02-19 16:50   ` Michael Kelley
2021-02-19 17:57   ` synchronization model: was: " Petr Mladek
2021-02-24 12:27     ` John Ogness
2021-02-24 15:40       ` John Ogness
2021-02-25 12:33       ` Petr Mladek
2021-02-26  8:36         ` John Ogness
2021-02-26  9:48           ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 10/14] um: synchronize kmsg_dumper John Ogness
2021-02-18  8:18 ` [PATCH printk-rework 11/14] printk: remove logbuf_lock John Ogness
2021-02-23 11:44   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 12/14] printk: kmsg_dump: remove _nolock() variants John Ogness
2021-02-23 11:51   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 13/14] printk: kmsg_dump: use kmsg_dump_rewind John Ogness
2021-02-23 11:53   ` Petr Mladek
2021-02-18  8:18 ` [PATCH printk-rework 14/14] printk: console: remove unnecessary safe buffer usage John Ogness
2021-02-23 12:55   ` Petr Mladek

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=YDPbqhi6wVwGa5rF@alley \
    --to=pmladek@suse.com \
    --cc=deller@gmx.de \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).