linux-kernel - Re: [PATCH] Makefile.extrawarn: re-enable -Wformat for clang

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YugYbvRu1xqnx6mC@dev-arch.thelio-3990X>
Date:   Mon, 1 Aug 2022 11:16:14 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Justin Stitt <justinstitt@...gle.com>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tom Rix <trix@...hat.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <llvm@...ts.linux.dev>
Subject: Re: [PATCH] Makefile.extrawarn: re-enable -Wformat for clang

On Mon, Aug 01, 2022 at 10:40:29AM -0700, Justin Stitt wrote:
> > OK, I think that will be good timing.
> > Please ping me if I forget to pick it up.
> >
> Hey Masahiro, just pinging to see the state of this PR.
> 
> I think we are on pace to re-enable this warning.
> 
> I believe there exists only _two_ patches left still needing to go
> through along with this patch:
> 1) https://lore.kernel.org/all/20220718050356.227647-1-hch@lst.de/

This is now in the block tree, so it should be squared away:

https://lore.kernel.org/YuFhR9OoPvM9VsdT@infradead.org/

Stephen is on vacation so -next hasn't updated for a few days but it
sounds like Mark is going to provide some coverage:

https://lore.kernel.org/YugAzWWl++ArhhPS@sirena.org.uk/

> 2) https://lore.kernel.org/all/YtnDltqEVeJQQkbW@dev-arch.thelio-3990X/

We need to chase this, as I haven't seen an "applied" email. We have two
options:

1. Ask the maintainers to apply the change to their branch directly.
2. Ask them for an "Ack" so that we can apply that change along with
   this one.

It is worth a ping asking which they prefer. The first option is
simpler, as the change that introduced the warning is only in -next so
it can just be applied to the same branch; the only concern is making
sure that change makes -rc1. The second option gives us more flexibility
with enabling the warning in the event that the change missed being
added to the main pull request but it will require basing the change on
a non-rc base, which most maintainers don't really like.

It is ultimately up to Masahiro but my vision is:

1. Ping the patch, asking how to proceed.
2. If the maintainers can pick it up and it will make the merge window,
   let them apply it then apply this patch to the Kbuild tree for -next.
3. If they prefer the "Ack" route, wait until mainline contains the
   problematic patch then apply the warning fix patch and this patch to
   the Kbuild tree on top of the problematic merge.
4. Wait until all other patches are in mainline (I can watch mainline
   and build it continuously) then pull request the branch containing
   whatever changes we need.

Masahiro, does that sound reasonable?

Cheers,
Nathan