linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ming Lei <ming.lei@redhat.com>, Hannes Reinecke <hare@suse.de>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	Dan Williams <dan.j.williams@intel.com>,
	yukuai <yukuai3@huawei.com>
Subject: Re: [PATCH V2 2/2] block: fix "Directory XXXXX with parent 'block' already present!"
Date: Mon, 25 Apr 2022 09:48:42 +0200	[thread overview]
Message-ID: <20220425074842.GA9787@lst.de> (raw)
In-Reply-To: <YmYtVnC3QzfukbSu@kroah.com>

On Mon, Apr 25, 2022 at 07:10:46AM +0200, Greg Kroah-Hartman wrote:
> > But what is wrong with the test? Isn't it reasonable to keep debugfs dir
> > when blktrace is collecting log?
> 
> How can you collect something from a device that is gone?
> 
> > After debugfs dir is removed, blktrace may not collect intact log, and
> > people may complain it is one kernel regression.
> 
> What exactly breaks?  The device is removed, why should a trace continue
> to give you data?

This is a good question.  All but one of the block device drivers
really only have a concept of a block "queue" that is attached to a
live block device.  In that case the awnser is simple and obvious.

But SCSI allocates these queues before the block device, and they can
outlive it, because SCSI is a layered architecture where the "upper level"
drivers like sd and st are only bound to the queue based on information
returned from it, and the queue can outlive unbinding these drivers
(which is a bit pointless but possible due to full device model
integration).

So there might be some uses cases to keep on tracing.  I don't think they
are very valid, though, because if you really want to trace that raw
queue you can do it using the /dev/sg node.


  reply	other threads:[~2022-04-25  7:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-23 14:39 [PATCH V2 0/2] block: fix "Directory XXXXX with parent 'block' already present!" Ming Lei
2022-04-23 14:39 ` [PATCH V2 1/2] debugfs: fix declaration of debugfs_rename Ming Lei
2022-04-23 14:39 ` [PATCH V2 2/2] block: fix "Directory XXXXX with parent 'block' already present!" Ming Lei
2022-04-23 16:29   ` Christoph Hellwig
2022-04-24  9:24     ` Ming Lei
2022-04-25  7:49       ` Christoph Hellwig
2022-04-25  9:18         ` Ming Lei
2022-04-24  8:53   ` Hannes Reinecke
2022-04-24  9:28     ` Ming Lei
2022-04-24 11:51       ` Hannes Reinecke
2022-04-24 12:04         ` Ming Lei
2022-04-24 13:45           ` Greg Kroah-Hartman
2022-04-25  1:28             ` Ming Lei
2022-04-25  5:10               ` Greg Kroah-Hartman
2022-04-25  7:48                 ` Christoph Hellwig [this message]
2022-04-25  7:53                   ` Hannes Reinecke
2022-04-25  9:07                 ` Ming Lei
2022-04-25  9:32                   ` Hannes Reinecke
2022-04-26  3:07                     ` Ming Lei
2022-05-23 13:11   ` Yu Kuai

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=20220425074842.GA9787@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --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;
as well as URLs for NNTP newsgroup(s).