linux-kernel - Re: [PATCH v2] kdb: Make the internal env 'KDBFLAGS' undefinable

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]

Date:   Tue, 19 May 2020 22:11:11 +0800
From:   "liwei (GF)" <liwei391@...wei.com>
To:     Daniel Thompson <daniel.thompson@...aro.org>
CC:     Doug Anderson <dianders@...omium.org>,
        Jason Wessel <jason.wessel@...driver.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        <kgdb-bugreport@...ts.sourceforge.net>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kdb: Make the internal env 'KDBFLAGS' undefinable

Hi Daniel,

On 2020/5/19 19:40, Daniel Thompson wrote:
> On Sat, May 16, 2020 at 05:26:06PM +0800, Wei Li wrote:
>> 'KDBFLAGS' is an internal variable of kdb, it is combined by 'KDBDEBUG'
>> and state flags. But the user can define an environment variable named
>> 'KDBFLAGS' too, so let's make it undefinable to avoid confusion.
>>
>> Signed-off-by: Wei Li <liwei391@...wei.com>
>> Reviewed-by: Douglas Anderson <dianders@...omium.org>
> 
> I took a quick look at this and find myself thinking of KDBFLAGS as
> something of a misfeature.
> 
> I think I'd rather get kdb_env to show the value we wrote into
> KDBDEBUG.
> 
> Sure this means we cannot use KDBDEBUG to look at the least significant
> 16-bits but I think anyone who is debugging kdb itself should know
> enough to use `md4c1 kdb_flags` to read those anyway.
> 
> 

Agree. That will be more clear with no confusion. Currently,
KDBFLAGS will be shown only when KDBDEBUG is set, that is weird too.
So, let's just make it simple.
I can fix it as you suggested in the next post.

Thanks,
Wei