linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>,
	Peter Zijlstra <peterz@infradead.org>,
	Jiri Bohac <jbohac@suse.cz>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 0/4] Convert timekeeping core to use printk_deferred (v2)
Date: Mon, 05 May 2014 13:15:54 -0700	[thread overview]
Message-ID: <5367F17A.3070408@linaro.org> (raw)
In-Reply-To: <20140502160536.892e6aff76df3398529d09ad@linux-foundation.org>

On 05/02/2014 04:05 PM, Andrew Morton wrote:
> On Fri,  2 May 2014 15:09:14 -0700 John Stultz <john.stultz@linaro.org> wrote:
>
>> Recently, Jiri pointed out a potential deadlock when calling printk
>> while holding the timekeeping seqlock.
>>
>> Annoyingly, the seqlock lockdep enablement doesn't catch this, as
>> printk disables lockdep.
>>
>> When looking for possible solutions, one idea was to use a local buffer
>> and defer the printk to later. Ends up there is already similar
>> functionality in printk_sched() to avoid similar style deadlocks w/
>> the scheduler.
>>
>> Thus this patchset (based on next/akpm) renames printk_sched to
>> printk_deferred and then moves the affected timekeeping printks to make
>> use of it.
>>
>> There were some points in the discussion between Jan and Peter that
>> made it seem that there may still be problems lurking in the console
>> layer, and I'm not sure I fully understand their point, so this solution
>> may be incomplete.
>>
>> Additionally, the same issue likely affects any WARN_ONs as well, but
>> I wanted to get some thoughts on this approach before trying to remove
>> or convert affected WARN_ONS.
>>
>> Your thoughts and feedback are greatly appreciated!
> All look pretty simple and sane to me.  printk is a crazy hotspot
> lately but this patchset looks like it won't get singed.
>
> Would "printk_deferred_once" be more logical than
> "printk_once_deferred"?  Think so.  It's (((printk(deferred(once))),
> not (((printk(once(deferred))).

Sounds good.  Will update the set with this.

thanks!
-john


      parent reply	other threads:[~2014-05-05 20:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02 22:09 [PATCH 0/4] Convert timekeeping core to use printk_deferred (v2) John Stultz
2014-05-02 22:09 ` [PATCH 1/4] printk: Re-add irqsave/restore in printk_sched John Stultz
2014-05-04 14:58   ` Jan Kara
2014-05-04 16:13     ` Peter Zijlstra
2014-05-05 20:16       ` John Stultz
2014-05-02 22:09 ` [PATCH 2/4] printk: Rename printk_sched to printk_deferred John Stultz
2014-05-02 22:09 ` [PATCH 3/4] printk: Add printk_once_deferred John Stultz
2014-05-02 22:09 ` [PATCH 4/4] timekeeping: Use printk_deferred when holding timekeeping seqlock John Stultz
2014-05-02 23:05 ` [PATCH 0/4] Convert timekeeping core to use printk_deferred (v2) Andrew Morton
2014-05-05 15:30   ` Steven Rostedt
2014-05-05 18:42   ` Steven Rostedt
2014-05-05 20:25     ` John Stultz
2014-05-05 20:15   ` John Stultz [this message]

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=5367F17A.3070408@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=jbohac@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).