All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-04-12 14:35 Christoph Hellwig
  2019-04-12 14:53 ` Arnd Bergmann
  2019-05-30  1:46 ` Maciej Rozycki
  0 siblings, 2 replies; 20+ messages in thread
From: Christoph Hellwig @ 2019-04-12 14:35 UTC (permalink / raw)
  To: torvalds, akpm; +Cc: arnd, linux-arch, mick, linux-kernel

When removing some dead big endian checks in the RISC-V code Nick
suggested that we should have some generic sanity checks.  I don't think
we should have thos inside the RISC-V code, but maybe it might make
sense to have these in the generic byteorder headers.  Note that these
are UAPI headers and some compilers might not actually define
__BYTE_ORDER__, so we first check that it actually exists.

Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/uapi/linux/byteorder/big_endian.h    | 4 ++++
 include/uapi/linux/byteorder/little_endian.h | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/include/uapi/linux/byteorder/big_endian.h b/include/uapi/linux/byteorder/big_endian.h
index 2199adc6a6c2..34a5864526d2 100644
--- a/include/uapi/linux/byteorder/big_endian.h
+++ b/include/uapi/linux/byteorder/big_endian.h
@@ -2,6 +2,10 @@
 #ifndef _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
 #define _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
 
+#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
+#error "Unsupported endianess, check your toolchain"
+#endif
+
 #ifndef __BIG_ENDIAN
 #define __BIG_ENDIAN 4321
 #endif
diff --git a/include/uapi/linux/byteorder/little_endian.h b/include/uapi/linux/byteorder/little_endian.h
index 601c904fd5cd..0cdf3583e19f 100644
--- a/include/uapi/linux/byteorder/little_endian.h
+++ b/include/uapi/linux/byteorder/little_endian.h
@@ -2,6 +2,10 @@
 #ifndef _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
 #define _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
 
+#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ !=  __ORDER_LITTLE_ENDIAN__
+#error "Unsupported endianess, check your toolchain"
+#endif
+
 #ifndef __LITTLE_ENDIAN
 #define __LITTLE_ENDIAN 1234
 #endif
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-04-12 14:35 [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess Christoph Hellwig
@ 2019-04-12 14:53 ` Arnd Bergmann
  2019-04-12 14:55   ` Christoph Hellwig
  2019-04-12 16:05   ` Nick Kossifidis
  2019-05-30  1:46 ` Maciej Rozycki
  1 sibling, 2 replies; 20+ messages in thread
From: Arnd Bergmann @ 2019-04-12 14:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linus Torvalds, Andrew Morton, Arnd Bergmann, linux-arch, mick,
	Linux Kernel Mailing List

On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <hch@lst.de> wrote:
>
> When removing some dead big endian checks in the RISC-V code Nick
> suggested that we should have some generic sanity checks.  I don't think
> we should have thos inside the RISC-V code, but maybe it might make
> sense to have these in the generic byteorder headers.  Note that these
> are UAPI headers and some compilers might not actually define
> __BYTE_ORDER__, so we first check that it actually exists.
>
> Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Extra checking like this is good in general, but I'm not sure I see
exactly what kind of issue one might expect to prevent with this:

All architecture asm/byteorder.h headers either include the only
possible option, or they check the compiler defined macros:

arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__

Are you worried about toolchains that define those differently
from what these headers expect? Did you encounter such a case?

      Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-04-12 14:53 ` Arnd Bergmann
@ 2019-04-12 14:55   ` Christoph Hellwig
  2019-04-12 15:22     ` Arnd Bergmann
  2019-04-12 16:05   ` Nick Kossifidis
  1 sibling, 1 reply; 20+ messages in thread
From: Christoph Hellwig @ 2019-04-12 14:55 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Christoph Hellwig, Linus Torvalds, Andrew Morton, linux-arch,
	mick, Linux Kernel Mailing List

On Fri, Apr 12, 2019 at 04:53:28PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <hch@lst.de> wrote:
> >
> > When removing some dead big endian checks in the RISC-V code Nick
> > suggested that we should have some generic sanity checks.  I don't think
> > we should have thos inside the RISC-V code, but maybe it might make
> > sense to have these in the generic byteorder headers.  Note that these
> > are UAPI headers and some compilers might not actually define
> > __BYTE_ORDER__, so we first check that it actually exists.
> >
> > Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> Extra checking like this is good in general, but I'm not sure I see
> exactly what kind of issue one might expect to prevent with this:

I'm personally not worried at all. Just trying to respond to Nicks
review comment and make it reasonable generic if we have to have these
checks at all.  I personally would be ok without them, I just don't
want them hidden somewhere in the RISC-V code (RISC-V is always little
endian at least right now).

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-04-12 14:55   ` Christoph Hellwig
@ 2019-04-12 15:22     ` Arnd Bergmann
  0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2019-04-12 15:22 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linus Torvalds, Andrew Morton, linux-arch, mick,
	Linux Kernel Mailing List

On Fri, Apr 12, 2019 at 4:55 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Apr 12, 2019 at 04:53:28PM +0200, Arnd Bergmann wrote:
> > On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > When removing some dead big endian checks in the RISC-V code Nick
> > > suggested that we should have some generic sanity checks.  I don't think
> > > we should have thos inside the RISC-V code, but maybe it might make
> > > sense to have these in the generic byteorder headers.  Note that these
> > > are UAPI headers and some compilers might not actually define
> > > __BYTE_ORDER__, so we first check that it actually exists.
> > >
> > > Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Extra checking like this is good in general, but I'm not sure I see
> > exactly what kind of issue one might expect to prevent with this:
>
> I'm personally not worried at all. Just trying to respond to Nicks
> review comment and make it reasonable generic if we have to have these
> checks at all.  I personally would be ok without them, I just don't
> want them hidden somewhere in the RISC-V code (RISC-V is always little
> endian at least right now).

Ok, makes sense.

Note: I hope we won't ever see big-endian RISC-V, I think that ship has
sailed long ago, regardless of any personal preferences one might hold.

The architectures that allow both (arm, arc, mips, c6x, microblaze,
modern ppc64, superh) tend to just use little-endian in practice, and the
ones that are hardcoded to big-endian (sparc, parisc, m68k, h8300, s390,
ppc32, some mips) are all 25+ years old and do so only for historic
reasons, with openrisc being the notable exception.

       Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-04-12 14:53 ` Arnd Bergmann
  2019-04-12 14:55   ` Christoph Hellwig
@ 2019-04-12 16:05   ` Nick Kossifidis
  2019-05-10 10:53     ` Dmitry Vyukov
  1 sibling, 1 reply; 20+ messages in thread
From: Nick Kossifidis @ 2019-04-12 16:05 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Christoph Hellwig, Linus Torvalds, Andrew Morton, linux-arch,
	mick, Linux Kernel Mailing List

Στις 2019-04-12 17:53, Arnd Bergmann έγραψε:
> On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <hch@lst.de> wrote:
>> 
>> When removing some dead big endian checks in the RISC-V code Nick
>> suggested that we should have some generic sanity checks.  I don't 
>> think
>> we should have thos inside the RISC-V code, but maybe it might make
>> sense to have these in the generic byteorder headers.  Note that these
>> are UAPI headers and some compilers might not actually define
>> __BYTE_ORDER__, so we first check that it actually exists.
>> 
>> Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> Extra checking like this is good in general, but I'm not sure I see
> exactly what kind of issue one might expect to prevent with this:
> 
> All architecture asm/byteorder.h headers either include the only
> possible option, or they check the compiler defined macros:
> 
> arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
> arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
> arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
> arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
> arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
> arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
> arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
> arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__
> 
> Are you worried about toolchains that define those differently
> from what these headers expect? Did you encounter such a case?
> 
>       Arnd

The following architectures just include the header file without
checking for any compiler macro:

alpha: little_endian.h
csky: little_endian.h
h8300: big_endian.h
hexagon: little_endian.h
ia64: little_endian.h
m68k: big_endian.h
nios2: little_endian.h
openrisc: big_endian.h
parisc: big_endian.h
riscv: little_endian.h
s390: big_endian.h
sparc: big_endian.h
unicore32: little_endian.h
x86: little_endian.h

Of those who do check for a compiler macro, they don't use the
generic macros (__ORDER_*_ENDIAN__) but arch-specific ones.

Only two architectures (mips and xtensa) that support both big
and little endian return an error in case the endianess can't be
determined, the rest will move on without including any
of *_endian.h files.

I think it's good to have a sanity check in-place for consistency.

Regards,
Nick

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-04-12 16:05   ` Nick Kossifidis
@ 2019-05-10 10:53     ` Dmitry Vyukov
  2019-05-11  0:51         ` Arnd Bergmann
  0 siblings, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2019-05-10 10:53 UTC (permalink / raw)
  To: Nick Kossifidis
  Cc: Arnd Bergmann, Christoph Hellwig, Linus Torvalds, Andrew Morton,
	linux-arch, Linux Kernel Mailing List

From: Nick Kossifidis <mick@ics.forth.gr>
Date: Fri, Apr 12, 2019 at 6:08 PM
To: Arnd Bergmann
Cc: Christoph Hellwig, Linus Torvalds, Andrew Morton, linux-arch,
<mick@ics.forth.gr>, Linux Kernel Mailing List

> Στις 2019-04-12 17:53, Arnd Bergmann έγραψε:
> > On Fri, Apr 12, 2019 at 4:36 PM Christoph Hellwig <hch@lst.de> wrote:
> >>
> >> When removing some dead big endian checks in the RISC-V code Nick
> >> suggested that we should have some generic sanity checks.  I don't
> >> think
> >> we should have thos inside the RISC-V code, but maybe it might make
> >> sense to have these in the generic byteorder headers.  Note that these
> >> are UAPI headers and some compilers might not actually define
> >> __BYTE_ORDER__, so we first check that it actually exists.
> >>
> >> Suggested-by: Nick Kossifidis <mick@ics.forth.gr>
> >> Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Extra checking like this is good in general, but I'm not sure I see
> > exactly what kind of issue one might expect to prevent with this:
> >
> > All architecture asm/byteorder.h headers either include the only
> > possible option, or they check the compiler defined macros:
> >
> > arch/arc/include/uapi/asm/byteorder.h:#ifdef __BIG_ENDIAN__
> > arch/arm/include/uapi/asm/byteorder.h:#ifdef __ARMEB__
> > arch/arm64/include/uapi/asm/byteorder.h:#ifdef __AARCH64EB__
> > arch/c6x/include/uapi/asm/byteorder.h:#ifdef _BIG_ENDIAN
> > arch/microblaze/include/uapi/asm/byteorder.h:#ifdef __MICROBLAZEEL__
> > arch/mips/include/uapi/asm/byteorder.h:#if defined(__MIPSEB__)
> > arch/nds32/include/uapi/asm/byteorder.h:#ifdef __NDS32_EB__
> > arch/powerpc/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> > arch/sh/include/uapi/asm/byteorder.h:#ifdef __LITTLE_ENDIAN__
> > arch/xtensa/include/uapi/asm/byteorder.h:#ifdef __XTENSA_EL__
> >
> > Are you worried about toolchains that define those differently
> > from what these headers expect? Did you encounter such a case?
> >
> >       Arnd
>
> The following architectures just include the header file without
> checking for any compiler macro:
>
> alpha: little_endian.h
> csky: little_endian.h
> h8300: big_endian.h
> hexagon: little_endian.h
> ia64: little_endian.h
> m68k: big_endian.h
> nios2: little_endian.h
> openrisc: big_endian.h
> parisc: big_endian.h
> riscv: little_endian.h
> s390: big_endian.h
> sparc: big_endian.h
> unicore32: little_endian.h
> x86: little_endian.h
>
> Of those who do check for a compiler macro, they don't use the
> generic macros (__ORDER_*_ENDIAN__) but arch-specific ones.
>
> Only two architectures (mips and xtensa) that support both big
> and little endian return an error in case the endianess can't be
> determined, the rest will move on without including any
> of *_endian.h files.
>
> I think it's good to have a sanity check in-place for consistency.


Hi,

This broke our cross-builds from x86. I am using:

$ powerpc64le-linux-gnu-gcc --version
powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0

and it says that it's little-endian somehow:

$ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__

Is it broke compiler? Or I always hold it wrong? Is there some
additional flag I need to add?

Thanks

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-10 10:53     ` Dmitry Vyukov
@ 2019-05-11  0:51         ` Arnd Bergmann
  0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2019-05-11  0:51 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds,
	Andrew Morton, linux-arch, Linux Kernel Mailing List,
	linuxppc-dev

On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > I think it's good to have a sanity check in-place for consistency.
>
>
> Hi,
>
> This broke our cross-builds from x86. I am using:
>
> $ powerpc64le-linux-gnu-gcc --version
> powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>
> and it says that it's little-endian somehow:
>
> $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>
> Is it broke compiler? Or I always hold it wrong? Is there some
> additional flag I need to add?

It looks like a bug in the kernel Makefiles to me. powerpc32 is always
big-endian,
powerpc64 used to be big-endian but is now usually little-endian. There are
often three separate toolchains that default to the respective user
space targets
(ppc32be, ppc64be, ppc64le), but generally you should be able to build
any of the
three kernel configurations with any of those compilers, and have the Makefile
pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
depending on the kernel configuration. It seems that this is not happening
here. I have not checked why, but if this is the problem, it should be
easy enough
to figure out.

       Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-05-11  0:51         ` Arnd Bergmann
  0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2019-05-11  0:51 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: linux-arch, linuxppc-dev, Linux Kernel Mailing List,
	Nick Kossifidis, Andrew Morton, Linus Torvalds,
	Christoph Hellwig

On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > I think it's good to have a sanity check in-place for consistency.
>
>
> Hi,
>
> This broke our cross-builds from x86. I am using:
>
> $ powerpc64le-linux-gnu-gcc --version
> powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>
> and it says that it's little-endian somehow:
>
> $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>
> Is it broke compiler? Or I always hold it wrong? Is there some
> additional flag I need to add?

It looks like a bug in the kernel Makefiles to me. powerpc32 is always
big-endian,
powerpc64 used to be big-endian but is now usually little-endian. There are
often three separate toolchains that default to the respective user
space targets
(ppc32be, ppc64be, ppc64le), but generally you should be able to build
any of the
three kernel configurations with any of those compilers, and have the Makefile
pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
depending on the kernel configuration. It seems that this is not happening
here. I have not checked why, but if this is the problem, it should be
easy enough
to figure out.

       Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-11  0:51         ` Arnd Bergmann
@ 2019-05-13  7:39           ` Dmitry Vyukov
  -1 siblings, 0 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2019-05-13  7:39 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds,
	Andrew Morton, linux-arch, Linux Kernel Mailing List,
	linuxppc-dev

From: Arnd Bergmann <arnd@arndb.de>
Date: Sat, May 11, 2019 at 2:51 AM
To: Dmitry Vyukov
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev

> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > >
> > > I think it's good to have a sanity check in-place for consistency.
> >
> >
> > Hi,
> >
> > This broke our cross-builds from x86. I am using:
> >
> > $ powerpc64le-linux-gnu-gcc --version
> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >
> > and it says that it's little-endian somehow:
> >
> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >
> > Is it broke compiler? Or I always hold it wrong? Is there some
> > additional flag I need to add?
>
> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> big-endian,
> powerpc64 used to be big-endian but is now usually little-endian. There are
> often three separate toolchains that default to the respective user
> space targets
> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> any of the
> three kernel configurations with any of those compilers, and have the Makefile
> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> depending on the kernel configuration. It seems that this is not happening
> here. I have not checked why, but if this is the problem, it should be
> easy enough
> to figure out.


Thanks! This clears a lot.
This may be a bug in our magic as we try to build kernel files outside
of make with own flags (required to extract parts of kernel
interfaces).
So don't spend time looking for the Makefile bugs yet.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-05-13  7:39           ` Dmitry Vyukov
  0 siblings, 0 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2019-05-13  7:39 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, linuxppc-dev, Linux Kernel Mailing List,
	Nick Kossifidis, Andrew Morton, Linus Torvalds,
	Christoph Hellwig

From: Arnd Bergmann <arnd@arndb.de>
Date: Sat, May 11, 2019 at 2:51 AM
To: Dmitry Vyukov
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev

> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > >
> > > I think it's good to have a sanity check in-place for consistency.
> >
> >
> > Hi,
> >
> > This broke our cross-builds from x86. I am using:
> >
> > $ powerpc64le-linux-gnu-gcc --version
> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >
> > and it says that it's little-endian somehow:
> >
> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >
> > Is it broke compiler? Or I always hold it wrong? Is there some
> > additional flag I need to add?
>
> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> big-endian,
> powerpc64 used to be big-endian but is now usually little-endian. There are
> often three separate toolchains that default to the respective user
> space targets
> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> any of the
> three kernel configurations with any of those compilers, and have the Makefile
> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> depending on the kernel configuration. It seems that this is not happening
> here. I have not checked why, but if this is the problem, it should be
> easy enough
> to figure out.


Thanks! This clears a lot.
This may be a bug in our magic as we try to build kernel files outside
of make with own flags (required to extract parts of kernel
interfaces).
So don't spend time looking for the Makefile bugs yet.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-13  7:39           ` Dmitry Vyukov
@ 2019-05-13 11:33             ` Michael Ellerman
  -1 siblings, 0 replies; 20+ messages in thread
From: Michael Ellerman @ 2019-05-13 11:33 UTC (permalink / raw)
  To: Dmitry Vyukov, Arnd Bergmann
  Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds,
	Andrew Morton, linux-arch, Linux Kernel Mailing List,
	linuxppc-dev

Dmitry Vyukov <dvyukov@google.com> writes:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sat, May 11, 2019 at 2:51 AM
> To: Dmitry Vyukov
> Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> linux-arch, Linux Kernel Mailing List, linuxppc-dev
>
>> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>> > >
>> > > I think it's good to have a sanity check in-place for consistency.
>> >
>> >
>> > Hi,
>> >
>> > This broke our cross-builds from x86. I am using:
>> >
>> > $ powerpc64le-linux-gnu-gcc --version
>> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>> >
>> > and it says that it's little-endian somehow:
>> >
>> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
>> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>> >
>> > Is it broke compiler? Or I always hold it wrong? Is there some
>> > additional flag I need to add?
>>
>> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
>> big-endian,
>> powerpc64 used to be big-endian but is now usually little-endian. There are
>> often three separate toolchains that default to the respective user
>> space targets
>> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
>> any of the
>> three kernel configurations with any of those compilers, and have the Makefile
>> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
>> depending on the kernel configuration. It seems that this is not happening
>> here. I have not checked why, but if this is the problem, it should be
>> easy enough
>> to figure out.
>
>
> Thanks! This clears a lot.
> This may be a bug in our magic as we try to build kernel files outside
> of make with own flags (required to extract parts of kernel
> interfaces).
> So don't spend time looking for the Makefile bugs yet.

OK :)

We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
fixed now. These days I build most of my kernels with a bi-endian 64-bit
toolchain, and switching endian without running `make clean` also works.

cheers

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-05-13 11:33             ` Michael Ellerman
  0 siblings, 0 replies; 20+ messages in thread
From: Michael Ellerman @ 2019-05-13 11:33 UTC (permalink / raw)
  To: Dmitry Vyukov, Arnd Bergmann
  Cc: linux-arch, linuxppc-dev, Linux Kernel Mailing List,
	Nick Kossifidis, Andrew Morton, Linus Torvalds,
	Christoph Hellwig

Dmitry Vyukov <dvyukov@google.com> writes:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sat, May 11, 2019 at 2:51 AM
> To: Dmitry Vyukov
> Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> linux-arch, Linux Kernel Mailing List, linuxppc-dev
>
>> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>> > >
>> > > I think it's good to have a sanity check in-place for consistency.
>> >
>> >
>> > Hi,
>> >
>> > This broke our cross-builds from x86. I am using:
>> >
>> > $ powerpc64le-linux-gnu-gcc --version
>> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>> >
>> > and it says that it's little-endian somehow:
>> >
>> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
>> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>> >
>> > Is it broke compiler? Or I always hold it wrong? Is there some
>> > additional flag I need to add?
>>
>> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
>> big-endian,
>> powerpc64 used to be big-endian but is now usually little-endian. There are
>> often three separate toolchains that default to the respective user
>> space targets
>> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
>> any of the
>> three kernel configurations with any of those compilers, and have the Makefile
>> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
>> depending on the kernel configuration. It seems that this is not happening
>> here. I have not checked why, but if this is the problem, it should be
>> easy enough
>> to figure out.
>
>
> Thanks! This clears a lot.
> This may be a bug in our magic as we try to build kernel files outside
> of make with own flags (required to extract parts of kernel
> interfaces).
> So don't spend time looking for the Makefile bugs yet.

OK :)

We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
fixed now. These days I build most of my kernels with a bi-endian 64-bit
toolchain, and switching endian without running `make clean` also works.

cheers

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-13 11:33             ` Michael Ellerman
@ 2019-05-13 11:50               ` Dmitry Vyukov
  -1 siblings, 0 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2019-05-13 11:50 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Arnd Bergmann, Nick Kossifidis, Christoph Hellwig,
	Linus Torvalds, Andrew Morton, linux-arch,
	Linux Kernel Mailing List, linuxppc-dev, Andrew Donnellan

From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, May 13, 2019 at 1:33 PM
To: Dmitry Vyukov, Arnd Bergmann
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev

> Dmitry Vyukov <dvyukov@google.com> writes:
> > From: Arnd Bergmann <arnd@arndb.de>
> > Date: Sat, May 11, 2019 at 2:51 AM
> > To: Dmitry Vyukov
> > Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> > linux-arch, Linux Kernel Mailing List, linuxppc-dev
> >
> >> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> > >
> >> > > I think it's good to have a sanity check in-place for consistency.
> >> >
> >> >
> >> > Hi,
> >> >
> >> > This broke our cross-builds from x86. I am using:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc --version
> >> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >> >
> >> > and it says that it's little-endian somehow:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> >> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >> >
> >> > Is it broke compiler? Or I always hold it wrong? Is there some
> >> > additional flag I need to add?
> >>
> >> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> >> big-endian,
> >> powerpc64 used to be big-endian but is now usually little-endian. There are
> >> often three separate toolchains that default to the respective user
> >> space targets
> >> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> >> any of the
> >> three kernel configurations with any of those compilers, and have the Makefile
> >> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> >> depending on the kernel configuration. It seems that this is not happening
> >> here. I have not checked why, but if this is the problem, it should be
> >> easy enough
> >> to figure out.
> >
> >
> > Thanks! This clears a lot.
> > This may be a bug in our magic as we try to build kernel files outside
> > of make with own flags (required to extract parts of kernel
> > interfaces).
> > So don't spend time looking for the Makefile bugs yet.
>
> OK :)
>
> We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> fixed now. These days I build most of my kernels with a bi-endian 64-bit
> toolchain, and switching endian without running `make clean` also works.

For the record, yes, it turn out to be a problem in our code (a latent
bug). We actually used host (x86) gcc to build as-if ppc code that can
run on the host, so it defined neither LE no BE macros. It just
happened to work in the past :)
+Andrew

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-05-13 11:50               ` Dmitry Vyukov
  0 siblings, 0 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2019-05-13 11:50 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: linux-arch, Arnd Bergmann, linuxppc-dev,
	Linux Kernel Mailing List, Andrew Donnellan, Nick Kossifidis,
	Andrew Morton, Linus Torvalds, Christoph Hellwig

From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, May 13, 2019 at 1:33 PM
To: Dmitry Vyukov, Arnd Bergmann
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev

> Dmitry Vyukov <dvyukov@google.com> writes:
> > From: Arnd Bergmann <arnd@arndb.de>
> > Date: Sat, May 11, 2019 at 2:51 AM
> > To: Dmitry Vyukov
> > Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> > linux-arch, Linux Kernel Mailing List, linuxppc-dev
> >
> >> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> > >
> >> > > I think it's good to have a sanity check in-place for consistency.
> >> >
> >> >
> >> > Hi,
> >> >
> >> > This broke our cross-builds from x86. I am using:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc --version
> >> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >> >
> >> > and it says that it's little-endian somehow:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> >> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >> >
> >> > Is it broke compiler? Or I always hold it wrong? Is there some
> >> > additional flag I need to add?
> >>
> >> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> >> big-endian,
> >> powerpc64 used to be big-endian but is now usually little-endian. There are
> >> often three separate toolchains that default to the respective user
> >> space targets
> >> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> >> any of the
> >> three kernel configurations with any of those compilers, and have the Makefile
> >> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> >> depending on the kernel configuration. It seems that this is not happening
> >> here. I have not checked why, but if this is the problem, it should be
> >> easy enough
> >> to figure out.
> >
> >
> > Thanks! This clears a lot.
> > This may be a bug in our magic as we try to build kernel files outside
> > of make with own flags (required to extract parts of kernel
> > interfaces).
> > So don't spend time looking for the Makefile bugs yet.
>
> OK :)
>
> We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> fixed now. These days I build most of my kernels with a bi-endian 64-bit
> toolchain, and switching endian without running `make clean` also works.

For the record, yes, it turn out to be a problem in our code (a latent
bug). We actually used host (x86) gcc to build as-if ppc code that can
run on the host, so it defined neither LE no BE macros. It just
happened to work in the past :)
+Andrew

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-13 11:50               ` Dmitry Vyukov
@ 2019-05-13 12:04                 ` Christoph Hellwig
  -1 siblings, 0 replies; 20+ messages in thread
From: Christoph Hellwig @ 2019-05-13 12:04 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Michael Ellerman, Arnd Bergmann, Nick Kossifidis,
	Christoph Hellwig, Linus Torvalds, Andrew Morton, linux-arch,
	Linux Kernel Mailing List, linuxppc-dev, Andrew Donnellan

On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > toolchain, and switching endian without running `make clean` also works.
> 
> For the record, yes, it turn out to be a problem in our code (a latent
> bug). We actually used host (x86) gcc to build as-if ppc code that can
> run on the host, so it defined neither LE no BE macros. It just
> happened to work in the past :)

So Nick was right and these checks actually are useful..

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-05-13 12:04                 ` Christoph Hellwig
  0 siblings, 0 replies; 20+ messages in thread
From: Christoph Hellwig @ 2019-05-13 12:04 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: linux-arch, Arnd Bergmann, linuxppc-dev,
	Linux Kernel Mailing List, Andrew Donnellan, Nick Kossifidis,
	Andrew Morton, Linus Torvalds, Christoph Hellwig

On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > toolchain, and switching endian without running `make clean` also works.
> 
> For the record, yes, it turn out to be a problem in our code (a latent
> bug). We actually used host (x86) gcc to build as-if ppc code that can
> run on the host, so it defined neither LE no BE macros. It just
> happened to work in the past :)

So Nick was right and these checks actually are useful..

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-13 12:04                 ` Christoph Hellwig
@ 2019-05-15  6:53                   ` Arnd Bergmann
  -1 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2019-05-15  6:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Dmitry Vyukov, Michael Ellerman, Nick Kossifidis, Linus Torvalds,
	Andrew Morton, linux-arch, Linux Kernel Mailing List,
	linuxppc-dev, Andrew Donnellan

On Mon, May 13, 2019 at 2:04 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > > toolchain, and switching endian without running `make clean` also works.
> >
> > For the record, yes, it turn out to be a problem in our code (a latent
> > bug). We actually used host (x86) gcc to build as-if ppc code that can
> > run on the host, so it defined neither LE no BE macros. It just
> > happened to work in the past :)
>
> So Nick was right and these checks actually are useful..

Yes, definitely. I wonder if we should also bring back the word size check
from include/asm-generic/bitsperlong.h, which was disabled right
after I originally added that.

      Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
@ 2019-05-15  6:53                   ` Arnd Bergmann
  0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2019-05-15  6:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-arch, linuxppc-dev, Linux Kernel Mailing List,
	Andrew Donnellan, Nick Kossifidis, Andrew Morton, Linus Torvalds,
	Dmitry Vyukov

On Mon, May 13, 2019 at 2:04 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > > toolchain, and switching endian without running `make clean` also works.
> >
> > For the record, yes, it turn out to be a problem in our code (a latent
> > bug). We actually used host (x86) gcc to build as-if ppc code that can
> > run on the host, so it defined neither LE no BE macros. It just
> > happened to work in the past :)
>
> So Nick was right and these checks actually are useful..

Yes, definitely. I wonder if we should also bring back the word size check
from include/asm-generic/bitsperlong.h, which was disabled right
after I originally added that.

      Arnd

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-04-12 14:35 [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess Christoph Hellwig
  2019-04-12 14:53 ` Arnd Bergmann
@ 2019-05-30  1:46 ` Maciej Rozycki
  2019-05-30  6:41   ` Christoph Hellwig
  1 sibling, 1 reply; 20+ messages in thread
From: Maciej Rozycki @ 2019-05-30  1:46 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: torvalds, akpm, arnd, linux-arch, mick, linux-kernel

On Fri, 12 Apr 2019, Christoph Hellwig wrote:

> diff --git a/include/uapi/linux/byteorder/big_endian.h b/include/uapi/linux/byteorder/big_endian.h
> index 2199adc6a6c2..34a5864526d2 100644
> --- a/include/uapi/linux/byteorder/big_endian.h
> +++ b/include/uapi/linux/byteorder/big_endian.h
> @@ -2,6 +2,10 @@
>  #ifndef _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
>  #define _UAPI_LINUX_BYTEORDER_BIG_ENDIAN_H
>  
> +#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
> +#error "Unsupported endianess, check your toolchain"

 Typo here: s/endianess/endianness/.

> diff --git a/include/uapi/linux/byteorder/little_endian.h b/include/uapi/linux/byteorder/little_endian.h
> index 601c904fd5cd..0cdf3583e19f 100644
> --- a/include/uapi/linux/byteorder/little_endian.h
> +++ b/include/uapi/linux/byteorder/little_endian.h
> @@ -2,6 +2,10 @@
>  #ifndef _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
>  #define _UAPI_LINUX_BYTEORDER_LITTLE_ENDIAN_H
>  
> +#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ !=  __ORDER_LITTLE_ENDIAN__
> +#error "Unsupported endianess, check your toolchain"

 Likewise.

  Maciej

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
  2019-05-30  1:46 ` Maciej Rozycki
@ 2019-05-30  6:41   ` Christoph Hellwig
  0 siblings, 0 replies; 20+ messages in thread
From: Christoph Hellwig @ 2019-05-30  6:41 UTC (permalink / raw)
  To: Maciej Rozycki
  Cc: Christoph Hellwig, torvalds, akpm, arnd, linux-arch, mick, linux-kernel

On Thu, May 30, 2019 at 01:46:18AM +0000, Maciej Rozycki wrote:
> > +#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
> > +#error "Unsupported endianess, check your toolchain"
> 
>  Typo here: s/endianess/endianness/.

The original patch has already been merged, please send a fixup.

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2019-05-30  6:41 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-12 14:35 [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess Christoph Hellwig
2019-04-12 14:53 ` Arnd Bergmann
2019-04-12 14:55   ` Christoph Hellwig
2019-04-12 15:22     ` Arnd Bergmann
2019-04-12 16:05   ` Nick Kossifidis
2019-05-10 10:53     ` Dmitry Vyukov
2019-05-11  0:51       ` Arnd Bergmann
2019-05-11  0:51         ` Arnd Bergmann
2019-05-13  7:39         ` Dmitry Vyukov
2019-05-13  7:39           ` Dmitry Vyukov
2019-05-13 11:33           ` Michael Ellerman
2019-05-13 11:33             ` Michael Ellerman
2019-05-13 11:50             ` Dmitry Vyukov
2019-05-13 11:50               ` Dmitry Vyukov
2019-05-13 12:04               ` Christoph Hellwig
2019-05-13 12:04                 ` Christoph Hellwig
2019-05-15  6:53                 ` Arnd Bergmann
2019-05-15  6:53                   ` Arnd Bergmann
2019-05-30  1:46 ` Maciej Rozycki
2019-05-30  6:41   ` Christoph Hellwig

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.