On Fri, Oct 09, 2020 at 11:19:55AM -0700, Peter Collingbourne wrote:
> On Wed, Oct 7, 2020 at 7:11 PM Peter Collingbourne <pcc@xxxxxxxxxx> wrote:
> >
> > On Tue, Sep 8, 2020 at 8:13 AM Dave Martin <Dave.Martin@xxxxxxx> wrote:
> > >
> > > On Fri, Aug 21, 2020 at 10:10:16PM -0700, Peter Collingbourne wrote:
[...]
> > > > diff --git a/include/linux/compat.h b/include/linux/compat.h
> > > > index d38c4d7e83bd..55d4228dfd88 100644
> > > > --- a/include/linux/compat.h
> > > > +++ b/include/linux/compat.h
> > > > @@ -231,7 +231,9 @@ typedef struct compat_siginfo {
> > > > char _dummy_pkey[__COMPAT_ADDR_BND_PKEY_PAD];
> > > > u32 _pkey;
> > > > } _addr_pkey;
> > > > + compat_uptr_t _pad[6];
> > > > };
> > > > + compat_uptr_t _xflags;
> > >
> > > Should we have the same type here for native and compat?
> > >
> > > I don't have a very strong opinion on this, but currently native on
> > > 64-bit arches will have 32 extra bits in _xflags that can never be used
> > > (or have to be defined differently for compat).
> >
> > Good point. I will make this a u64 (although I think 32 bits will
> > probably be more than enough, the distance between si_xflags and
> > si_addr_ignored_bits will be 8 bytes on 64-bit architectures due to
> > alignment so we may as well make all of the bits available).
>
> It turns out that we can't actually make this a u64 because on 32-bit
> platforms this increases the alignment of the union to 8, which breaks
> layout for the other fields in the union. In v12 I will make this a
> u32 so that we don't end up with unusable bits.
u32 seems fine to me.
If we need more bits later, we can always use one of the 32 xflags bits
to indicate that the new field(s) exist.
Cheers
---Dave
