netdev - RE: [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages

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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 6 Feb 2024 22:50:25 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, "Brady, Alan" <alan.brady@...el.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"willemdebruijn.kernel@...il.com" <willemdebruijn.kernel@...il.com>,
	"Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>, "Bagnucki, Igor"
	<igor.bagnucki@...el.com>, "Lobakin, Aleksander"
	<aleksander.lobakin@...el.com>
Subject: RE: [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Tuesday, February 6, 2024 12:03 PM
> To: Brady, Alan <alan.brady@...el.com>
> Cc: intel-wired-lan@...ts.osuosl.org; netdev@...r.kernel.org;
> willemdebruijn.kernel@...il.com; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>; Bagnucki, Igor <igor.bagnucki@...el.com>;
> Lobakin, Aleksander <aleksander.lobakin@...el.com>
> Subject: Re: [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages
> 
> On Tue, 6 Feb 2024 11:18:48 -0800 Alan Brady wrote:
> > We did run coccinelle check and see the min suggestions. It's triggering
> > on these statements I added:
> >
> > return reply_sz < 0 ? reply_sz : 0;
> >
> > A min here would change it to:
> >
> > return min(reply_sz, 0);
> >
> > I didn't really like that because it's misleading as though we're
> > returning the size of the reply and might accidentally encourage someone
> > to change it to a max. Here reply_sz will be negative if an error was
> > returned from message sending. But this function we only want to return
> > 0 or negative. By being explicit in what we want to do, it seems clearer
> > to me what the intention is but I could be wrong.
> >
> > We can definitely change it however if that's preferred here.
> 
> Hm, okay, that does sound like making it worse.
> I'll disable the minmax coccicheck for now, it seems noisy.

Maybe you could make the coccicheck only complain if the value is non-zero or not const? Maybe that's a bit too complicated... Hm