[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YdiuN9kv5OvE/Rtf@slm.duckdns.org>
Date: Fri, 7 Jan 2022 11:18:47 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Yu Kuai <yukuai3@...wei.com>, hch@...radead.org, axboe@...nel.dk,
cgroups@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, yi.zhang@...wei.com,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH v5 2/2] block: cancel all throttled bios in del_gendisk()
Hello,
On Fri, Jan 07, 2022 at 04:05:19PM +0100, Michal Koutný wrote:
> On Fri, Dec 10, 2021 at 04:31:43PM +0800, Yu Kuai <yukuai3@...wei.com> wrote:
> > + * queue_lock is held, rcu lock is not needed here.
> > + */
> > + blkg_for_each_descendant_post(blkg, pos_css, td->queue->root_blkg)
> > + tg_drain_bios(&blkg_to_tg(blkg)->service_queue);
>
> FTR, I acknowledge this can work due to RCU peculiarities, however, I
> don't understand why is it preferred against more robust explict
> rcu_read_lock().
>
> (All in all, this isn't a deal breaker and I'm not confident evaluating
> the rest of the patch.)
Cc'ing Paul for RCU. Paul, this nit is around whether or not to use
rcu_read_lock() in an irq disabled section. I can see both sides of the
arguments - it's weird to put in an extra rcu_read_lock() when technically
unnecessary but it's also nice to have something explicit and structured to
mark parts which require RCU protection. Putting in a comment is okay but
consistency is difficult to achieve that way.
Maybe all these are unnecessary as lockdep would be able to catch them
anyway, or maybe we'd want something to explicitly mark RCU protected
sections. I don't know but whichever way, I think we need to establish a
convention.
Thanks.
--
tejun
Powered by blists - more mailing lists