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: <46ddc6aa-486e-4080-a89b-365340ef7c54@gmail.com>
Date: Mon, 4 Nov 2024 22:51:01 +0100
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
 Alexandre Ferrieux <alexandre.ferrieux@...il.com>,
 Pedro Tammela <pctammela@...atatu.com>, edumazet@...gle.com
Cc: 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 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 ?

> But in either
> cases use u32 as types to be consistent with other types in the
> functions you modify.

Ok.