[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191101212857.GA889092@rikard>
Date: Fri, 1 Nov 2019 22:28:57 +0100
From: Rikard Falkeborn <rikard.falkeborn@...il.com>
To: Rikard Falkeborn <rikard.falkeborn@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, bp@...en8.de,
joe@...ches.com, johannes@...solutions.net, keescook@...omium.org,
linux-kernel@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
yamada.masahiro@...ionext.com,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Haren Myneni <haren@...ibm.com>
Subject: Re: [Patch v4 2/2] linux/bits.h: Add compile time sanity check of
GENMASK inputs
On Tue, Oct 22, 2019 at 09:53:06PM +0200, Rikard Falkeborn wrote:
> On Fri, Oct 11, 2019 at 07:27:37PM -0700, Andrew Morton wrote:
> > On Wed, 9 Oct 2019 23:45:02 +0200 Rikard Falkeborn <rikard.falkeborn@...il.com> wrote:
> >
> > > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> > > as the first argument and the low bit as the second argument. Mixing
> > > them will return a mask with zero bits set.
> > >
> >
> > I'm seeing some breakage in code which is newly added in linux-next:
> >
>
> As of next-20191021, those breakages are fixed ([0], [1]). next-20191021
> now builds (at least for x86-64) with the GENMASK compile checks added.
>
> I also stumbled upon [2], which is a fix for an unused macro in a header
> in mips/include/asm. next-201008 contained both v3 of this patch and the
> mips header with the bad GENMASK in without build regressions, so it
> *should* be ok to include v4 (but given the track record of this patch,
> I totally understand if you want to wait until [2] lands in mips-next and
> linux-next).
>
> Rikard
>
> [0]: https://lore.kernel.org/patchwork/patch/1139777/
> [1]: https://lore.kernel.org/patchwork/patch/1139778/
> [2]: https://lore.kernel.org/linux-mips/20191022192547.480095-1-rikard.falkeborn@gmail.com/T/#u
And as of next-20191031, the mentioned mips-header is fixed [0]. Also, a
recently introduced arm-bug has also been fixed. I just built x86-64 and
arm64 allmodconfigs without issue.
Trying to get this patch merged feels a bit like playing whack a-mole.
Perhaps it would have been better to make it a warning at first, and
then promote the warning to an error in a later release? Then everyone
would have the warning in their tree when they do development and the
number if issues in next would be (almost) zero.
Rikard
[0]: https://lore.kernel.org/linux-mips/20191009013721.qda2bo5teppr7nom@pburton-laptop/T/#m6e7cd9c89ef06240fe3cd36a60bd73eff1a1ea5d
[1]: https://www.spinics.net/lists/arm-kernel/msg764473.html
Powered by blists - more mailing lists