From: Christoph Hellwig <hch@lst.de>
To: John Garry <john.g.garry@oracle.com>
Cc: hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, axboe@fb.com,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH RFC] nvme: fix NS head cdev lifetime
Date: Wed, 8 Jul 2026 11:27:40 +0200 [thread overview]
Message-ID: <20260708092740.GB6513@lst.de> (raw)
In-Reply-To: <20260706130146.617258-1-john.g.garry@oracle.com>
On Mon, Jul 06, 2026 at 01:01:46PM +0000, John Garry wrote:
> Sashiko bot reported a potential problem for the NS head cdev lifetime in
> the libmultipath refactoring in [0].
>
> Currently the NS head .open and .release file_operations methods take a
> reference to the nvme_ns_head to ensure that this structure does not
> disappear while we have files open.
>
> When we teardown the NS head, we call nvme_cdev_del() -> cdev_device_del()
> -> cdev_del(). However after cdev_del() returns, cdevs already open will
> remain and their fops will still be callable. As such, we can still
> reference the cdev after the nvme_ns_head reference count drops to 0 (and
> is freed).
>
> This can be shown with an application which delays between opening the cdev
> and issuing the ioctl while the NS head is being torn down:
Can you wire this up to blktests?
> When all fds for the cdev disappear, the cdev removal path puts a
> reference to the parent object, which is the nvme_ns_head.cdev_device - see
> cdev_default_release() -> kobject_put(parent). We can use the lifetime
> of the cdev_device to resolve this lifetime issue.
>
> Fix the lifetime for the cdev by making adding the cdev add take a
> reference to the NS head and drop that reference in the
> nvme_ns_head.cdev_device release function.
>
> [0] https://lore.kernel.org/linux-scsi/20260703102918.3723667-1-john.g.garry@oracle.com/T/#m67265e2906d617acd2743c0a00809246d0cfc506
>
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> ---
> Setting as RFC as I am not sure if this is the best solution.
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 453c1f0b2dd09..c7578b7ed6b76 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -3887,7 +3887,7 @@ static int nvme_subsys_check_duplicate_ids(struct nvme_subsystem *subsys,
> return 0;
> }
>
> -static void nvme_cdev_rel(struct device *dev)
> +void nvme_cdev_rel(struct device *dev)
> {
> ida_free(&nvme_ns_chr_minor_ida, MINOR(dev->devt));
> }
Can we unify this and the ns_head version by checking of which type
the device is somehow? I think driver_data would still be free to
optionally point to the ns_head for eexample.
> + if (nvme_tryget_ns_head(head)) {
> + if (nvme_cdev_add(name, &head->cdev, &head->cdev_device,
> + &nvme_ns_head_chr_fops, THIS_MODULE,
> + nvme_cdev_ns_head_rel)) {
Messed up indenttation here as continuations in an conditional/loop
should not be indented the ssame way as the body.
This could be merged a bit anywya:
if (nvme_tryget_ns_head(head) &&
nvme_cdev_add(name, &head->cdev, &head->cdev_device,
&nvme_ns_head_chr_fops, THIS_MODULE)) {
dev_err(disk_to_dev(head->disk),
"Unable to create the %s device\n", name);
nvme_put_ns_head(head);
return;
}
but shouldn't we warn for the nvme_tryget_ns_head failure as well?
Or can that even happen here?
next prev parent reply other threads:[~2026-07-08 9:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 13:01 [PATCH RFC] nvme: fix NS head cdev lifetime John Garry
2026-07-08 9:27 ` Christoph Hellwig [this message]
2026-07-08 9:57 ` John Garry
2026-07-08 11:26 ` John Garry
2026-07-08 16:18 ` Christoph Hellwig
2026-07-09 7:33 ` John Garry
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=20260708092740.GB6513@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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.