linux-kernel - Re: [PATCH] firewire: Replace ENOSYS with appropriate error codes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251117113107.GA663208@workstation.local>
Date: Mon, 17 Nov 2025 20:31:07 +0900
From: Takashi Sakamoto <o-takashi@...amocchi.jp>
To: Nirbhay Sharma <nirbhay.lkd@...il.com>
Cc: linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	skhan@...uxfoundation.org, david.hunter.linux@...il.com,
	linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH] firewire: Replace ENOSYS with appropriate error codes

Hi,

On Mon, Nov 17, 2025 at 04:39:01PM +0530, Nirbhay Sharma wrote:
> ENOSYS is reserved for "invalid syscall number" and should not be used
> for other error conditions. Replace incorrect usages with more
> appropriate error codes:
 
Yes. The newly-written code should not use ENOSYS for cadual use, indeed.

> - In sbp2.c: Use -EOPNOTSUPP for unsupported operation (re-adding
>   logical units via SCSI stack).
> 
> - In ohci.c: Use -EINVAL for invalid ISO context types in switch
>   statements, and -EOPNOTSUPP for unsupported Pinnacle MovieBoard
>   hardware.
> 
> - In core-cdev.c: Use -EACCES for access policy violations when
>   operations are restricted to local nodes' device files.
>
> Signed-off-by: Nirbhay Sharma <nirbhay.lkd@...il.com>
> ---
>  drivers/firewire/core-cdev.c | 6 +++---
>  drivers/firewire/ohci.c      | 8 ++++----
>  drivers/firewire/sbp2.c      | 2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)
 
There is a rest to discuss when changing existing code in respect to
this topic, since it brings loss of backward-compatibility to userspace
software. In this reason, I've left them as is.

If there are any strong and specific reasons to correct them, let us
change them. Do you have such reasons? For example, Linux kernel
developer have shared the consensus and decision to ostracize such codes?


Thanks

Takashi Sakamoto