Date: Fri, 19 May 2023 15:50:35 +0000 From: Brooks Davis <brooks@freebsd.org> To: Rick Macklem <rick.macklem@gmail.com> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: RFC: MFC'ng a change to struct mount Message-ID: <ZGeayxTxxu1F5lBW@spindle.one-eyed-alien.net> In-Reply-To: <CAM5tNy7SdXOF7DXGYVHLEUENQmjHf8FZQwRQ_dGVRr2Ki52KbA@mail.gmail.com> References: <CAM5tNy7SdXOF7DXGYVHLEUENQmjHf8FZQwRQ_dGVRr2Ki52KbA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 19, 2023 at 08:00:02AM -0700, Rick Macklem wrote: > Hi, >=20 > Since there seemed to be interest in it, I have MFC'd most of > the changes needed to run nfsd(8) in a vnet jail to stable/13. >=20 > However, there is one change that *might* affect the VFS KAPI. >=20 > I need to add a pointer called mnt_exjail to struct mount. >=20 > There is a field called mnt_pad0. It is 32bits, but is followed > by a field that is a structure. As such, replacing it with the pointer > does not change the offsets of subsequent fields for amd64. > --> Since mnt_exjail is only used in generic code, this should > not break the VFS KAPI for amd64, I think? > I will check i386, but since it will be replacing a 32bit field with a > 32bit pointer, I suspect it will be ok. >=20 > Does anyone think some other architecture will be broken by this > or know an easy way I can check all arches? Replacing mnt_pad0 with a pointer should be ok. It's proceeded by a pointer and thus properly aligned and followed by struct statfs which contains uint64_t's so there is indeed a gap after mnt_pad0 on 64-bit systems. -- Brooks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZGeayxTxxu1F5lBW>