linux-kernel - Re: [PATCH] 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]

Date:   Fri, 26 Aug 2022 07:46:13 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@...hat.com>
To:     Will Deacon <will@...nel.org>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Andrea Parri <parri.andrea@...il.com>,
        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@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] wait_on_bit: add an acquire memory barrier



On Fri, 26 Aug 2022, Will Deacon wrote:

> On Thu, Aug 25, 2022 at 05:03:40PM -0400, Mikulas Patocka wrote:
> > Here I reworked your patch, so that test_bit_acquire is defined just like 
> > test_bit. There's some code duplication (in 
> > include/asm-generic/bitops/generic-non-atomic.h and in 
> > arch/x86/include/asm/bitops.h), but that duplication exists in the 
> > test_bit function too.
> > 
> > I tested it on x86-64 and arm64. On x86-64 it generates the "bt" 
> > instruction for variable-bit test and "shr; and $1" for constant bit test. 
> > On arm64 it generates the "ldar" instruction for both constant and 
> > variable bit test.
> > 
> > For me, the kernel 6.0-rc2 doesn't boot in an arm64 virtual machine at all 
> > (with or without this patch), so I only compile-tested it on arm64. I have 
> > to bisect it.
> 
> It's working fine for me and I haven't had any other reports that it's not
> booting. Please could you share some more details about your setup so we
> can try to reproduce the problem?

I'm bisecting it now. I'll post the offending commit when I'm done.

It gets stuck without printing anything at this point:
Loading Linux 6.0.0-rc2 ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...

I uploaded my .config here: 
https://people.redhat.com/~mpatocka/testcases/arm64-config/config-6.0.0-rc2 
so you can try it on your own.

The host system is MacchiatoBIN board with Debian 10.12.

> This looks good to me, thanks for doing it! Just one thing that jumped out
> at me:
> 
> > Index: linux-2.6/include/linux/buffer_head.h
> > ===================================================================
> > --- linux-2.6.orig/include/linux/buffer_head.h
> > +++ linux-2.6/include/linux/buffer_head.h
> > @@ -156,7 +156,7 @@ static __always_inline int buffer_uptoda
> >  	 * make it consistent with folio_test_uptodate
> >  	 * pairs with smp_mb__before_atomic in set_buffer_uptodate
> >  	 */
> > -	return (smp_load_acquire(&bh->b_state) & (1UL << BH_Uptodate)) != 0;
> > +	return test_bit_acquire(BH_Uptodate, &bh->b_state);
> 
> Do you think it would be worth adding set_bit_release() and then relaxing
> set_buffer_uptodate() to use that rather than the smp_mb__before_atomic()?
> 
> Will

Yes, we could add this (but it would be better to add it in a separate 
patch, so that backporting of the origianal patch to -stable is easier).

Mikulas