public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
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


  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