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: <771bd976-e68c-48d0-bfbd-1f1b73d7bb91@linux.dev>
Date: Tue, 5 Nov 2024 23:42:14 +0000
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: 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 05/11/2024 22:14, Alexandre Ferrieux wrote:
>> On 04/11/2024 22:33, Vadim Fedorenko wrote:
>>>> On 04/11/2024 18:00, Pedro Tammela wrote:
>>>>> '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 ?
> 
> Can you please explain *why* in the first place you're saying "'static inline'
> is discouraged in .c files" ? I see no trace if this in coding-style.rst, and
> the kernel contains hundreds of counter-examples.

The biggest reason is because it will mask unused function warnings when
"static inline" function will not be used because of some future
patches. There is no big reason to refactor old code that's why there
are counter-examples in the kernel, but the new code shouldn't have it.

I don't really understand what kind of exotic environment you are
thinking about, but modern kernel has proper gcc/clang version
dependency, both of these compilers have good heuristics to identify
which function to inline.