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

[Petr Mladek <pmladek@suse.com>]

On Mon 2021-02-22 17:43:56, John Ogness wrote:
> On 2021-02-22, 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.
> >
> > Note that console_lock was a spinlock in 2.3.15.pre1. I see it defined
> > in kernel/printk.c as:
> >
> > spinlock_t console_lock = SPIN_LOCK_UNLOCKED;
> >
> > But it is a sleeping semaphore these days. As a result,
> > register_console(), as it is now, must not be called in an interrupt
> > context.
> 
> OK. So I will change read_syslog_seq_irq() to not disable interrupts. As
> you suggested, we can fix the rest when we remove the safe buffers.

I do not have strong opinion any longer. The disabled interrupts
should not change anything, except theoretically for the parisc
emergency console.

Maybe keep the disabled interrupts there until we have a better solution
for parisc.

Best Regards,
Petr