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

Message-ID: <20241110140017.GS4507@kernel.org>
Date: Sun, 10 Nov 2024 14:00:17 +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 Mon, Nov 04, 2024 at 10:51:01PM +0100, Alexandre Ferrieux wrote:
> On 04/11/2024 22:33, Vadim Fedorenko wrote:
> > On 04/11/2024 20:26, Alexandre Ferrieux wrote:
> >> On 04/11/2024 18:00, Pedro Tammela wrote:
> >>>>
> >>>> Signed-off-by: Alexandre Ferrieux <alexandre.ferrieux@...nge.com>
> >>>
> >>> SoB does not match sender, probably missing 'From:' tag
> >> 
> >> Due to dumb administrativia at my organization, I am compelled to post from my
> >> personal gmail accout in order for my posts to be acceptable on this mailing
> >> list; while I'd like to keep my official address in commit logs. Is it possible ?
> > 
> > Yes, it's possible, the author of commit in your local git should use
> > email account of company, then git format-patch will generate proper header.
> 
> That's exactly what I did, and the file generated by format-patch does have the
> proper From:, but it gets overridden by Gmail when sending. That's why, as a
> last resort, I tried Signed-off-by... Any hope ?
> 
> > you can add
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> 
> Ok.
> 
> >>> 'static inline' is discouraged in .c files
> >> 
> >> Why ?
> >> 
> >> It could have been a local macro, but an inline has (a bit) better type
> >> checking. And I didn't want to add it to a .h that is included by many other
> >> unrelated components, as it makes no sense to them. So, what is the recommendation ?
> > 
> > Either move it to some local header file, or use 'static u32 
> > handle2id(u32 h)'
> > and let compiler decide whether to include it or not.
> 
> 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.

Thanks!