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: <7cbd8419-2c74-4201-b5a3-7b88c3ec83fe@gmail.com>
Date: Wed, 6 Nov 2024 11:15:56 +0100
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
 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 06/11/2024 00:42, Vadim Fedorenko wrote:
> On 05/11/2024 22:14, Alexandre Ferrieux wrote:
>> 
>> 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.

A macro doesn't elicit unused function warnings either, so this looks like a
very weak motivation. While coding-style.rst explicitly encourages to use static
inline instead of macros, as they have better type checking and syntaxic isolation.

Regarding old vs new code, below are the last two month's fresh commits of
"static inline" in *.c. So it looks like the motivation is not shared by other
maintainers. Do we expect to see "local styles" emerge ?

$ git log --pretty='%h %as %ae'   -p | gawk
'/^[0-9a-f]{12}/{c=$0;next}/^diff/{f=$NF;next}/^[+].*static.inline/{if
(f~/[.]c$/){print c "\t"gensub(/.*\//,"","1",f)}}'

baa802d2aa5c 2024-10-21 daniel@...earbox.net    verifier_const.c
baa802d2aa5c 2024-10-21 daniel@...earbox.net    verifier_const.c
d1744a4c975b 2024-10-21 bp@...en8.de    amd.c
d1744a4c975b 2024-10-21 bp@...en8.de    amd.c
a6e0ceb7bf48 2024-10-11 sidhartha.kumar@...cle.com      maple.c
78f636e82b22 2024-09-25 freude@...ux.ibm.com    ap_queue.c
19773ec99720 2024-10-07 kent.overstreet@...ux.dev       disk_accounting.c
9b23fdbd5d29 2024-09-29 kent.overstreet@...ux.dev       inode.c
9b23fdbd5d29 2024-09-29 kent.overstreet@...ux.dev       inode.c
3d5854d75e31 2024-09-30 agordeev@...ux.ibm.com  kcore.c
3d5854d75e31 2024-09-30 agordeev@...ux.ibm.com  kcore.c
38864eccf78b 2024-09-30 kent.overstreet@...ux.dev       fsck.c
d278a9de5e18 2024-10-02 perex@...ex.cz  init.c
f811b83879fb 2024-10-02 mpatocka@...hat.com     dm-verity-target.c
4c411cca33cf 2024-09-13 artem.bityutskiy@...ux.intel.com        intel_idle.c
42268ad0eb41 2024-09-24 tj@...nel.org   ext.c
56bcd0f07fdb 2024-09-05 snitzer@...nel.org      localio.c
1b11c4d36548 2024-09-01 kent.overstreet@...ux.dev       ec.c
7a51608d0125 2024-09-04 kent.overstreet@...ux.dev       btree_cache.c
7a51608d0125 2024-09-04 kent.overstreet@...ux.dev       btree_cache.c
691f2cba2291 2024-09-05 kent.overstreet@...ux.dev       btree_cache.c