linux-kernel - Re: No care given to GDB scripts..

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: <20231129150629.0a82efbfc1494972e4e4f8cb@linux-foundation.org>
Date:   Wed, 29 Nov 2023 15:06:29 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        Kieran Bingham <kbingham@...nel.org>,
        Shanker Donthineni <sdonthineni@...dia.com>,
        Kuan-Ying Lee <Kuan-Ying.Lee@...iatek.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
Subject: Re: No care given to GDB scripts..

On Wed, 29 Nov 2023 14:48:02 -0800 Florian Fainelli <f.fainelli@...il.com> wrote:

> Hello,
> 
> It is quite clear that there are zero cares being given to making sure 
> that GDB scripts continue to work after making changes to core kernel 
> code, and why would you, because you probably did not know those 
> existed, but they do and they are used, and useful.
> 
> A recent example that was fixed by Kuan-Ying is this:
> 
> and now of course, "lx-interupts" also stopped working altogether after 
> this change:
> 
> https://lore.kernel.org/r/20230519134902.1495562-4-sdonthineni@nvidia.com
> 
> and who knows what else I could not test that is also broken.
> 
> We really need to find a better way to stop breaking GDB scripts, they 
> break way too often to be even remotely usable, and this is really sad.
> 
> It is also quite clear that we do not have enough continuous integration 
> and regression testing to ensure those breakages are caught ahead of time...
> 

This isn't terribly surprising - the gdb scripts are a pretty remote
corner and are peculiarly sensitive to getting damaged by routine
kernel development.

Is there any way of scripting the scripts so we can have some sort of
automated testing down under tools/testing/selftests/?