Messages in this thread | | | Date | Mon, 6 Nov 2023 11:30:05 +0100 | Subject | Re: [PATCH] rfkill: return ENOTTY on invalid ioctl | From | Przemek Kitszel <> |
| |
On 11/2/23 20:14, Thomas Weißschuh wrote: > Hi! > > On 2023-11-02 09:57:45+0100, Przemek Kitszel wrote: >> On 11/1/23 20:41, Thomas Weißschuh wrote: >>> For unknown ioctls the correct error is >>> ENOTTY "Inappropriate ioctl for device". >> >> For sure! >> >> I would like to learn more of why this is not an UAPI breaking change? > > "break" would mean that some user application worked correctly before > but does not do so anymore with this change. > > This seems highly unlikely and I was not able to find such an > application via Debian code search. > > In general I did *not* mark this change for stable so if some > application would indeed break it gets detected before the patch hits > a release. > >>> >>> ENOSYS as returned before should only be used to indicate that a syscall >>> is not available at all. >>> >>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> >>> --- >>> net/rfkill/core.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/net/rfkill/core.c b/net/rfkill/core.c >>> index 14cc8fe8584b..c3feb4f49d09 100644 >>> --- a/net/rfkill/core.c >>> +++ b/net/rfkill/core.c >>> @@ -1351,11 +1351,11 @@ static long rfkill_fop_ioctl(struct file *file, unsigned int cmd, >>> unsigned long arg) >>> { >>> struct rfkill_data *data = file->private_data; >>> - int ret = -ENOSYS; >>> + int ret = -ENOTTY; >>> u32 size; >>> if (_IOC_TYPE(cmd) != RFKILL_IOC_MAGIC) >>> - return -ENOSYS; >>> + return -ENOTTY; >>> mutex_lock(&data->mtx); >>> switch (_IOC_NR(cmd)) { >>> >>> --- >>> base-commit: 7d461b291e65938f15f56fe58da2303b07578a76 >>> change-id: 20231101-rfkill-ioctl-enosys-00a2bb0a4ab1 >>> >>> Best regards, >>
Thanks!
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
| |