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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZMgIF_6zCqB0LfjN@slm.duckdns.org>
Date:   Mon, 31 Jul 2023 09:14:31 -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,

On Mon, Jul 31, 2023 at 11:40:04AM -0700, Linus Torvalds wrote:
> So I think the whole "gdb debug info" argument is complete garbage,
> and was never true at all. If you want gdb to know about these
> constants, you just do the same thing that gdb users already have to
> do for other things.

When manually debugging with gdb, figuring out these constants might not add
too much overhead on top but nowadays there are many other tools which can
benefit from having the source of truth available to them directly from the
kernel.

For example, it's a lot easier to write non-trivial debug scripts with drgn
(https://github.com/osandov/drgn) and it's not too unusual to have a
collection of bcc / bpftrace scripts for diagnosing common problems. They of
course don't have any interface stability expectations. However, there's no
reason to make using them unnecessarily painful given how useful they are.
Having constant values included in the kernel debug info makes it a lot
easier to use these tools and removes a silly source of subtle problems.

> And honestly, I don't understand why anybody seriously believes that
> those WORK_STRUCT constants are somehow very important. We have many
> *much* more fundamental constants that are #define's. Thinking that
> WORK_OFFQ_CANCELING needs special gdb understanding when we have
> PAGE_SIZE that does not seems entirely crazy to me.

PAGE_SIZE is easily available through _SC_PAGE_SIZE, so that particular one
is never a real problem (and a lot of tools have pre-defined helpers for it
and similarly important constants) but yeah there are other constants which
I sometimes wish were available through debug info.

It may be difficult to argue specifically for WORK_OFFQ_CANCELING in
isolation as it is directly derived from __WORK_OFFQ_CANCELNG, so no problem
there, but I hope you can see that having these constants available in debug
info in general is useful.

Even here, the value of __WORK_OFFQ_CANCELING is dependent on
CONFIG_DEBUG_OBJECTS_WORK. It's not a strong case as the option is pretty
specifically for debugging but if one is to actually debug or monitor
workqueue using external visibility tools, this can easily lead to mistakes.

Thanks.

-- 
tejun