From: Luis Chamberlain <mcgrof@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Bart Van Assche <bvanassche@acm.org>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org
Subject: Re: [PATCH] blktrace: Avoid sparse warnings when assigning q->blk_trace
Date: Thu, 28 May 2020 18:43:33 +0000 [thread overview]
Message-ID: <20200528184333.GU11244@42.do-not-panic.com> (raw)
In-Reply-To: <20200528183152.GH14550@quack2.suse.cz>
On Thu, May 28, 2020 at 08:31:52PM +0200, Jan Kara wrote:
> On Thu 28-05-20 07:44:38, Bart Van Assche wrote:
> > (+Luis)
> >
> > On 2020-05-28 02:29, Jan Kara wrote:
> > > Mostly for historical reasons, q->blk_trace is assigned through xchg()
> > > and cmpxchg() atomic operations. Although this is correct, sparse
> > > complains about this because it violates rcu annotations. Furthermore
> > > there's no real need for atomic operations anymore since all changes to
> > > q->blk_trace happen under q->blk_trace_mutex. So let's just replace
> > > xchg() with rcu_replace_pointer() and cmpxchg() with explicit check and
> > > rcu_assign_pointer(). This makes the code more efficient and sparse
> > > happy.
> > >
> > > Reported-by: kbuild test robot <lkp@intel.com>
> > > Signed-off-by: Jan Kara <jack@suse.cz>
> >
> > How about adding a reference to commit c780e86dd48e ("blktrace: Protect
> > q->blk_trace with RCU") in the description of this patch?
>
> Yes, that's probably a good idea.
>
> > > @@ -1669,10 +1672,7 @@ static int blk_trace_setup_queue(struct request_queue *q,
> > >
> > > blk_trace_setup_lba(bt, bdev);
> > >
> > > - ret = -EBUSY;
> > > - if (cmpxchg(&q->blk_trace, NULL, bt))
> > > - goto free_bt;
> > > -
> > > + rcu_assign_pointer(q->blk_trace, bt);
> > > get_probe_ref();
> > > return 0;
> >
> > This changes a conditional assignment of q->blk_trace into an
> > unconditional assignment. Shouldn't q->blk_trace only be assigned if
> > q->blk_trace == NULL?
>
> Yes but both callers of blk_trace_setup_queue() actually check that
> q->blk_trace is NULL before calling blk_trace_setup_queue() and since we
> hold blk_trace_mutex all the time, the value of q->blk_trace cannot change.
> So the conditional assignment was just bogus.
If you run a blktrace against a different partition the check does have
an effect today. This is because the request_queue is shared between
partitions implicitly, even though they end up using a different struct
dentry. So the check is actually still needed, however my change adds
this check early as well so we don't do a memory allocation just to
throw it away.
Even then, the last final check is neede then.
Try these:
https://github.com/mcgrof/break-blktrace
Luis
next prev parent reply other threads:[~2020-05-28 18:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 9:29 [PATCH] blktrace: Avoid sparse warnings when assigning q->blk_trace Jan Kara
2020-05-28 14:44 ` Bart Van Assche
2020-05-28 14:55 ` Luis Chamberlain
2020-05-28 18:31 ` Jan Kara
2020-05-28 18:43 ` Luis Chamberlain [this message]
2020-05-28 18:55 ` Jan Kara
2020-05-29 8:00 ` Luis Chamberlain
2020-05-29 9:04 ` Jan Kara
2020-05-29 11:43 ` Luis Chamberlain
2020-05-29 12:11 ` Jan Kara
2020-05-29 12:22 ` Luis Chamberlain
-- strict thread matches above, loose matches on Subject: below --
2020-06-02 7:12 Jan Kara
2020-06-02 14:17 ` Luis Chamberlain
2020-06-02 15:10 ` Luis Chamberlain
2020-06-03 8:35 ` Jan Kara
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=20200528184333.GU11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.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.