linux-kernel - Re: [PATCH v3] wait_on_bit: add an acquire memory barrier

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]

Message-ID: <CAHk-=wh91FqN2sNSRFZPxfGnqAbJ1o66ew8TXh+neM9hW0xZiA@mail.gmail.com>
Date:   Fri, 26 Aug 2022 13:03:36 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Mikulas Patocka <mpatocka@...hat.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Andrea Parri <parri.andrea@...il.com>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Akira Yokosawa <akiyks@...il.com>,
        Daniel Lustig <dlustig@...dia.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v3] wait_on_bit: add an acquire memory barrier

On Fri, Aug 26, 2022 at 12:23 PM Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
>
>     include/asm-generic/bitops/non-instrumented-non-atomic.h:15:33:
> error: implicit declaration of function 'arch_test_bit_acquire'; did
> you mean '_test_bit_acquire'? [-Werror=implicit-function-declaration]
>

Ahh. m68k isn't using any of the generic bitops headers.

*Most* architectures have that

   #include <asm-generic/bitops/non-atomic.h>

and get it that way, but while it's common, it's most definitely not universal:

  [torvalds@...en linux]$ git grep -L bitops/non-atomic.h
arch/*/include/asm/bitops.h
  arch/alpha/include/asm/bitops.h
  arch/hexagon/include/asm/bitops.h
  arch/ia64/include/asm/bitops.h
  arch/m68k/include/asm/bitops.h
  arch/s390/include/asm/bitops.h
  arch/sparc/include/asm/bitops.h
  arch/x86/include/asm/bitops.h

and of that list only x86 has the new arch_test_bit_acquire().

So I assume it's not just m68k, but also alpha, hexagon, ia64, s390
and sparc that have this issue (unless they maybe have some other path
that includes the gerneric ones, I didn't check).

This was actually why my original suggested patch used the
'generic-non-atomic.h' header for it, because that is actually
included regardless of any architecture headers directly from
<linux/bitops.h>.

And it never triggered for me that Mikulas' updated patch then had
this arch_test_bit_acquire() issue.

Something like the attached patch *MAY* fix it, but I really haven't
thought about it a lot, and it's pretty ugly. Maybe it would be better
to just add the

   #define arch_test_bit_acquire generic_test_bit_acquire

to the affected <asm/bitops.h> files instead, and then let those
architectures decide on their own that maybe they want to use their
own test_bit() function because it is _already_ an acquire one.

Mikulas?

Geert - any opinions on that "maybe the arch should just do that
#define itself"? I don't think it actually matters for m68k, you end
up with pretty much the same thing anyway, because
"smp_load_acquire()" is just a load anyway..

                 Linus

View attachment "patch.diff" of type "text/x-patch" (1111 bytes)