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  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

Powered by blists - more mailing lists