All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Fengguang Wu <fengguang.wu@intel.com>,
	Peter Zijlstra <peterz@infradead.org>, LKP <lkp@01.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Shaohua Li <shli@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: __might_sleep() warnings on v3.19-rc6
Date: Mon, 2 Feb 2015 17:09:37 +1100	[thread overview]
Message-ID: <20150202170937.4b5ffcb0@notabene.brown> (raw)
In-Reply-To: <CA+55aFyR-ZK9Y2KkxbcTnMOcCc243ZKD6AKTuktpmyE0HCUcPw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

On Sun, 1 Feb 2015 21:08:12 -0800 Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> On Sun, Feb 1, 2015 at 3:03 PM, NeilBrown <neilb@suse.de> wrote:
> >
> > I guess I could
> >       __set_current_state(TASK_RUNNING);
> > somewhere to defeat the warning, and add a comment explaining why.
> >
> > Would that be a good thing?
> 
> Use "sched_annotate_sleep()" instead, but yes, add a comment about why it's ok.
> 
>                         Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

OK - following patch is queued to appear in a pull request tomorrow  (I hope).

Thanks,
NeilBrown

From: NeilBrown <neilb@suse.de>
Date: Mon, 2 Feb 2015 17:08:03 +1100
Subject: [PATCH] md/bitmap: fix a might_sleep() warning.

commit 8eb23b9f35aae413140d3fda766a98092c21e9b0
    sched: Debug nested sleeps

causes false-positive warnings in RAID5 code.

This annotation removes them and adds a comment
explaining why there is no real problem.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index da3604e73e8a..1695ee5f3ffc 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -72,6 +72,19 @@ __acquires(bitmap->lock)
 	/* this page has not been allocated yet */
 
 	spin_unlock_irq(&bitmap->lock);
+	/* It is possible that this is being called inside a
+	 * prepare_to_wait/finish_wait loop from raid5c:make_request().
+	 * In general it is not permitted to sleep in that context as it
+	 * can cause the loop to spin freely.
+	 * That doesn't apply here as we can only reach this point
+	 * once with any loop.
+	 * When this function completes, either bp[page].map or
+	 * bp[page].hijacked.  In either case, this function will
+	 * abort before getting to this point again.  So there is
+	 * no risk of a free-spin, and so it is safe to assert
+	 * that sleeping here is allowed.
+	 */
+	sched_annotate_sleep();
 	mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
 	spin_lock_irq(&bitmap->lock);
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.de>
To: lkp@lists.01.org
Subject: Re: __might_sleep() warnings on v3.19-rc6
Date: Mon, 02 Feb 2015 17:09:37 +1100	[thread overview]
Message-ID: <20150202170937.4b5ffcb0@notabene.brown> (raw)
In-Reply-To: <CA+55aFyR-ZK9Y2KkxbcTnMOcCc243ZKD6AKTuktpmyE0HCUcPw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Sun, 1 Feb 2015 21:08:12 -0800 Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> On Sun, Feb 1, 2015 at 3:03 PM, NeilBrown <neilb@suse.de> wrote:
> >
> > I guess I could
> >       __set_current_state(TASK_RUNNING);
> > somewhere to defeat the warning, and add a comment explaining why.
> >
> > Would that be a good thing?
> 
> Use "sched_annotate_sleep()" instead, but yes, add a comment about why it's ok.
> 
>                         Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

OK - following patch is queued to appear in a pull request tomorrow  (I hope).

Thanks,
NeilBrown

From: NeilBrown <neilb@suse.de>
Date: Mon, 2 Feb 2015 17:08:03 +1100
Subject: [PATCH] md/bitmap: fix a might_sleep() warning.

commit 8eb23b9f35aae413140d3fda766a98092c21e9b0
    sched: Debug nested sleeps

causes false-positive warnings in RAID5 code.

This annotation removes them and adds a comment
explaining why there is no real problem.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index da3604e73e8a..1695ee5f3ffc 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -72,6 +72,19 @@ __acquires(bitmap->lock)
 	/* this page has not been allocated yet */
 
 	spin_unlock_irq(&bitmap->lock);
+	/* It is possible that this is being called inside a
+	 * prepare_to_wait/finish_wait loop from raid5c:make_request().
+	 * In general it is not permitted to sleep in that context as it
+	 * can cause the loop to spin freely.
+	 * That doesn't apply here as we can only reach this point
+	 * once with any loop.
+	 * When this function completes, either bp[page].map or
+	 * bp[page].hijacked.  In either case, this function will
+	 * abort before getting to this point again.  So there is
+	 * no risk of a free-spin, and so it is safe to assert
+	 * that sleeping here is allowed.
+	 */
+	sched_annotate_sleep();
 	mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
 	spin_lock_irq(&bitmap->lock);
 

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

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

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-28 14:25 WARNING: CPU: 0 PID: 61 at kernel/sched/core.c:7312 __might_sleep() Fengguang Wu
2014-10-28 14:25 ` Fengguang Wu
2014-10-29 16:16 ` [PATCH] netdev: Fix sleeping inside wait event Peter Zijlstra
2014-10-29 16:16   ` Peter Zijlstra
2014-10-29 16:29   ` Cong Wang
2014-10-29 16:29     ` Cong Wang
2014-10-29 17:13     ` Peter Zijlstra
2014-10-29 17:13       ` Peter Zijlstra
2014-10-29 17:31       ` Peter Zijlstra
2014-10-29 17:31         ` Peter Zijlstra
2014-10-29 17:38         ` David Miller
2014-10-29 17:38           ` David Miller
2014-11-04 16:09         ` [tip:sched/core] netdev, sched/wait: " tip-bot for Peter Zijlstra
2014-10-29 17:37   ` [PATCH] netdev: " David Miller
2014-10-29 17:37     ` David Miller
2015-02-01  3:43 ` __might_sleep() warnings on v3.19-rc6 Fengguang Wu
2015-02-01  3:43   ` Fengguang Wu
2015-02-01 23:03   ` NeilBrown
2015-02-01 23:03     ` NeilBrown
2015-02-02  4:58     ` NeilBrown
2015-02-02  4:58       ` NeilBrown
2015-02-02  5:08     ` Linus Torvalds
2015-02-02  5:08       ` Linus Torvalds
2015-02-02  6:09       ` NeilBrown [this message]
2015-02-02  6:09         ` NeilBrown
2015-02-05 16:16   ` Chris Mason
2015-02-05 16:16     ` Chris Mason

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=20150202170937.4b5ffcb0@notabene.brown \
    --to=neilb@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=peterz@infradead.org \
    --cc=shli@kernel.org \
    --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.