From: Waiman Long <longman@redhat.com> Date: 2021-02-10 14:47:53
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
---
arch/arm64/include/asm/spinlock.h | 2 +-
arch/mips/include/asm/spinlock.h | 2 +-
arch/xtensa/include/asm/spinlock.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
There should be a Fixes: tag here. If the SHA of the offending commit is not
stable, there should be a better reference than "The queued rwlock code".
This patch fixes the build problem I had observed on mips. I also tested
xtensa:defconfig and arm64:defconfig with no problems observed.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
From: Waiman Long <longman@redhat.com> Date: 2021-02-10 15:55:41
On 2/10/21 10:05 AM, Guenter Roeck wrote:
On 2/10/21 6:45 AM, Waiman Long wrote:
quoted
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
There should be a Fixes: tag here. If the SHA of the offending commit is not
stable, there should be a better reference than "The queued rwlock code".
I originally have a Fixes tag when I was modifying the mips'
asm/spinlock.h file. After I realize that there are more files to
modify, I take that out. Anyway, the problem was exposed by Ben's
qrwlock patch. So existing stable releases should still be fine without
this patch.
This patch fixes the build problem I had observed on mips. I also tested
xtensa:defconfig and arm64:defconfig with no problems observed.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Thanks for the testing as I don't have a build environment to verify that.
Cheers,
Longman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Date: 2021-02-10 16:21:07
On Wed, Feb 10, 2021 at 09:45:56AM -0500, Waiman Long wrote:
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
---
arch/arm64/include/asm/spinlock.h | 2 +-
arch/mips/include/asm/spinlock.h | 2 +-
arch/xtensa/include/asm/spinlock.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
which tree should this go through ? I can take it via mips-next,
if everybody agrees.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Ben Gardon <hidden> Date: 2021-02-10 17:37:17
On Wed, Feb 10, 2021 at 7:54 AM Waiman Long [off-list ref] wrote:
On 2/10/21 10:05 AM, Guenter Roeck wrote:
quoted
On 2/10/21 6:45 AM, Waiman Long wrote:
quoted
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
There should be a Fixes: tag here. If the SHA of the offending commit is not
stable, there should be a better reference than "The queued rwlock code".
I originally have a Fixes tag when I was modifying the mips'
asm/spinlock.h file. After I realize that there are more files to
modify, I take that out. Anyway, the problem was exposed by Ben's
qrwlock patch. So existing stable releases should still be fine without
this patch.
quoted
This patch fixes the build problem I had observed on mips. I also tested
xtensa:defconfig and arm64:defconfig with no problems observed.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Thanks for the testing as I don't have a build environment to verify that.
Cheers,
Longman
Thanks Longman and Guenter for developing and testing this fix! I
don't have the environment to test this either, but the patch looks
good to me.
Reviewed-by: Ben Gardon <redacted>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Paolo Bonzini <pbonzini@redhat.com> Date: 2021-02-10 18:44:26
On 10/02/21 15:45, Waiman Long wrote:
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
arch/sparc/include/asm/spinlock_64.h is missing. Also, the include in
kernel/locking/qrwlock.c is not necessary (it may be there for aesthetic
reasons, but it complicates thing in this case).
I'll send a v2 that is based on the kvm/next tree.
Paolo
From: Waiman Long <longman@redhat.com> Date: 2021-02-10 18:55:29
On 2/10/21 1:28 PM, Paolo Bonzini wrote:
On 10/02/21 15:45, Waiman Long wrote:
quoted
The queued rwlock code has a dependency on the current spinlock
implementation (likely to be qspinlock), but not vice versa. Including
qrwlock.h before qspinlock.h can be problematic when expanding qrwlock
functionality.
If both qspinlock.h and qrwlock.h are to be included, the qrwlock.h
include should always be after qspinlock.h. Update the current set of
asm/spinlock.h files to enforce that.
Signed-off-by: Waiman Long <longman@redhat.com>
arch/sparc/include/asm/spinlock_64.h is missing. Also, the include in
kernel/locking/qrwlock.c is not necessary (it may be there for
aesthetic reasons, but it complicates thing in this case).
Sorry for missing arch/sparc/include/asm/spinlock_64.h. I was just
focusing on asm/spinlock.h and not aware that there are other variants
there.
It is true that the asm/qrwlock.h include in qrwlock.c is not really
necessary. I can't recall why it was there.
I'll send a v2 that is based on the kvm/next tree.
Paolo
which tree should this go through ? I can take it via mips-next,
if everybody agrees.
The breakage is in the KVM tree, and the existing patch has acked-by
from the locking primitives folks. So I'll queue it there in order to
limit the range that breaks bisection.
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
which tree should this go through ? I can take it via mips-next,
if everybody agrees.
The breakage is in the KVM tree, and the existing patch has acked-by from
the locking primitives folks. So I'll queue it there in order to limit the
range that breaks bisection.
if it's not too late you can add by
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel