linux-kernel - Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()

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]

Date: Sun, 5 May 2024 12:42:53 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Nathan Chancellor <nathan@...nel.org>, Kuan-Wei Chiu <visitorckw@...il.com>, 
	kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev, 
	Miguel Ojeda <ojeda@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()

On Fri, May 3, 2024 at 11:56 PM Yury Norov <yury.norov@...il.com> wrote:
>
> + * The __used attribute guarantees that the attributed variable will be

We should probably mention functions as Nathan said (unless it does
not work for some reason).

> + * always emitted by a compiler. It doesn't prevent the compiler from
> + * throwing the 'unused' warnings when it can't detect how the variable

Nit: "throwing the" -> "throwing" (I think)

Also, perhaps "when ..." -> "when it appears that the variable is not
used" like in the documentation of the attribute or similar? (e.g. in
the case that triggered the report, it is really unused, while one
could read this as the compiler not being able to detect a use
somewhere).

> + * is actually used. It's a compiler implementation details either emit
> + * the warning in that case or not.

Is it an implementation detail or rather that they took different
alternatives/options on purpose (even if not documented)? If we think
it is just a consequence of their implementation, perhaps we should
mention that and what GCC/Clang do today in their latest version, in
case it changes (so that we know whether we need to remove the macro,
for instance).

None of the above is a big deal though -- thanks!

Cheers,
Miguel