From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Geoffrey McRae <geoffrey.mcrae@amd.com>,
Alex Deucher <alexander.deucher@amd.com>,
Felix Kuehling <felix.kuehling@amd.com>,
Sasha Levin <sashal@kernel.org>,
Felix.Kuehling@amd.com, amd-gfx@lists.freedesktop.org
Subject: [PATCH AUTOSEL 6.17-5.4] drm/amdkfd: return -ENOTTY for unsupported IOCTLs
Date: Sat, 25 Oct 2025 12:00:12 -0400 [thread overview]
Message-ID: <20251025160905.3857885-381-sashal@kernel.org> (raw)
In-Reply-To: <20251025160905.3857885-1-sashal@kernel.org>
From: Geoffrey McRae <geoffrey.mcrae@amd.com>
[ Upstream commit 57af162bfc8c05332a28c4d458d246cc46d2746d ]
Some kfd ioctls may not be available depending on the kernel version the
user is running, as such we need to report -ENOTTY so userland can
determine the cause of the ioctl failure.
Signed-off-by: Geoffrey McRae <geoffrey.mcrae@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
YES
- What changed
- Unsupported amdkfd ioctls now return -ENOTTY instead of the previous
default -EINVAL on two early error paths:
- When `_IOC_NR(cmd)` is beyond the table: `nr >=
AMDKFD_CORE_IOCTL_COUNT` now sets `retcode = -ENOTTY` before `goto
err_i1` (drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:3256).
- When the ioctl number is outside the defined KFD command range:
the `else` branch after the `(nr >= AMDKFD_COMMAND_START) && (nr <
AMDKFD_COMMAND_END)` check now sets `retcode = -ENOTTY` before
`goto err_i1` (drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:3270).
- Prior to this change, both paths fell through with `retcode`
initialized to -EINVAL
(drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:3253).
- Why it matters
- KFD adds ioctls over time; user space built against newer headers
may issue an ioctl unknown to an older kernel. Returning -ENOTTY is
the canonical “inappropriate ioctl for device/unsupported ioctl”
signal, allowing user space to distinguish “unsupported on this
kernel” from “bad arguments to a supported ioctl” (which should be
-EINVAL).
- This aligns KFD’s error semantics with kernel ioctl conventions used
elsewhere. For example, DRM core returns -ENOTTY for unsupported
ioctl types (drivers/gpu/drm/drm_ioctl.c:782), and many drivers use
-ENOTTY to indicate unsupported ioctls.
- Scope and risk
- Change is small and tightly scoped to `kfd_ioctl` error handling for
unsupported commands only
(drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:3244).
- No architectural changes, no new UAPI or features, and no functional
change for supported ioctls.
- Potential regression risk is low: only the errno for “unsupported
ioctl” changes from -EINVAL to -ENOTTY. Well-behaved user space
should treat -ENOTTY (not -EINVAL) as the indicator for an
unsupported ioctl. This is correcting an API bug rather than
changing intended behavior.
- Security impact is nil; control flow and data handling are
unchanged.
- Stable backport criteria
- Fixes a real user-visible bug: ambiguous errno on unsupported ioctls
made feature detection and fallback logic in userland unreliable.
- Minimal, self-contained patch limited to amdkfd.
- No side effects beyond improving errno correctness for unsupported
ioctls.
- Consistent with prior amdkfd errno cleanups (e.g., “Return proper
error code for gws alloc API”) and general kernel ioctl practices.
Given these points, this is a good, low-risk candidate for stable
backport.
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 828a9ceef1e76..79ed3be63d0dd 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -3252,8 +3252,10 @@ static long kfd_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
int retcode = -EINVAL;
bool ptrace_attached = false;
- if (nr >= AMDKFD_CORE_IOCTL_COUNT)
+ if (nr >= AMDKFD_CORE_IOCTL_COUNT) {
+ retcode = -ENOTTY;
goto err_i1;
+ }
if ((nr >= AMDKFD_COMMAND_START) && (nr < AMDKFD_COMMAND_END)) {
u32 amdkfd_size;
@@ -3266,8 +3268,10 @@ static long kfd_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
asize = amdkfd_size;
cmd = ioctl->cmd;
- } else
+ } else {
+ retcode = -ENOTTY;
goto err_i1;
+ }
dev_dbg(kfd_device, "ioctl cmd 0x%x (#0x%x), arg 0x%lx\n", cmd, nr, arg);
--
2.51.0
next prev parent reply other threads:[~2025-10-25 16:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251025160905.3857885-1-sashal@kernel.org>
2025-10-25 15:54 ` [PATCH AUTOSEL 6.17] amd/amdkfd: enhance kfd process check in switch partition Sasha Levin
2025-10-25 15:54 ` [PATCH AUTOSEL 6.17-6.12] drm/amdgpu: fix nullptr err of vm_handle_moved Sasha Levin
2025-10-25 15:55 ` [PATCH AUTOSEL 6.17-6.1] drm/amdgpu: Allow kfd CRIU with no buffer objects Sasha Levin
2025-10-25 15:57 ` [PATCH AUTOSEL 6.17] drm/amd/pm: refine amdgpu pm sysfs node error code Sasha Levin
2025-10-25 15:58 ` [PATCH AUTOSEL 6.17-6.6] drm/amdkfd: Handle lack of READ permissions in SVM mapping Sasha Levin
2025-10-25 15:59 ` [PATCH AUTOSEL 6.17-6.6] amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw Sasha Levin
2025-10-25 16:00 ` Sasha Levin [this message]
2025-10-25 16:00 ` [PATCH AUTOSEL 6.17-6.1] drm/amdkfd: fix vram allocation failure for a special case Sasha Levin
2025-10-25 16:00 ` [PATCH AUTOSEL 6.17-5.4] drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption Sasha Levin
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-381-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=geoffrey.mcrae@amd.com \
--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