linux-kernel - Re: [PATCH] asm-generic: correct reference to GENERIC_LIB_DEVMEM_IS

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:   Thu, 21 Jul 2022 22:41:12 +0200
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Conor Dooley <Conor.Dooley@...rochip.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        kernel-janitors <kernel-janitors@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] asm-generic: correct reference to GENERIC_LIB_DEVMEM_IS_ALLOWED

On Thu, Jul 21, 2022 at 8:52 AM Lukas Bulwahn <lukas.bulwahn@...il.com> wrote:
>
> On Wed, Jul 20, 2022 at 12:50 PM Arnd Bergmann <arnd@...db.de> wrote:
> >
> > On Thu, Jul 7, 2022 at 4:41 PM Lukas Bulwahn <lukas.bulwahn@...il.com> wrote:
> > > On Thu, Jul 7, 2022 at 3:07 PM Arnd Bergmann <arnd@...db.de> wrote:
> > > > On Thu, Jul 7, 2022 at 2:20 PM <Conor.Dooley@...rochip.com> wrote:
> >
> > > > lkft just found a build failure:
> > > >
> > > > https://gitlab.com/Linaro/lkft/users/arnd.bergmann/asm-generic/-/jobs/2691154818
> > > >
> > > > I have not investigated what went wrong, but it does look like an actual
> > > > regression, so I'll wait for Lukas to follow up with a new version of the patch.
> > >
> > > Thanks for your testing. I will look into it. Probably it is due to
> > > some more rigor during builds (-Werror and new warning types in the
> > > default build) since I proposed the patch in October 2021. That should
> > > be easy to fix, but let us see. I will send a PATCH v2 soon.
> >
> > Any update on this? I have another bugfix for asm-generic now and was planning
> > to send a pull request with both. If you don't have the updated patch
> > ready yet, this
> > will have to go into 5.21 instead.
> >
>
> It is still on my TODO list for revisiting, but I had other work on
> patches taking me longer than originally expected. I now moved this
> patch revisiting to the top of my TODO list; so, I will certainly look
> into this today. So far, I have not set up an arm64 build on my local
> machine and have not used tuxbuild (which should simplify all this
> setup)---the typical challenges for a "part-time kernel
> contributor/janitor"...
>
> Arnd, I will certainly let you know by this evening (European time
> zone) how far I got. If that is already too late, it is also perfectly
> fine if this goes in 5.21 instead, but I will try my best to make it
> 5.20 material.
>

Arnd, I can reproduce the error from your build system.

I think I have an idea what the correct patch would actually be:

- either make the function declaration completely unconditional,
- or put the function declaration under #ifdef and not #ifndef.

I guess the first should actually lead to some compiler warning (at
W=2 or so) having a function declared multiple times, for some
architectures. And hence, the second option is a better one. This is
all educated guessing so far, so to confirm, I need to build the
kernel with W=2 on the defconfig all architectures before and after
patch application and see if I am right. This is going to take some
build time on my local (home) machine. So, I hope that I can spend
some time tomorrow on just kicking off builds and looking at diffs and
then send out a working patch v2.

Lukas