linux-kernel - Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_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]

Date:   Thu, 9 Nov 2017 06:44:49 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Tony Lindgren <tony@...mide.com>, letux-kernel@...nphoenux.org,
        linux-kernel@...r.kernel.org, kernel@...a-handheld.com,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

Hi Russel,

> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux <linux@...linux.org.uk>:
> 
> On Wed, Nov 08, 2017 at 10:36:04PM +0000, Russell King - ARM Linux wrote:
>> We don't need a compiler warning there, we probably need better help
>> text against DEBUG_LL and against EARLY_PRINTK.
> 
> Actually, this is already clearly stated against DEBUG_LL:
> 
>          Note that selecting this option will limit the kernel to a single
>          UART definition, as specified below. Attempting to boot the kernel
>          image on a different platform *will not work*, so this option should
>          not be enabled for kernels that are intended to be portable.
> 
> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> read help texts anymore.

Yes, we read, but we face a situation where it doesn't help that it is a
well known problem *for you* or anyone else and that it is described in the help.

We simply had a private defconfig for years and someone enabled DEBUG_LL some
years ago and it worked.

Then we upgrade the kernel for every -rc and it continued to work well. Then,
recently when doing just one update the compiled kernel failed to boot. Nobody
did change and look at the defconfig and its help. We just merged the latest
patches from linus/master.

Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL what
was written in a help message? Or to understand that DEBUG_LL has anything to
do with the mysteriously appearing boot problem? Which can't easily be debugged
since there are no messages despite playing with EARLY_PRINTK/EARLYCON?

It took me several hours of git bisect to find out the problematic commits
and needed help by the author to relate it to DEBUG_LL in the defconfig.

So we are coming from the other end with much less knowledge than you have.
Linux has grown to be a beast that only a handful of people fully understand.
And this patch is to help those poor production kernel maintainers like me
who don't...

A technically different solution would be to automatically disable DEBUG_LL
if it is not compatible with some other setting.

BTW it appears that there was similar code elsewhere long time ago:

http://elixir.free-electrons.com/linux/v3.1.10/source/arch/arm/plat-mxc/include/mach/debug-macro.S

BR and thanks,
Nikolaus Schaller