[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2208260727020.17585@file01.intranet.prod.int.rdu2.redhat.com>
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
Powered by blists - more mailing lists