linux-kernel - Re: [PATCH 29/33] serial: 8250: drop DEBUG

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: <2025061733-pushy-croon-08da@gregkh>
Date: Tue, 17 Jun 2025 13:42:02 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Jiri Slaby (SUSE)" <jirislaby@...nel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 29/33] serial: 8250: drop DEBUG_AUTOCONF() macro

On Tue, Jun 17, 2025 at 12:32:48PM +0100, Maciej W. Rozycki wrote:
> On Wed, 11 Jun 2025, Jiri Slaby (SUSE) wrote:
> 
> > DEBUG_AUTOCONF() is always disabled (by "#if 0"), so one would need to
> > recompile the kernel to use it. And even if they did, they would find
> > out it is broken anyway:
> >   error: variable 'scratch' is used uninitialized whenever 'if' condition is false
> 
>  This is removing useful debugging aids.

How can it be "useful" if it's broken and no one has ever reported that?

>  The issue with compilation is related to commit 3398cc4f2b15 ("serial: 
> 8250: Add IIR FIFOs enabled field properly"), which removed the assignment 
> of IIR to `scratch' (although a path did exist before it that bypassed the 
> assignment anyway), and can be trivially fixed by bringing the assignment 
> back and moving the debug statement next to it.

So it's been broken for over 2 years and no one has asked for it to be
fixed?

>  I agree that "#if 0" isn't very useful as it requires patching the source 
> to activate; changing it to "#ifdef DEBUG" would make more sense nowadays.

No, dynamic debugging is the proper solution, not build-time stuff.  If
you really need/want this, add it back in that way, not this old-style
"let's rebuild the whole kernel" type of thing.  This isn't the 1990's
anymore :)

thanks,

greg k-h