From nobody Fri May 19 15:50:35 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QNBBk6rxsz4C5XY for ; Fri, 19 May 2023 15:50:38 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QNBBj4D3zz47gv for ; Fri, 19 May 2023 15:50:37 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net; dmarc=none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 51F6E3C0199; Fri, 19 May 2023 15:50:35 +0000 (UTC) Date: Fri, 19 May 2023 15:50:35 +0000 From: Brooks Davis To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: RFC: MFC'ng a change to struct mount Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Spamd-Result: default: False [-1.25 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.45)[-0.451]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[brooks]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QNBBj4D3zz47gv X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N 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