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: <ef7e9698-db22-40a9-afb7-7a5204c579ac@gmail.com>
Date: Wed, 19 Nov 2025 10:21:01 +0530
From: Nirbhay Sharma <nirbhay.lkd@...il.com>
To: o-takashi@...amocchi.jp
Cc: linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
 david.hunter.linux@...il.com,
 linux-kernel-mentees@...ts.linuxfoundation.org, skhan@...uxfoundation.org
Subject: Re: [PATCH] firewire: Replace ENOSYS with appropriate error codes

On 11/17/25 5:01 PM, Takashi Sakamoto wrote:
> Hi,
>   
> Yes. The newly-written code should not use ENOSYS for cadual use, indeed.
> 
>   
> 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

Hi Takashi,

Thank you for your detailed review and explanation.

You are absolutely right about the backward compatibility concern. I 
realize now that changing error codes in existing code paths could break 
userspace applications that might be checking for specific error values.

My patch was motivated by the checkpatch.pl warning and the general 
kernel policy that ENOSYS should only mean "invalid syscall number." 
BUt, I didn't fully consider the userspace ABI implications of changing 
error codes in code that's already been released.

I do not have a strong technical reason beyond code correctness to 
justify breaking backward compatibility in this case. Since these 
interfaces are already in use and userspace software may depend on the 
current behavior, the risk of breaking existing applications outweighs 
the benefit of this cleanup.

I withdraw this patch. Thank you for taking the time to explain this, 
its an important lesson about the difference between fixing issues in 
new code versus maintaining stability in existing interfaces.

Thanks,
Nirbhay