All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: AlanCui4080 <me@alancui.cc>
Cc: linux-nvme@lists.infradead.org
Subject: Re: Non-SGL transport mode warnings are set to dev_warn_once will cause confusion
Date: Thu, 9 Apr 2026 08:36:56 -0600	[thread overview]
Message-ID: <ade5iAP4y94z0JDL@kbusch-mbp> (raw)
In-Reply-To: <4770779.LvFx2qVVIh@alanarchdesktop>

On Thu, Apr 09, 2026 at 04:46:37PM +0800, AlanCui4080 wrote:
> See 6fad84a (nvme-pci: use sgls for all user requests if possible). In the 
> kernel, those warnings are printed using `dev warn once`. This means that if 
> multiple devices in the system do not support SGLs (most consumer-grade 
> devices do not support them), only one warning for only one device will be 
> printed.
> 
> This asymmetry can be misleading to users. If all devices in the system report 
> the same issue, it might not be a problem, but if only one device reports it, 
> it might (especially since I have two identical drives). Is it possible to 
> move this warning to the device initialization phase so print it for each 
> device? Or, since we cannot resolve the issue of consumer-grade devices not 
> supporting SGL, should it be downgraded to an informational warning?

Fine with me. The warning was added in response to people filing CVE's
against the driver as a sort of acknowledgement that yeah, this
interface can't validate transfer lengths under these conditions, so
we're trusting the user isn't abusing it. A sort of nudge that perhaps
controller vendors might consider supporting the safer option.

Anyway, it's fine with me to move the message and make it less scary.
How about this:

---
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index b42d8768d2979..b6aec0e3fbfb8 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3744,6 +3744,10 @@ int nvme_init_ctrl_finish(struct nvme_ctrl *ctrl, bool was_suspended)
 		ret = nvme_hwmon_init(ctrl);
 		if (ret == -EINTR)
 			return ret;
+
+		if (!nvme_ctrl_sgl_supported(ctrl))
+			dev_info(ctrl->device,
+				"passthrough uses implicit buffer lengths\n");
 	}
 
 	clear_bit(NVME_CTRL_DIRTY_CAPABILITY, &ctrl->flags);
diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c
index 8844bbd395159..e9eecdd54d5ed 100644
--- a/drivers/nvme/host/ioctl.c
+++ b/drivers/nvme/host/ioctl.c
@@ -125,16 +125,8 @@ static int nvme_map_user_request(struct request *req, u64 ubuffer,
 	struct bio *bio = NULL;
 	int ret;
 
-	if (!nvme_ctrl_sgl_supported(ctrl))
-		dev_warn_once(ctrl->device, "using unchecked data buffer\n");
-	if (has_metadata) {
-		if (!supports_metadata)
-			return -EINVAL;
-
-		if (!nvme_ctrl_meta_sgl_supported(ctrl))
-			dev_warn_once(ctrl->device,
-				      "using unchecked metadata buffer\n");
-	}
+	if (has_metadata && !supports_metadata)
+		return -EINVAL;
 
 	if (iter)
 		ret = blk_rq_map_user_iov(q, req, NULL, iter, GFP_KERNEL);
--


  reply	other threads:[~2026-04-09 14:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09  8:46 Non-SGL transport mode warnings are set to dev_warn_once will cause confusion AlanCui4080
2026-04-09 14:36 ` Keith Busch [this message]
2026-04-09 15:49   ` AlanCui4080
2026-05-06  4:10     ` AlanCui4080

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=ade5iAP4y94z0JDL@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=me@alancui.cc \
    /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.