netdev - Re: [QUERY] mctp: getsockopt unknown option return code -EINVAL

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: <a8c2dd5d8f72820941a3f4d660db3076ff9a8b52.camel@codeconstruct.com.au>
Date: Tue, 02 Sep 2025 11:59:02 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: ALOK TIWARI <alok.a.tiwari@...cle.com>, matt@...econstruct.com.au, 
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com,  horms@...nel.org, netdev@...r.kernel.org
Subject: Re: [QUERY] mctp: getsockopt unknown option return code -EINVAL

Hi Alok,

> I was not looking at a specific path, I just noticed the
> inconsistency in the return codes between getsockopt and setsockopt.
> 
> Extending this to the level != SOL_MCTP case would also require
> changes in the mctp_setsockopt() API.

Yep. The changes to the level error path may have different semantics,
so if you'd prefer to look at that separately, that's fine.

> Also, would it be fine if I send this patch to [net-next] without a 
> Fixes tag?

All fine by me.

We're fairly safe from any side-effects here, as we only have the one
sockopt, but we do want to ensure that remains the case in future,
particularly if any new sockopts are introduced.

Cheers,

Jeremy