linux-kernel - Re: arm32 build warnings in workqueue.c

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]

Date:   Thu, 3 Aug 2023 12:23:46 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Petr Mladek <pmladek@...e.com>, Dave Airlie <airlied@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: arm32 build warnings in workqueue.c

Hello, Linus.

On Mon, Jul 31, 2023 at 12:22:06PM -0700, Linus Torvalds wrote:
> We do have that
> 
>    scripts/gdb/linux/constants.py.in
> 
> thing. Which seems to be the logical place do deal with this all.
> 
> That's where other - and arguably much more fundamental - kernel
> #define's are dealt with.
> 
> Now, looking at the particular constants that are listed, I get the
> feeling that the people who have done that script may be mostly
> interested in filesystems, but I don't see why it wouldn't be
> appropriate for the workstruct stuff too...

It can be used but there are some drawbacks:

* It requires maintaining external code, which usually doesn't scale that
  well, especially over extended period of time.

* It requires pre-processing header files and then evaluating the resulting
  C expressions. It's not a showstopper and some tools can already do so
  but, for example, to use this with drgn, we'd have to generate this into
  python expressions using something and then source it. Maybe we can
  prepackage the pre-processed results but things do get more complicated
  and likely more error-prone.

* This likely will cover some of the constants but there are also many which
  aren't readily visible in public header files. It is possible to try to
  preprocess .c files too but then now each machine has to have full source
  deployed and so on.

So, not that it's impossible but if you contrast this to having the
constants available in the debug info:

* There's only one source of truth. No external maintenance is needed.

* The tools already rely heavily on having debug info available for type
  information and the symbols. As needing debug info is pretty common, most
  distros and prod environments provide ready access to them, whether kernel
  or applications.

* Having constants in debug info doesn't add any complexity or point of
  possible mistakes. As long as the binary matches the debug info, which is
  a property that tools and environments watch and maintain closely and easy
  to notice when broken, you know that you're using the same numers as the
  running kernel, which is a huge relief.

The downside of using enums is that C's enum is not great in terms of type
predictability. I personally would much prefer specifying the types
explicitly, but, as long as the rules are stable, I think it's something we
can live with. While a bit annoying, the benefits of using them outweighs
the annoyances in general.

It's just so silly that constants of all the stuff we need for monitoring
and debugging are the one thing that we can't provide through debug info and
requires all the special, potentially fragile, workarounds.

Thanks.

-- 
tejun