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]
Message-ID: <2f48008d-b05d-48b0-bba1-f37ed59301b7@siemens.com>
Date: Fri, 20 Jun 2025 07:50:52 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>,
 Stephen Brennan <stephen.s.brennan@...cle.com>,
 Tony Ambardar <tony.ambardar@...il.com>, linux-kernel@...r.kernel.org,
 linux-debuggers@...r.kernel.org
Cc: Kieran Bingham <kbingham@...nel.org>,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v1] scripts/gdb: fix parsing of MNT_* constants

On 19.06.25 23:51, Florian Fainelli wrote:
> On 6/3/25 09:17, Florian Fainelli wrote:
>> On 6/2/25 21:42, Stephen Brennan wrote:
>>> On 5/31/25 22:50, Tony Ambardar wrote:
>>>> Recently, constants in linux/mount.h were changed from integer macros
>>>> parsable by LX_VALUE() to enums which are not, thus breaking gdb python
>>>> scripts:
>>>>
>>>>    Reading symbols from vmlinux...
>>>>    Traceback (most recent call last):
>>>>      File ".../linux/vmlinux-gdb.py", line 25, in <module>
>>>>        import linux.constants
>>>>      File ".../linux/scripts/gdb/linux/constants.py", line 19, in
>>>> <module>
>>>>        LX_MNT_NOSUID = MNT_NOSUID
>>>>    NameError: name 'MNT_NOSUID' is not defined
>>>>
>>>> Update to parse with LX_GDBPARSED(), which correctly handles enums.
>>>>
>>>> Fixes: 101f2bbab541 ("fs: convert mount flags to enum")
>>>> Signed-off-by: Tony Ambardar <tony.ambardar@...il.com>
>>>
>>> Hi Tony,
>>>
>>> I was totally unaware that these constants were being consumed by
>>> another debugger, and having fixed them for one, I broke them for
>>> another!
>>>
>>> Thanks for the fix. Having read through the preprocessor magic and this
>>> change, they make sense to me. In the future, I'll be sure to make an
>>> extra check for GDB users when updating enums.
>>>
>>> Reviewed-by: Stephen Brennan <stephen.s.brennan@...cle.com>
>>
>> Not targeted to anyone in particular but this is a recurring problem,
>> the GDB scripts are typically not part of any CI and it is not natural
>> to grep for constant names outside of the C/Rust code where they are
>> being used...
>>
>> I suppose that QEMU it should be much easier to ensure that GDB
>> scripts are being exercised than with my current set-up using OpenOCD
>> + real hardware...
> 
> And also:
> 
> Tested-by: Florian Fainelli <florian.fainelli@...adcom.com>
> 
> Jan, Kieran, can you please pick this up? Thanks!

Thanks for all the fixes. The version of Johannes has already been 
queued up by Andrew:

https://lore.kernel.org/mm-commits/20250618223437.C3BB2C4CEE7@smtp.kernel.org/T/#u

Regarding automated testing: This would indeed be a valuable addition. 
Some QEMU-based tests should suffice, but I do not know where those 
could be best hooked into for broad visibility. To my understanding, 
KernelCI is right now focusing on single device boot tests, and we would 
rather need some backend/frontend test setup here even when only using a 
virtual device. Some self-built pipeline could provide that as well - 
but where/how to report findings then? Ideas welcome.

And then it would obviously also need some folks willing to contribute 
the actual test cases.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ