All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: NeilBrown <neilb@suse.de>
Cc: Tony Battersby <tonyb@cybernetics.com>,
	linux-raid@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
	axboe@kernel.dk, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: RAID1 might_sleep() warning on 3.19-rc7
Date: Mon, 9 Feb 2015 10:10:00 +0100	[thread overview]
Message-ID: <20150209091000.GN5029@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150209121357.29f19d36@notabene.brown>

On Mon, Feb 09, 2015 at 12:13:57PM +1100, NeilBrown wrote:
> I had to re-read the code (And your analysis) a couple of times to be sure ...

Sorry :-)

> However, when io_schedule() explicitly calls blk_flush_plug(), then
> @from_schedule=false variant is used, and the unplug functions are allowed to
> allocate memory and block and maybe even call mempool_alloc() which might
> call io_schedule().
> 
> This shouldn't be a problem as blk_flush_plug() spliced out the plug list, so
> any recursive call will find an empty list and do nothing.

Unless, something along the way stuck something back on, right? So
should we stick an:

	WARN_ON(current->in_iowait);

somewhere near where things are added to this plug list? (and move the
blk_flush_plug() call inside of where that's actually true of course).

> Worst case is that a wait_event loop that calls io_schedule() (i.e.
> wait_on_bit_io()) might not block in the first call to io_schedule()
> if the unplugging needed to wait.  Every subsequent call will block as
> required as there is nothing else to add requests to the plug queue.

Again, assuming @cond will not actually stick something on this list.
Which if we add the above we'll get warned about.

> It isn't that scheduling is "rare" - it is that it can only occur once in a
> loop which doesn't expect it.

With the above WARN stuck in, agreed.

> So I propose the following, though I haven't tested it.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e628cb11b560..b0f12ab3df23 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4374,6 +4374,11 @@ void __sched io_schedule(void)
>  
>  	delayacct_blkio_start();
>  	atomic_inc(&rq->nr_iowait);
> +	/* Any sleeping in blk_flush_plug() should not
> +	 * trigger the "do not call blocking ops" warning
> +	 * as it can only happen once in a wait_event loop.
> +	 */

Might I suggest the 'regular' multi-line comment style, and a reference
to the above WARN that makes everything actually work?

	/*
	 * multi-line
	 *  comments have an empty
	 *    line at the start... As per CodingStyle ch. 8
	 */

> +	sched_annotate_sleep();
>  	blk_flush_plug(current);

Also, at this point, should we put it in blk_flush_plug()?


The only thing that really goes wrong then is if people 'forget' to put
a loop around io_schedule().

  reply	other threads:[~2015-02-09  9:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-05 20:27 RAID1 might_sleep() warning on 3.19-rc7 Tony Battersby
2015-02-05 21:51 ` NeilBrown
2015-02-06 11:39   ` Peter Zijlstra
2015-02-09  1:13     ` NeilBrown
2015-02-09  9:10       ` Peter Zijlstra [this message]
2015-02-10  2:50         ` NeilBrown
2015-02-10  9:29           ` Peter Zijlstra
2015-02-10 11:01             ` Peter Zijlstra
2015-02-13  5:26             ` NeilBrown
2015-02-13  8:32               ` Peter Zijlstra
2015-02-13  8:49                 ` NeilBrown
2015-02-13 10:27                   ` Peter Zijlstra
2015-02-13 14:48                     ` Peter Zijlstra
2015-02-18  1:09                       ` NeilBrown
2015-02-18 13:47                         ` Peter Zijlstra
2015-02-18 17:07               ` [tip:sched/core] sched: Prevent recursion in io_schedule() tip-bot for NeilBrown

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=20150209091000.GN5029@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=tonyb@cybernetics.com \
    --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.