From: Joel Fernandes <joel@joelfernandes.org>
To: dsterba@suse.cz,
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>,
Qu Wenruo <quwenruo.btrfs@gmx.com>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
paulmck@kernel.org, frextrite@gmail.com, linux@roeck-us.net
Subject: Re: [PATCH] fs: btrfs: block-group.c: Fix suspicious RCU usage warning
Date: Fri, 6 Mar 2020 14:53:23 -0500 [thread overview]
Message-ID: <20200306195323.GE60713@google.com> (raw)
In-Reply-To: <20200306152527.GH2902@twin.jikos.cz>
On Fri, Mar 06, 2020 at 04:25:27PM +0100, David Sterba wrote:
> On Fri, Mar 06, 2020 at 07:30:24PM +0530, Madhuparna Bhowmik wrote:
> > On Fri, Mar 06, 2020 at 03:16:53PM +0800, Qu Wenruo wrote:
> > >
> > >
> > > On 2020/3/6 下午2:52, madhuparnabhowmik10@gmail.com wrote:
> > > > From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> > > >
> > > > The space_info list is rcu protected.
> > > > Hence, it should be traversed with rcu_read_lock held.
> > > >
> > > > Warning:
> > > > [ 29.104591] =============================
> > > > [ 29.104756] WARNING: suspicious RCU usage
> > > > [ 29.105046] 5.6.0-rc4-next-20200305 #1 Not tainted
> > > > [ 29.105231] -----------------------------
> > > > [ 29.105401] fs/btrfs/block-group.c:2011 RCU-list traversed in non-reader section!!
> > > >
> > > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> > > > ---
> > > > fs/btrfs/block-group.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
> > > > index 404e050ce8ee..9cabeef66f5b 100644
> > > > --- a/fs/btrfs/block-group.c
> > > > +++ b/fs/btrfs/block-group.c
> > > > @@ -1987,6 +1987,7 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
> > >
> > > This function is only triggered at mount time, where no other rcu
> > > operation can happen.
> > >
> > Thanks Qu.
> >
> > Joel and Paul, what should we do in this case?
> > Should we just pass cond = true or use list_for_each_entry instead?
>
> I think we can afford to add rcu lock/unlock, even if it's not strictly
> necessary due to the single threaded context where the function is run.
> There are some lightweight operations inside and inc_block_group starts
> with two spin locks so there's nothing we'd be losing with disabled
> preemption from the caller.
I think use list_for_each_entry().
thanks,
- Joel
WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: dsterba@suse.cz,
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>,
Qu Wenruo <quwenruo.btrfs@gmx.com>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
paulmck@kernel.org, frextrite@gmail.com, linux@roeck-us.net
Subject: Re: [Linux-kernel-mentees] [PATCH] fs: btrfs: block-group.c: Fix suspicious RCU usage warning
Date: Fri, 6 Mar 2020 14:53:23 -0500 [thread overview]
Message-ID: <20200306195323.GE60713@google.com> (raw)
In-Reply-To: <20200306152527.GH2902@twin.jikos.cz>
On Fri, Mar 06, 2020 at 04:25:27PM +0100, David Sterba wrote:
> On Fri, Mar 06, 2020 at 07:30:24PM +0530, Madhuparna Bhowmik wrote:
> > On Fri, Mar 06, 2020 at 03:16:53PM +0800, Qu Wenruo wrote:
> > >
> > >
> > > On 2020/3/6 下午2:52, madhuparnabhowmik10@gmail.com wrote:
> > > > From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> > > >
> > > > The space_info list is rcu protected.
> > > > Hence, it should be traversed with rcu_read_lock held.
> > > >
> > > > Warning:
> > > > [ 29.104591] =============================
> > > > [ 29.104756] WARNING: suspicious RCU usage
> > > > [ 29.105046] 5.6.0-rc4-next-20200305 #1 Not tainted
> > > > [ 29.105231] -----------------------------
> > > > [ 29.105401] fs/btrfs/block-group.c:2011 RCU-list traversed in non-reader section!!
> > > >
> > > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> > > > ---
> > > > fs/btrfs/block-group.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
> > > > index 404e050ce8ee..9cabeef66f5b 100644
> > > > --- a/fs/btrfs/block-group.c
> > > > +++ b/fs/btrfs/block-group.c
> > > > @@ -1987,6 +1987,7 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
> > >
> > > This function is only triggered at mount time, where no other rcu
> > > operation can happen.
> > >
> > Thanks Qu.
> >
> > Joel and Paul, what should we do in this case?
> > Should we just pass cond = true or use list_for_each_entry instead?
>
> I think we can afford to add rcu lock/unlock, even if it's not strictly
> necessary due to the single threaded context where the function is run.
> There are some lightweight operations inside and inc_block_group starts
> with two spin locks so there's nothing we'd be losing with disabled
> preemption from the caller.
I think use list_for_each_entry().
thanks,
- Joel
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2020-03-06 19:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 6:52 [PATCH] fs: btrfs: block-group.c: Fix suspicious RCU usage warning madhuparnabhowmik10
2020-03-06 6:52 ` [Linux-kernel-mentees] " madhuparnabhowmik10
2020-03-06 7:16 ` Qu Wenruo
2020-03-06 7:16 ` [Linux-kernel-mentees] " Qu Wenruo
2020-03-06 14:00 ` Madhuparna Bhowmik
2020-03-06 14:00 ` [Linux-kernel-mentees] " Madhuparna Bhowmik
2020-03-06 15:25 ` David Sterba
2020-03-06 15:25 ` [Linux-kernel-mentees] " David Sterba
2020-03-06 19:53 ` Joel Fernandes [this message]
2020-03-06 19:53 ` Joel Fernandes
2020-03-06 19:37 ` David Sterba
2020-03-06 19:37 ` [Linux-kernel-mentees] " David Sterba
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=20200306195323.GE60713@google.com \
--to=joel@joelfernandes.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=frextrite@gmail.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=madhuparnabhowmik10@gmail.com \
--cc=paulmck@kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/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.