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: <9662e6fe-cc91-4258-aba1-ab5b016a041a@orange.com>
Date: Sun, 10 Nov 2024 16:40:26 +0100
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: Simon Horman <horms@...nel.org>,
 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 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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ