[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161201131539.GO21230@pathway.suse.cz>
Date: Thu, 1 Dec 2016 14:15:39 +0100
From: Petr Mladek <pmladek@...e.com>
To: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.cz>,
Tejun Heo <tj@...nel.org>, Calvin Owens <calvinowens@...com>,
Thomas Gleixner <tglx@...utronix.de>,
Mel Gorman <mgorman@...hsingularity.net>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Laura Abbott <labbott@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function
On Thu 2016-12-01 21:50:45, Sergey Senozhatsky wrote:
> On (11/25/16 16:01), Petr Mladek wrote:
> [..]
> > > apart from detecting and reporting printk recursions, that code also
> > > used to zap_lockc() in case of panic. However, zap_locks() does not
> > ^
> >
> > s/zap_lockc/zap_locks/
> >
> > > look to be needed anymore:
> > >
> > > 1) Since commit 08d78658f393 ("panic: release stale console lock to
> > > always get the logbuf printed out") panic flushing of `logbuf' to
> > > console ignores the state of `console_sem' by doing
> > > panic()
> > > console_trylock();
> > > console_unlock();
> > >
> > > 2) Since commit cf9b1106c81c ("printk/nmi: flush NMI messages on the
> > > system panic") panic attempts to zap the `logbuf_lock' spin_lock to
> > > successfully flush nmi messages to `logbuf'.
> >
> > Note that the same code is newly used to flush also the printk_safe
> > per-CPU buffers. It means that logbuf_lock is zapped also when
> > flushing these new buffers.
>
>
> not quite. there are several checks that would prevent multiple logbuf_lock
> re-inits:
Ah, I did not meant that the lock was zapped twice. I wanted to say
that we added a new path and that it was handled as well :-)
Best Regards,
Petr
Powered by blists - more mailing lists