Re: [PATCH printk-rework 08/14] printk: add syslog_lock

[John Ogness <john.ogness@linutronix.de>]

On 2021-02-19, Petr Mladek <pmladek@suse.com> 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)

Looking back through history, I found that locking of the "console lock"
in register_console() was changed from spin_lock_irq() to
spin_lock_irqsave() for 2.3.15pre1 [0]. The only reason I can find why
that was done is because sparc64 was regstering its console in a PROM
callback (the comments there: "Pretty sick eh?").

Today sparc64 is setting up the console in init code. 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.

John Ogness

[0] https://github.com/schwabe/davej-history/commit/f91c3404ba16c88cdb33824bf0249c6263cd4465#diff-84036d1e27f4207c783a3b876aef4e45340d30f43b1319bca382f5775a9b14beL348