All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	John Ogness <john.ogness@linutronix.de>,
	Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t
Date: Wed, 9 Dec 2020 20:28:52 +0900	[thread overview]
Message-ID: <X9C09N5r4sGdel+h@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <20201209110042.GW3021@hirez.programming.kicks-ass.net>

On (20/12/09 12:00), Peter Zijlstra wrote:
> > So another potential re-entry path is
> > 
> > 	atomic_foo()
> > 	 spin_lock_irqsave(ATOMIC_HASH(v), flags)
> > 	  printk()
> > 	   prb()
> > 	    atomic_foo()
> > 	     spin_lock_irqsave(ATOMIC_HASH(v), flags)
> > 
> > which can deadlock, in theory, if both atomics HASH to the same
> > key (same spin_lock).
> 
> Yep, but see the 'mostly' in the 'they mostly work'. Given the
> limitiations of these architectures there's really only so much you can
> do.

Right, agreed.

Nevertheless TIL that lockless printk buffer is not always lockless.
Perhaps, people that work with those archs need to also know this.
I haven't checked all the archs, but if, somehow, (IF) some of them
can panic the system with the atomic hash entries locked, then on
those archs new printk may not be able to flush-on-panic. Because
while printk iterates logbuf it may HASH to the atomic hash table
entry, that will never be unlocked. So there are some changes in
atomic/printk department on those archs.

	-ss

  reply	other threads:[~2020-12-09 11:29 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 20:53 [PATCH next v2 0/3] printk: remove logbuf_lock John Ogness
2020-12-01 20:53 ` [PATCH next v2 1/3] printk: inline log_output(),log_store() in vprintk_store() John Ogness
2020-12-03 15:57   ` Petr Mladek
2020-12-03 16:25     ` John Ogness
2020-12-04  6:13       ` Sergey Senozhatsky
2020-12-04  8:26       ` Petr Mladek
2020-12-01 20:53 ` [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t John Ogness
2020-12-04  9:12   ` Petr Mladek
2020-12-06 20:23     ` John Ogness
2020-12-07  9:34       ` Peter Zijlstra
2020-12-07 10:03         ` John Ogness
2020-12-07 12:56           ` Peter Zijlstra
2020-12-07 12:56           ` Petr Mladek
2020-12-07 16:46           ` David Laight
2020-12-08 20:34     ` Sergey Senozhatsky
2020-12-08 22:30       ` John Ogness
2020-12-09  1:04         ` Sergey Senozhatsky
2020-12-09  8:16         ` Peter Zijlstra
2020-12-09  9:22           ` Sergey Senozhatsky
2020-12-09 10:46             ` Sergey Senozhatsky
2020-12-09 11:00               ` Peter Zijlstra
2020-12-09 11:28                 ` Sergey Senozhatsky [this message]
2020-12-09 12:29                   ` Peter Zijlstra
2020-12-09  8:07       ` Peter Zijlstra
2020-12-01 20:53 ` [PATCH next v2 3/3] printk: remove logbuf_lock, add syslog_lock John Ogness
2020-12-04  6:41   ` Sergey Senozhatsky
2020-12-06 20:44     ` John Ogness
2020-12-04 15:52   ` devkmsg: was " Petr Mladek
2020-12-06 20:51     ` John Ogness
2020-12-07  9:56       ` Petr Mladek
2020-12-04 15:57   ` syslog: was: " Petr Mladek
2020-12-06 21:06     ` John Ogness
2020-12-07 10:01       ` Petr Mladek
2020-12-04 16:10   ` recursion handling: " Petr Mladek
2020-12-05  4:25     ` Sergey Senozhatsky
2020-12-06 22:08       ` John Ogness
2020-12-05  9:41     ` Sergey Senozhatsky
2020-12-06 22:17       ` John Ogness
2020-12-06 21:44     ` John Ogness
2020-12-07 11:17       ` Petr Mladek
2020-12-04 16:15   ` vprintk_store: was: " Petr Mladek
2020-12-06 22:30     ` John Ogness
2020-12-07 12:46       ` Petr Mladek
2020-12-04 16:19   ` consoles: " Petr Mladek
2020-12-05  4:39     ` Sergey Senozhatsky
2020-12-07  9:50       ` Petr Mladek
2020-12-08 20:51         ` Sergey Senozhatsky

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=X9C09N5r4sGdel+h@jagdpanzerIV.localdomain \
    --to=sergey.senozhatsky@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.