linux-ext4 - Re: [PATCH v2] ext4: Enable code path when DX

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:   Mon, 1 Feb 2021 13:16:19 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Vinicius Tinti <viniciustinti@...il.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Nathan Chancellor <natechancellor@...il.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Mon, Feb 1, 2021 at 1:09 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Mon, Feb 01, 2021 at 03:41:50PM -0300, Vinicius Tinti wrote:
> >
> > My goal is to avoid having a dead code. Three options come to mind.
> >
> > The first would be to add another #ifdef SOMETHING (suggest a name).
> > But this doesn't remove the code and someone could enable it by accident.
>
> I *really* don't see the point of having the compiler whine about
> "dead code", so I'm not terribly fond of
> -Wunreachable-code-aggressive.

I agree; Vinicius, my recommendation for -Wunreachable-* with Clang
was to see whether dead code identified by this more aggressive
diagnostic (than -Wunused-function) was to ask maintainers whether
code identified by it was intentionally dead and if they would
consider removing it.  If they say "no," that's fine, and doesn't need
to be pushed.  It's not clear to maintainers that:
1. this warning is not on by default
2. we're not looking to pursue turning this on by default

If maintainers want to keep the dead code, that's fine, let them and
move on to the next instance to see if that's interesting (or not).
-- 
Thanks,
~Nick Desaulniers