From: Dave Airlie airlied@redhat.com
This commit is not required upstream, but is required for the 4.9.y stable series.
Upstream commit 101110f6271c ("Kbuild: always define endianess in kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is defined to reflect the endianness of the target CPU architecture regardless of whether or not <asm/byteorder.h> has been #included. The upstream definition of 'struct qspinlock' relies on this property.
Unfortunately, the 4.9.y stable series does not provide this guarantee, so the 'spin_unlock()' routine can erroneously treat the underlying lockword as big-endian on little-endian architectures using native qspinlock (i.e. x86_64 without PV) if the caller has not included <asm/byteorder.h>. This can lead to hangs such as the one in 'i915_gem_request()' reported via bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202063
Fix the issue by ensuring that <asm/byteorder.h> is #included in <asm/qspinlock_types.h>, where 'struct qspinlock' is defined.
Cc: stable@vger.kernel.org # 4.9 Signed-off-by: Dave Airlie airlied@redhat.com [will: wrote commit message] Signed-off-by: Will Deacon will.deacon@arm.com --- include/asm-generic/qspinlock_types.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/asm-generic/qspinlock_types.h b/include/asm-generic/qspinlock_types.h index d10f1e7d6ba8..6503e96710fa 100644 --- a/include/asm-generic/qspinlock_types.h +++ b/include/asm-generic/qspinlock_types.h @@ -18,6 +18,8 @@ #ifndef __ASM_GENERIC_QSPINLOCK_TYPES_H #define __ASM_GENERIC_QSPINLOCK_TYPES_H
+#include <asm/byteorder.h> + /* * Including atomic.h with PARAVIRT on will cause compilation errors because * of recursive header file incluson via paravirt_types.h. So don't include
On Thu, Jan 24, 2019 at 06:54:15PM +0000, Will Deacon wrote:
From: Dave Airlie airlied@redhat.com
This commit is not required upstream, but is required for the 4.9.y stable series.
Upstream commit 101110f6271c ("Kbuild: always define endianess in kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is defined to reflect the endianness of the target CPU architecture regardless of whether or not <asm/byteorder.h> has been #included. The upstream definition of 'struct qspinlock' relies on this property.
Unfortunately, the 4.9.y stable series does not provide this guarantee, so the 'spin_unlock()' routine can erroneously treat the underlying lockword as big-endian on little-endian architectures using native qspinlock (i.e. x86_64 without PV) if the caller has not included <asm/byteorder.h>. This can lead to hangs such as the one in 'i915_gem_request()' reported via bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202063
Fix the issue by ensuring that <asm/byteorder.h> is #included in <asm/qspinlock_types.h>, where 'struct qspinlock' is defined.
That is crazy...
Thanks for the patch, now queued up.
greg k-h
On Fri, Jan 25, 2019 at 5:04 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Jan 24, 2019 at 06:54:15PM +0000, Will Deacon wrote:
From: Dave Airlie airlied@redhat.com
This commit is not required upstream, but is required for the 4.9.y stable series.
Upstream commit 101110f6271c ("Kbuild: always define endianess in kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is defined to reflect the endianness of the target CPU architecture regardless of whether or not <asm/byteorder.h> has been #included. The upstream definition of 'struct qspinlock' relies on this property.
Unfortunately, the 4.9.y stable series does not provide this guarantee, so the 'spin_unlock()' routine can erroneously treat the underlying lockword as big-endian on little-endian architectures using native qspinlock (i.e. x86_64 without PV) if the caller has not included <asm/byteorder.h>. This can lead to hangs such as the one in 'i915_gem_request()' reported via bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202063
Fix the issue by ensuring that <asm/byteorder.h> is #included in <asm/qspinlock_types.h>, where 'struct qspinlock' is defined.
That is crazy...
You've no idea, we've spent a couple of days at LCA figuring it all out :-)
Dave.
linux-stable-mirror@lists.linaro.org