* [GIT PULL] siginfo fix for v4.16-rc5
@ 2018-03-06 7:11 Eric W. Biederman
2018-03-31 10:56 ` Eugene Syromiatnikov
0 siblings, 1 reply; 7+ messages in thread
From: Eric W. Biederman @ 2018-03-06 7:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, kernel test robot
Linus,
Please pull the siginfo-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git siginfo-linus
HEAD: f6a015498dcaee72f80283cb7873d88deb07129c signal/x86: Include the field offsets in the build time checks
The kbuild test robot found that I accidentally moved si_pkey when I was
cleaning up siginfo_t. A short followed by an int with the int having 8
byte alignment. Sheesh siginfo_t is a weird structure.
I have now corrected it and added build time checks that with a little
luck will catch any similar future mistakes. The build time checks were
sufficient for me to verify the bug and to verify my fix. So they are
at least useful this once.
Eric W. Biederman (2):
signal: Correct the offset of si_pkey in struct siginfo
signal/x86: Include the field offsets in the build time checks
arch/x86/kernel/signal_compat.c | 65 ++++++++++++++++++++++++++++++++++++++
include/linux/compat.h | 4 +--
include/uapi/asm-generic/siginfo.h | 4 +--
3 files changed, 69 insertions(+), 4 deletions(-)
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [GIT PULL] siginfo fix for v4.16-rc5 2018-03-06 7:11 [GIT PULL] siginfo fix for v4.16-rc5 Eric W. Biederman @ 2018-03-31 10:56 ` Eugene Syromiatnikov 2018-04-02 20:17 ` Eric W. Biederman 0 siblings, 1 reply; 7+ messages in thread From: Eugene Syromiatnikov @ 2018-03-31 10:56 UTC (permalink / raw) To: Eric W. Biederman; +Cc: Linus Torvalds, linux-kernel, linux-m68k On Tue, Mar 06, 2018 at 01:11:03AM -0600, Eric W. Biederman wrote: > Linus, > > Please pull the siginfo-linus branch from the git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git siginfo-linus > > HEAD: f6a015498dcaee72f80283cb7873d88deb07129c signal/x86: Include the field offsets in the build time checks > > The kbuild test robot found that I accidentally moved si_pkey when I was > cleaning up siginfo_t. A short followed by an int with the int having 8 > byte alignment. Sheesh siginfo_t is a weird structure. > > I have now corrected it and added build time checks that with a little > luck will catch any similar future mistakes. The build time checks were > sufficient for me to verify the bug and to verify my fix. So they are > at least useful this once. > > Eric W. Biederman (2): > signal: Correct the offset of si_pkey in struct siginfo Looks like this commit changes layout of the siginfo struct on m68k: pts/0, esyr@fedora: /tmp % cat si.c #include <stddef.h> #include "linux/signal.h" static const size_t lower_offset = offsetof(struct siginfo, si_lower); pts/0, esyr@fedora: /tmp % m68k-linux-gnu-gcc -Ikhdr-v4.16-rc1\~159\^2\~20/include -g -c si.c -o si-orig.o pts/0, esyr@fedora: /tmp % m68k-linux-gnu-gcc -Ikhdr-v4.16-rc3\~17\^2/include -g -c si.c -o si-1.o pts/0, esyr@fedora: /tmp % m68k-linux-gnu-gcc -Ikhdr-v4.16-rc7-194-g29d9d38/include -g -c si.c -o si-2.o pts/0, esyr@fedora: /tmp % for i in si-orig.o si-1.o si-2.o; do echo -------- $i; objdump -t -j .rodata $i; objdump -s -j .rodata $i; done -------- si-orig.o si-orig.o: file format elf32-big SYMBOL TABLE: 00000000 l d .rodata 00000000 .rodata 00000000 l O .rodata 00000004 lower_offset si-orig.o: file format elf32-big Contents of section .rodata: 0000 00000012 .... -------- si-1.o si-1.o: file format elf32-big SYMBOL TABLE: 00000000 l d .rodata 00000000 .rodata 00000000 l O .rodata 00000004 lower_offset si-1.o: file format elf32-big Contents of section .rodata: 0000 00000012 .... -------- si-2.o si-2.o: file format elf32-big SYMBOL TABLE: 00000000 l d .rodata 00000000 .rodata 00000000 l O .rodata 00000004 lower_offset si-2.o: file format elf32-big Contents of section .rodata: 0000 00000014 .... So, the offset of the si_lower field is 20 at the current HEAD and was 18 at commits v4.16-rc3~17^2 and v4.16-rc1~159^2~20. I believe this is due to the fact that m68k uses 2-byte default alignment and not 4-byte. > signal/x86: Include the field offsets in the build time checks > > arch/x86/kernel/signal_compat.c | 65 ++++++++++++++++++++++++++++++++++++++ > include/linux/compat.h | 4 +-- > include/uapi/asm-generic/siginfo.h | 4 +-- > 3 files changed, 69 insertions(+), 4 deletions(-) > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] siginfo fix for v4.16-rc5 2018-03-31 10:56 ` Eugene Syromiatnikov @ 2018-04-02 20:17 ` Eric W. Biederman 2018-04-03 7:30 ` Geert Uytterhoeven 0 siblings, 1 reply; 7+ messages in thread From: Eric W. Biederman @ 2018-04-02 20:17 UTC (permalink / raw) To: Eugene Syromiatnikov; +Cc: Linus Torvalds, linux-kernel, linux-m68k Eugene Syromiatnikov <esyr@redhat.com> writes: > So, the offset of the si_lower field is 20 at the current HEAD and was 18 at > commits v4.16-rc3~17^2 and v4.16-rc1~159^2~20. I believe this is due to > the fact that m68k uses 2-byte default alignment and not 4-byte. A 2-byte alignment for 4 byte pointers. That is a new one to me. Euguene can you test the patch below. It should be fully robust against this kind of craziness. It certainly passes my BUILD_BUG_ON tests for m68k. Eric From: "Eric W. Biederman" <ebiederm@xmission.com> Date: Mon, 2 Apr 2018 14:45:42 -0500 Subject: [PATCH] signal: Correct the offset of si_pkey and si_lower in struct siginfo on m68k The change moving addr_lsb into the _sigfault union failed to take into account that _sigfault._addr_bnd._lower being a pointer forced the entire union to have pointer alignment. The fix for _sigfault._addr_bnd._lower having pointer alignment failed to take into account that m68k has a pointer alignment less than the size of a pointer. So simply making the padding members pointers changed the location of later members in the structure. Fix this by directly computing the needed size of the padding members, and making the padding members char arrays of the needed size. AKA if __alignof__(void *) is 1 sizeof(short) otherwise __alignof__(void *). Which should be exactly the same rules the compiler whould have used when computing the padding. I have tested this change by adding BUILD_BUG_ONs to m68k to verify the offset of every member of struct siginfo, and with those testing that the offsets of the fields in struct siginfo is the same before I changed the generic _sigfault member and after the correction to the _sigfault member. I have also verified that the x86 with it's own BUILD_BUG_ONs to verify the offsets of the siginfo members also compiles cleanly. Cc: stable@vger.kernel.org Reported-by: Eugene Syromiatnikov <esyr@redhat.com> Fixes: 859d880cf544 ("signal: Correct the offset of si_pkey in struct siginfo") Fixes: b68a68d3dcc1 ("signal: Move addr_lsb into the _sigfault union for clarity") Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> --- include/linux/compat.h | 6 ++++-- include/uapi/asm-generic/siginfo.h | 7 +++++-- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/include/linux/compat.h b/include/linux/compat.h index e16d07eb08cf..d770e62632d7 100644 --- a/include/linux/compat.h +++ b/include/linux/compat.h @@ -221,6 +221,8 @@ typedef struct compat_siginfo { #ifdef __ARCH_SI_TRAPNO int _trapno; /* TRAP # which caused the signal */ #endif +#define __COMPAT_ADDR_BND_PKEY_PAD (__alignof__(compat_uptr_t) < sizeof(short) ? \ + sizeof(short) : __alignof__(compat_uptr_t)) union { /* * used when si_code=BUS_MCEERR_AR or @@ -229,13 +231,13 @@ typedef struct compat_siginfo { short int _addr_lsb; /* Valid LSB of the reported address. */ /* used when si_code=SEGV_BNDERR */ struct { - compat_uptr_t _dummy_bnd; + char _dummy_bnd[__COMPAT_ADDR_BND_PKEY_PAD]; compat_uptr_t _lower; compat_uptr_t _upper; } _addr_bnd; /* used when si_code=SEGV_PKUERR */ struct { - compat_uptr_t _dummy_pkey; + char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD]; u32 _pkey; } _addr_pkey; }; diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h index 4b3520bf67ba..6d789648473d 100644 --- a/include/uapi/asm-generic/siginfo.h +++ b/include/uapi/asm-generic/siginfo.h @@ -94,6 +94,9 @@ typedef struct siginfo { unsigned int _flags; /* see ia64 si_flags */ unsigned long _isr; /* isr */ #endif + +#define __ADDR_BND_PKEY_PAD (__alignof__(void *) < sizeof(short) ? \ + sizeof(short) : __alignof__(void *)) union { /* * used when si_code=BUS_MCEERR_AR or @@ -102,13 +105,13 @@ typedef struct siginfo { short _addr_lsb; /* LSB of the reported address */ /* used when si_code=SEGV_BNDERR */ struct { - void *_dummy_bnd; + char _dummy_bnd[__ADDR_BND_PKEY_PAD]; void __user *_lower; void __user *_upper; } _addr_bnd; /* used when si_code=SEGV_PKUERR */ struct { - void *_dummy_pkey; + char _dummy_pkey[__ADDR_BND_PKEY_PAD]; __u32 _pkey; } _addr_pkey; }; -- 2.14.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [GIT PULL] siginfo fix for v4.16-rc5 2018-04-02 20:17 ` Eric W. Biederman @ 2018-04-03 7:30 ` Geert Uytterhoeven 2018-04-03 14:27 ` Eric W. Biederman 0 siblings, 1 reply; 7+ messages in thread From: Geert Uytterhoeven @ 2018-04-03 7:30 UTC (permalink / raw) To: Eric W. Biederman Cc: Eugene Syromiatnikov, Linus Torvalds, Linux Kernel Mailing List, Linux/m68k Hi Eric, On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Eugene Syromiatnikov <esyr@redhat.com> writes: > >> So, the offset of the si_lower field is 20 at the current HEAD and was 18 at >> commits v4.16-rc3~17^2 and v4.16-rc1~159^2~20. I believe this is due to >> the fact that m68k uses 2-byte default alignment and not 4-byte. > > A 2-byte alignment for 4 byte pointers. That is a new one to me. Not just for pointers, also for int and long. And m68k is not the only architecture having such alignment rules. > Euguene can you test the patch below. It should be fully robust against > this kind of craziness. It certainly passes my BUILD_BUG_ON tests for > m68k. > > Eric > > From: "Eric W. Biederman" <ebiederm@xmission.com> > Date: Mon, 2 Apr 2018 14:45:42 -0500 > Subject: [PATCH] signal: Correct the offset of si_pkey and si_lower in struct siginfo on m68k > > The change moving addr_lsb into the _sigfault union failed to take > into account that _sigfault._addr_bnd._lower being a pointer forced > the entire union to have pointer alignment. The fix for > _sigfault._addr_bnd._lower having pointer alignment failed to take > into account that m68k has a pointer alignment less than the size > of a pointer. So simply making the padding members pointers changed > the location of later members in the structure. > > Fix this by directly computing the needed size of the padding members, > and making the padding members char arrays of the needed size. AKA > if __alignof__(void *) is 1 sizeof(short) otherwise __alignof__(void *). > Which should be exactly the same rules the compiler whould have > used when computing the padding. __alignof__(void *) is 2 not 1 on m68k. > I have tested this change by adding BUILD_BUG_ONs to m68k to verify > the offset of every member of struct siginfo, and with those testing > that the offsets of the fields in struct siginfo is the same before > I changed the generic _sigfault member and after the correction > to the _sigfault member. > > I have also verified that the x86 with it's own BUILD_BUG_ONs to verify > the offsets of the siginfo members also compiles cleanly. > > Cc: stable@vger.kernel.org > Reported-by: Eugene Syromiatnikov <esyr@redhat.com> > Fixes: 859d880cf544 ("signal: Correct the offset of si_pkey in struct siginfo") > Fixes: b68a68d3dcc1 ("signal: Move addr_lsb into the _sigfault union for clarity") > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > --- > include/linux/compat.h | 6 ++++-- > include/uapi/asm-generic/siginfo.h | 7 +++++-- > 2 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/include/linux/compat.h b/include/linux/compat.h > index e16d07eb08cf..d770e62632d7 100644 > --- a/include/linux/compat.h > +++ b/include/linux/compat.h > @@ -221,6 +221,8 @@ typedef struct compat_siginfo { > #ifdef __ARCH_SI_TRAPNO > int _trapno; /* TRAP # which caused the signal */ > #endif > +#define __COMPAT_ADDR_BND_PKEY_PAD (__alignof__(compat_uptr_t) < sizeof(short) ? \ > + sizeof(short) : __alignof__(compat_uptr_t)) On m68k, __alignof__(compat_uptr_t) == 2, so it will use __alignof__(compat_uptr_t) padding bytes. Note that while the test is wrong, the end result is correct :-) Hence you could just use __alignof__(compat_uptr_t) padding bytes unconditionally? > union { > /* > * used when si_code=BUS_MCEERR_AR or > @@ -229,13 +231,13 @@ typedef struct compat_siginfo { > short int _addr_lsb; /* Valid LSB of the reported address. */ > /* used when si_code=SEGV_BNDERR */ > struct { > - compat_uptr_t _dummy_bnd; > + char _dummy_bnd[__COMPAT_ADDR_BND_PKEY_PAD]; > compat_uptr_t _lower; > compat_uptr_t _upper; > } _addr_bnd; > /* used when si_code=SEGV_PKUERR */ > struct { > - compat_uptr_t _dummy_pkey; > + char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD]; > u32 _pkey; > } _addr_pkey; > }; > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h > index 4b3520bf67ba..6d789648473d 100644 > --- a/include/uapi/asm-generic/siginfo.h > +++ b/include/uapi/asm-generic/siginfo.h > @@ -94,6 +94,9 @@ typedef struct siginfo { > unsigned int _flags; /* see ia64 si_flags */ > unsigned long _isr; /* isr */ > #endif > + > +#define __ADDR_BND_PKEY_PAD (__alignof__(void *) < sizeof(short) ? \ > + sizeof(short) : __alignof__(void *)) Likewise. > union { > /* > * used when si_code=BUS_MCEERR_AR or > @@ -102,13 +105,13 @@ typedef struct siginfo { > short _addr_lsb; /* LSB of the reported address */ > /* used when si_code=SEGV_BNDERR */ > struct { > - void *_dummy_bnd; > + char _dummy_bnd[__ADDR_BND_PKEY_PAD]; > void __user *_lower; > void __user *_upper; > } _addr_bnd; > /* used when si_code=SEGV_PKUERR */ > struct { > - void *_dummy_pkey; > + char _dummy_pkey[__ADDR_BND_PKEY_PAD]; > __u32 _pkey; > } _addr_pkey; > }; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] siginfo fix for v4.16-rc5 2018-04-03 7:30 ` Geert Uytterhoeven @ 2018-04-03 14:27 ` Eric W. Biederman 2018-04-03 15:24 ` Josh Juran 0 siblings, 1 reply; 7+ messages in thread From: Eric W. Biederman @ 2018-04-03 14:27 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Eugene Syromiatnikov, Linus Torvalds, Linux Kernel Mailing List, Linux/m68k Geert Uytterhoeven <geert@linux-m68k.org> writes: > Hi Eric, > > On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman > <ebiederm@xmission.com> wrote: >> Eugene Syromiatnikov <esyr@redhat.com> writes: >> >>> So, the offset of the si_lower field is 20 at the current HEAD and was 18 at >>> commits v4.16-rc3~17^2 and v4.16-rc1~159^2~20. I believe this is due to >>> the fact that m68k uses 2-byte default alignment and not 4-byte. >> >> A 2-byte alignment for 4 byte pointers. That is a new one to me. > > Not just for pointers, also for int and long. > And m68k is not the only architecture having such alignment rules. The smallest I have seen previously has been 64bit integers having 32bit alignment. 32bit entities having only 16bit alignment on a 32bit arch was simply a surprise. Even when it works there tend to be good reasons not to do that by default. >> Euguene can you test the patch below. It should be fully robust against >> this kind of craziness. It certainly passes my BUILD_BUG_ON tests for >> m68k. >> >> Eric >> >> From: "Eric W. Biederman" <ebiederm@xmission.com> >> Date: Mon, 2 Apr 2018 14:45:42 -0500 >> Subject: [PATCH] signal: Correct the offset of si_pkey and si_lower in struct siginfo on m68k >> >> The change moving addr_lsb into the _sigfault union failed to take >> into account that _sigfault._addr_bnd._lower being a pointer forced >> the entire union to have pointer alignment. The fix for >> _sigfault._addr_bnd._lower having pointer alignment failed to take >> into account that m68k has a pointer alignment less than the size >> of a pointer. So simply making the padding members pointers changed >> the location of later members in the structure. >> >> Fix this by directly computing the needed size of the padding members, >> and making the padding members char arrays of the needed size. AKA >> if __alignof__(void *) is 1 sizeof(short) otherwise __alignof__(void *). >> Which should be exactly the same rules the compiler whould have >> used when computing the padding. > > __alignof__(void *) is 2 not 1 on m68k. I was not expecting __alignof__(void *) to be 1 on m68k. I was testing for anything crazier than m68k. Since there used to be a short in the hole. If your alignment is less than sizeof(short) aka 2 we do need two bytes of pad in there. >> I have tested this change by adding BUILD_BUG_ONs to m68k to verify >> the offset of every member of struct siginfo, and with those testing >> that the offsets of the fields in struct siginfo is the same before >> I changed the generic _sigfault member and after the correction >> to the _sigfault member. >> >> I have also verified that the x86 with it's own BUILD_BUG_ONs to verify >> the offsets of the siginfo members also compiles cleanly. >> >> Cc: stable@vger.kernel.org >> Reported-by: Eugene Syromiatnikov <esyr@redhat.com> >> Fixes: 859d880cf544 ("signal: Correct the offset of si_pkey in struct siginfo") >> Fixes: b68a68d3dcc1 ("signal: Move addr_lsb into the _sigfault union for clarity") >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> >> --- >> include/linux/compat.h | 6 ++++-- >> include/uapi/asm-generic/siginfo.h | 7 +++++-- >> 2 files changed, 9 insertions(+), 4 deletions(-) >> >> diff --git a/include/linux/compat.h b/include/linux/compat.h >> index e16d07eb08cf..d770e62632d7 100644 >> --- a/include/linux/compat.h >> +++ b/include/linux/compat.h >> @@ -221,6 +221,8 @@ typedef struct compat_siginfo { >> #ifdef __ARCH_SI_TRAPNO >> int _trapno; /* TRAP # which caused the signal */ >> #endif >> +#define __COMPAT_ADDR_BND_PKEY_PAD (__alignof__(compat_uptr_t) < sizeof(short) ? \ >> + sizeof(short) : __alignof__(compat_uptr_t)) > > On m68k, __alignof__(compat_uptr_t) == 2, so it will use > __alignof__(compat_uptr_t) padding bytes. > > Note that while the test is wrong, the end result is correct :-) > > Hence you could just use __alignof__(compat_uptr_t) padding bytes > unconditionally? Unless there is something crazier than m68k that only needs 1 byte alignment for pointers. In which case this code really needs 2 padding bytes to avoid introducing a regression there as historically there was a short in the padding hole. So I don't see anything wrong with the test. >> union { >> /* >> * used when si_code=BUS_MCEERR_AR or >> @@ -229,13 +231,13 @@ typedef struct compat_siginfo { >> short int _addr_lsb; /* Valid LSB of the reported address. */ >> /* used when si_code=SEGV_BNDERR */ >> struct { >> - compat_uptr_t _dummy_bnd; >> + char _dummy_bnd[__COMPAT_ADDR_BND_PKEY_PAD]; >> compat_uptr_t _lower; >> compat_uptr_t _upper; >> } _addr_bnd; >> /* used when si_code=SEGV_PKUERR */ >> struct { >> - compat_uptr_t _dummy_pkey; >> + char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD]; >> u32 _pkey; >> } _addr_pkey; >> }; >> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h >> index 4b3520bf67ba..6d789648473d 100644 >> --- a/include/uapi/asm-generic/siginfo.h >> +++ b/include/uapi/asm-generic/siginfo.h >> @@ -94,6 +94,9 @@ typedef struct siginfo { >> unsigned int _flags; /* see ia64 si_flags */ >> unsigned long _isr; /* isr */ >> #endif >> + >> +#define __ADDR_BND_PKEY_PAD (__alignof__(void *) < sizeof(short) ? \ >> + sizeof(short) : __alignof__(void *)) > > Likewise. > >> union { >> /* >> * used when si_code=BUS_MCEERR_AR or >> @@ -102,13 +105,13 @@ typedef struct siginfo { >> short _addr_lsb; /* LSB of the reported address */ >> /* used when si_code=SEGV_BNDERR */ >> struct { >> - void *_dummy_bnd; >> + char _dummy_bnd[__ADDR_BND_PKEY_PAD]; >> void __user *_lower; >> void __user *_upper; >> } _addr_bnd; >> /* used when si_code=SEGV_PKUERR */ >> struct { >> - void *_dummy_pkey; >> + char _dummy_pkey[__ADDR_BND_PKEY_PAD]; >> __u32 _pkey; >> } _addr_pkey; >> }; > > Gr{oetje,eeting}s, > > Geert ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] siginfo fix for v4.16-rc5 2018-04-03 14:27 ` Eric W. Biederman @ 2018-04-03 15:24 ` Josh Juran 2018-04-03 17:26 ` Andreas Schwab 0 siblings, 1 reply; 7+ messages in thread From: Josh Juran @ 2018-04-03 15:24 UTC (permalink / raw) To: Eric W. Biederman Cc: Geert Uytterhoeven, Eugene Syromiatnikov, Linus Torvalds, Linux Kernel Mailing List, Linux/m68k On Apr 3, 2018, at 10:27 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > >> On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: >> >>> A 2-byte alignment for 4 byte pointers. That is a new one to me. >> >> Not just for pointers, also for int and long. > > The smallest I have seen previously has been 64bit integers having > 32bit alignment. 32bit entities having only 16bit alignment on a 32bit > arch was simply a surprise. Even when it works there tend to be good > reasons not to do that by default. The 68K architecture began as 16-bit with the 68000. Rather than tightening requirements, the 68020 not only maintained compatibility with 16-bit alignment, but also forgave byte-misaligned data accesses (albeit with a performance penalty). Jumping to an odd address is still an error, though. Josh ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] siginfo fix for v4.16-rc5 2018-04-03 15:24 ` Josh Juran @ 2018-04-03 17:26 ` Andreas Schwab 0 siblings, 0 replies; 7+ messages in thread From: Andreas Schwab @ 2018-04-03 17:26 UTC (permalink / raw) To: Josh Juran Cc: Eric W. Biederman, Geert Uytterhoeven, Eugene Syromiatnikov, Linus Torvalds, Linux Kernel Mailing List, Linux/m68k On Apr 03 2018, Josh Juran <jjuran@gmail.com> wrote: > On Apr 3, 2018, at 10:27 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > >> Geert Uytterhoeven <geert@linux-m68k.org> writes: >> >>> On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: >>> >>>> A 2-byte alignment for 4 byte pointers. That is a new one to me. >>> >>> Not just for pointers, also for int and long. >> >> The smallest I have seen previously has been 64bit integers having >> 32bit alignment. 32bit entities having only 16bit alignment on a 32bit >> arch was simply a surprise. Even when it works there tend to be good >> reasons not to do that by default. > > The 68K architecture began as 16-bit with the 68000. Rather than tightening requirements, the 68020 not only maintained compatibility with 16-bit alignment, but also forgave byte-misaligned data accesses (albeit with a performance penalty). Jumping to an odd address is still an error, though. The m68k-linux gcc port started as a clone of the Sun3 port, which has a history dating back to the 68000, which is why it has a maximum of 16-bit alignment. When I implemented ELF support for m68k-linux I wanted to follow the SVR4 ABI (which has 32-bit alignment), but there were too many UAPI structures (esp. struct stat) that would have become incompatible (it would have made it impossible to run ELF binaries on an a.out kernel or vice-versa), so I had to keep the historical mistake. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-04-03 17:26 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-06 7:11 [GIT PULL] siginfo fix for v4.16-rc5 Eric W. Biederman 2018-03-31 10:56 ` Eugene Syromiatnikov 2018-04-02 20:17 ` Eric W. Biederman 2018-04-03 7:30 ` Geert Uytterhoeven 2018-04-03 14:27 ` Eric W. Biederman 2018-04-03 15:24 ` Josh Juran 2018-04-03 17:26 ` Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).