public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Alex Mastro <amastro@fb.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Sasha Levin <sashal@kernel.org>,
	alex@shazbot.org, kvm@vger.kernel.org
Subject: [PATCH AUTOSEL 6.17-6.1] vfio: return -ENOTTY for unsupported device feature
Date: Sat, 25 Oct 2025 12:00:07 -0400	[thread overview]
Message-ID: <20251025160905.3857885-376-sashal@kernel.org> (raw)
In-Reply-To: <20251025160905.3857885-1-sashal@kernel.org>

From: Alex Mastro <amastro@fb.com>

[ Upstream commit 16df67f2189a71a8310bcebddb87ed569e8352be ]

The two implementers of vfio_device_ops.device_feature,
vfio_cdx_ioctl_feature and vfio_pci_core_ioctl_feature, return
-ENOTTY in the fallthrough case when the feature is unsupported. For
consistency, the base case, vfio_ioctl_device_feature, should do the
same when device_feature == NULL, indicating an implementation has no
feature extensions.

Signed-off-by: Alex Mastro <amastro@fb.com>
Link: https://lore.kernel.org/r/20250908-vfio-enotty-v1-1-4428e1539e2e@fb.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- `drivers/vfio/vfio_main.c:1255` now returns `-ENOTTY` when
  `device->ops->device_feature` is NULL, matching the documented
  optional nature of that callback (`include/linux/vfio.h:137`), so
  users probing for vendor/device extensions on drivers without feature
  support get the expected “unsupported ioctl” error instead of the
  misleading `-EINVAL`.
- Existing feature implementations already signal “unsupported” with
  `-ENOTTY` (for example `drivers/vfio/pci/vfio_pci_core.c:1518` and
  `drivers/vfio/cdx/main.c:79`), so the change restores API consistency
  and lets user space rely on a single return code when checking for
  absent features.
- The bug has been present since the core feature decoder was introduced
  (commit 445ad495f0ff), leading to real user-visible confusion where
  `VFIO_DEVICE_FEATURE_PROBE` can’t distinguish between bad arguments
  and an unsupported feature on simpler devices.
- The fix is trivially small, has no dependencies, and only adjusts an
  errno in one fallback path, so regression risk for stable kernels is
  negligible while improving correctness for existing VFIO users.

 drivers/vfio/vfio_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 5046cae052224..715368076a1fe 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1251,7 +1251,7 @@ static int vfio_ioctl_device_feature(struct vfio_device *device,
 			feature.argsz - minsz);
 	default:
 		if (unlikely(!device->ops->device_feature))
-			return -EINVAL;
+			return -ENOTTY;
 		return device->ops->device_feature(device, feature.flags,
 						   arg->data,
 						   feature.argsz - minsz);
-- 
2.51.0


      parent reply	other threads:[~2025-10-25 16:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20251025160905.3857885-1-sashal@kernel.org>
2025-10-25 15:55 ` [PATCH AUTOSEL 6.17] vfio/nvgrace-gpu: Add GB300 SKU to the devid table Sasha Levin
2025-10-25 15:56 ` [PATCH AUTOSEL 6.17-5.10] x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of PV_UNHALT Sasha Levin
2025-10-25 15:58 ` [PATCH AUTOSEL 6.17] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Sasha Levin
2025-10-26 22:24   ` Huang, Kai
2025-11-03  9:26     ` Huang, Kai
2025-11-04 14:46       ` Sasha Levin
2025-11-04 21:27         ` Huang, Kai
2025-10-25 15:59 ` [PATCH AUTOSEL 6.17] x86/virt/tdx: Mark memory cache state incoherent when making SEAMCALL Sasha Levin
2025-10-26 22:25   ` Huang, Kai
2025-10-28 17:49     ` Sasha Levin
2025-10-25 16:00 ` [PATCH AUTOSEL 6.17] x86/virt/tdx: Use precalculated TDVPR page physical address Sasha Levin
2025-10-25 16:00 ` Sasha Levin [this message]

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=20251025160905.3857885-376-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=alex@shazbot.org \
    --cc=amastro@fb.com \
    --cc=kvm@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /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