Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1540790

Re: [RFC][PATCHv5 7/7] printk: remove zap_locks() function

From Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC][PATCHv5 7/7] printk: remove zap_locks() function
Date 2016-12-13 02:30 +0100
Message-ID <sNK4O-3eY-9@gated-at.bofh.it> (permalink)
References <sJA41-4xo-5@gated-at.bofh.it> <sJA41-4xo-3@gated-at.bofh.it> <sNBNU-6Du-57@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On (12/12/16 17:37), Petr Mladek wrote:
> On Thu 2016-12-01 22:55:46, Sergey Senozhatsky wrote:
> > We use printk-safe now which makes printk-recursion detection code
> > in vprintk_emit() unreachable. The tricky thing here is that, apart
> > from detecting and reporting printk recursions, that code also used
> > to zap_locks() in case of panic() from the same CPU. However,
> > zap_locks() does not 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'.
> > 
> > Basically, it seems that we either already do what zap_locks() used to
> > do but in other places or we ignore the state of the lock. The only
> > reaming difference is that we don't re-init the console semaphore in
> > printk_safe_flush_on_panic(), but this is not necessary because we
> > don't call console drivers from printk_safe_flush_on_panic() due to
> > the fact that we are using a deferred printk() version (as was
> > suggested by Petr Mladek).
> > 
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> 
> I like this patch. The code is unused after protecting the section
> by printk_safe_enter()/exit(). And also the panic mode is handled
> by the commits mentioned above.

and the scenario that code tried to address was super-tiny.
basically, a recursion from vscnprintf()/log_output() every 30
seconds (zap_locks() timeout):

	if (unlikely(logbuf_cpu == this_cpu)) {
		zap_locks();
	}

	raw_spin_lock(&logbuf_lock);
	logbuf_cpu = this_cpu;

	text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
	kern_level = printk_get_level(text));
	log_output(facility, level, lflags, dict, dictlen, text, text_len);

	logbuf_cpu = UINT_MAX;
	raw_spin_unlock(&logbuf_lock);

now we cover a much bigger scope.


> Reviewed-by: Petr Mladek <pmladek@suse.com>

thanks.

	-ss

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [RFC][PATCHv5 7/7] printk: remove zap_locks() function Petr Mladek <pmladek@suse.com> - 2016-12-12 17:40 +0100
  Re: [RFC][PATCHv5 7/7] printk: remove zap_locks() function Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-13 02:30 +0100

csiph-web