Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <CACRpkdZ_Jr3OzfoOpSSsAJMy1Oe_=zD861jouDzCVD-BQ6yZMg@mail.gmail.com>
In-Reply-To: <CACRpkdZ_Jr3OzfoOpSSsAJMy1Oe_=zD861jouDzCVD-BQ6yZMg@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 28 Mar 2022 12:11:49 -0700
Message-ID: <CAHk-=whzqAB6kfHUcX2uhfPnNiWJRq=UmeA1TbgGi3XA+57j3w@mail.gmail.com>
Subject: Re: [GIT PULL] pin control bulk changes for v5.18
To:     Linus Walleij <linus.walleij@linaro.org>,
        Kees Cook <keescook@chromium.org>
Cc:     linux-kernel <linux-kernel@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Mar 28, 2022 at 6:08 AM Linus Walleij <linus.walleij@linaro.org> wr=
ote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
> tags/pinctrl-v5.18-1

Hmm.

This clashes badly with the fact that we in the meantime have enabled
-Warray-bounds, and I got

  drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c: In function =E2=80=98npcmgpio_=
irq_handler=E2=80=99:
  ./include/linux/find.h:40:23: error: array subscript =E2=80=98long unsign=
ed
int[0]=E2=80=99 is partly outside array bounds of =E2=80=98u32[1]=E2=80=99 =
{aka =E2=80=98unsigned
int[1]=E2=80=99} [-Werror=3Darray-bounds]
     40 |                 val =3D *addr & GENMASK(size - 1, offset);
        |                       ^~~~~
  drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c:219:13: note: while
referencing =E2=80=98sts=E2=80=99
    219 |         u32 sts, en, bit;
        |             ^~~

as a result.

Was this not in linux-next?

Or was the array bounds checking not there?

Anyway, that cast to "const void *"

     for_each_set_bit(bit, (const void *)&sts,

in that driver is completely wrong.

The bit operations are defined in arrays of 'unsigned long', and you
can't just cast the issue away, because the end result is not the same
on a big-endian machine.

I fixed it up in the merge, but what really confuses me (apart from
the apparent lack of testing in linux-next) is that I don't actually
see what made this happen now, and not before. Maybe that's why it
didn't show up in linux-next: it's some odd gcc heisenbug.

Because there seems to be no actual changes to that driver that would
explain why I get the warning now, but not before the pull.

There *was* a change from

-       dev_dbg(bank->gc.parent, "...
+       dev_dbg(chip->parent_device, }...

in that function, but nothing else I notice.

VERY funky.

Kees, any idea?

                   Linus