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
prev 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