From: Ming Lei <ming.lei@redhat.com>
To: "yukuai (C)" <yukuai3@huawei.com>
Cc: "Williams, Dan J" <dan.j.williams@intel.com>,
"axboe@kernel.dk" <axboe@kernel.dk>, "hch@lst.de" <hch@lst.de>,
"tj@kernel.org" <tj@kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 2/3] block: let blkcg_gq grab request queue's refcnt
Date: Wed, 20 Apr 2022 10:20:44 +0800 [thread overview]
Message-ID: <Yl9t/Dy7C53DFEh0@T590> (raw)
In-Reply-To: <292908e4-8721-20a0-2720-e60641a1fbe4@huawei.com>
On Wed, Apr 20, 2022 at 10:01:36AM +0800, yukuai (C) wrote:
> 在 2022/04/20 9:46, Williams, Dan J 写道:
> > On Fri, 2022-03-18 at 21:01 +0800, Ming Lei wrote:
> > > In the whole lifetime of blkcg_gq instance, ->q will be referred, such
> > > as, ->pd_free_fn() is called in blkg_free, and throtl_pd_free() still
> > > may touch the request queue via &tg->service_queue.pending_timer which
> > > is handled by throtl_pending_timer_fn(), so it is reasonable to grab
> > > request queue's refcnt by blkcg_gq instance.
> > >
> > > Previously blkcg_exit_queue() is called from blk_release_queue, and it
> > > is hard to avoid the use-after-free. But recently commit 1059699f87eb ("block:
> > > move blkcg initialization/destroy into disk allocation/release handler")
> > > is merged to for-5.18/block, it becomes simple to fix the issue by simply
> > > grabbing request queue's refcnt.
> >
> > This patch, upstream as commit 0a9a25ca7843 ("block: let blkcg_gq grab
> > request queue's refcnt") causes the nvdimm unit tests to spam messages
> > like:
> >
> > [ 51.439133] debugfs: Directory 'pmem2' with parent 'block' already present!
> > [ 52.095679] debugfs: Directory 'pmem3' with parent 'block' already present!
> > [ 52.505613] block device autoloading is deprecated and will be removed.
> > [ 52.791693] debugfs: Directory 'pmem2' with parent 'block' already present!
> > [ 53.240314] debugfs: Directory 'pmem3' with parent 'block' already present!
> > [ 53.373472] debugfs: Directory 'pmem3' with parent 'block' already present!
> > [ 53.688876] nd_pmem btt2.0: No existing arenas
> > [ 53.773097] debugfs: Directory 'pmem2s' with parent 'block' already present!
> > [ 53.884493] debugfs: Directory 'pmem2s' with parent 'block' already present!
> > [ 54.042946] debugfs: Directory 'pmem2s' with parent 'block' already present!
> > [ 54.195954] debugfs: Directory 'pmem2s' with parent 'block' already present!
> > [ 54.383989] debugfs: Directory 'pmem2' with parent 'block' already present!
> > [ 54.577206] nd_pmem btt3.0: No existing arenas
> >
> Hi,
>
> I saw the same warning in our test, and I posted a patch to fix the
> problem:
>
> https://patchwork.kernel.org/project/linux-block/patch/20220415035607.1836495-1-yukuai3@huawei.com/
>
> The root cause is not relate to the above commit, see details in
> the commit message.
Yeah, I am pretty sure the issue of 'debugfs: Directory 'XXXXX' with parent 'block' already
present!' is one block layer long-term issue.
Commit 0a9a25ca7843 ("block: let blkcg_gq grab request queue's refcnt") justs causes queue
released a bit late, then the issue becomes easier to trigger.
Thanks,
Ming
next prev parent reply other threads:[~2022-04-20 2:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 13:01 [PATCH for-5.18 0/3] block: throttle related fixes Ming Lei
2022-03-18 13:01 ` [PATCH 1/3] block: avoid use-after-free on throttle data Ming Lei
2022-03-18 13:01 ` [PATCH 2/3] block: let blkcg_gq grab request queue's refcnt Ming Lei
2022-03-22 9:33 ` Christoph Hellwig
2022-03-22 10:23 ` Ming Lei
2022-03-22 16:45 ` Tejun Heo
2022-03-23 0:32 ` Ming Lei
2022-04-20 1:46 ` Williams, Dan J
2022-04-20 2:01 ` yukuai (C)
2022-04-20 2:20 ` Ming Lei [this message]
2022-04-20 3:40 ` Dan Williams
2022-03-18 13:01 ` [PATCH 3/3] block: cancel all throttled bios in del_gendisk() Ming Lei
2022-03-18 15:58 ` [PATCH for-5.18 0/3] block: throttle related fixes Jens Axboe
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=Yl9t/Dy7C53DFEh0@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox