netdev - Re: [PATCH net] Fix u32's systematic failure to free IDR entries for hnodes.

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: <20241111200759.GM4507@kernel.org>
Date: Mon, 11 Nov 2024 20:07:59 +0000
From: Simon Horman <horms@...nel.org>
To: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Pedro Tammela <pctammela@...atatu.com>, edumazet@...gle.com,
	jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us,
	netdev@...r.kernel.org
Subject: Re: [PATCH net] Fix u32's systematic failure to free IDR entries for
 hnodes.

On Sun, Nov 10, 2024 at 04:40:26PM +0100, Alexandre Ferrieux wrote:
> On 10/11/2024 15:00, Simon Horman wrote:
> > On Mon, Nov 04, 2024 at 10:51:01PM +0100, Alexandre Ferrieux wrote:
> >> 
> >> I believe you mean "let the compiler decide whether to _inline_ it or not".
> >> Sure, with a sufficiently modern Gcc this will do. However, what about more
> >> exotic environments ? Wouldn't it risk a perf regression for style reasons ?
> >> 
> >> And speaking of style, what about the dozens of instances of "static inline" in
> >> net/sched/*.c alone ? Why is it a concern suddenly ?
> > 
> > Hi Alexandre,
> > 
> > It's not suddenly a concern. It is a long standing style guideline for
> > Networking code, even if not always followed. Possibly some of the code
> > you have found in net/sched/*.c is even longer standing than the
> > guideline.
> > 
> > Please don't add new instances of inline to .c files unless there is a
> > demonstrable - usually performance - reason to do so.
> 
> Sure, I will abide in the next version :)
> 
> That said, please note it is hard to understand why such a rule would be
> enforced both locally and tacitly. Things would be entirely different if it were
> listed in coding-style.rst, advertising both consensus and wide applicability.

Thanks,

I completely agree that it would be better if it was documented somewhere.
I will add that to my TODO list.