From nobody Mon Dec 19 16:59:48 2022 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 4NbQtV64x2z1GCFX for ; Mon, 19 Dec 2022 17:00:02 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NbQtT63gmz3lp2; Mon, 19 Dec 2022 17:00:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZTHAWOzm; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1031.google.com with SMTP id o12so9692619pjo.4; Mon, 19 Dec 2022 09:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UZPhz2y24L89bdRjaLOY+mG3dNf9gz03ZS4p8wkVXuw=; b=ZTHAWOzmr1SoXwwr0EUCRxk5rDEvJJbmo5IgcSZs8D+vV9cdOYLrriu5bU1271nKfS W4S/VS4FxPe4LiREKNUU2/xFriJTW1WCsZt+fBj5CK/L+7jrkinQu3lpXxfekA1InRky l4eNgQZTqIJvP7EIslCUxnR2+fo5fbW8Ng/TAq9uQT8LiIyW+STVJee+ciX/v/k2CAcW IMLLtotl/1rWg4hSTddaJmRIhm8p/S/at0XmILgf+Lf4NnPe3RB4pF4i7TuFYPpY0lce YIR1KdduSGu2lv1sE8dD5lmh/w9MJESxjkL46KUCNhjh/Myu9+xnnkgfr3bAQNzqR5bz oU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UZPhz2y24L89bdRjaLOY+mG3dNf9gz03ZS4p8wkVXuw=; b=mrgBEFSVEYGY1DjRjd4xmEOfYOk3xCerbG/kwJNTm7nyWQxraShU6IKqfzK8M7t+3a ub1UO+PqHL2vFeiJNQQuGg9fPWHqzs2Jx2lt7i0ve7YHE1r2WU8QyKUOqokMoII3zxca wxqBWhLohe7FUGp4hLfmLDYxbKHuaFZVbcpcmq0C3CQ+n2boPSrh6gJw+ja27LGrlT2g gpMW3eO2fH4GhruDuZC3xf1GRmpb5TwLYIafAJVjP8p5fKWjIZ2aXneC50lwelsLs+Is zOLD8soGW0RzlClcA/q9SU+35wv7iWKBuKfcZQvZ53xFqh7cRfJwy8C/xFisvTKzx3lY MaXw== X-Gm-Message-State: AFqh2kp71pufdR3u9gMOt1ETzY8BBV63n84xORGow1KnP8eDFEC6A0UN T5YKGDKNZwVzPXYloIfHAUSXDZcieZkpdRh6daA2KEu2AQ== X-Google-Smtp-Source: AMrXdXvlywA29vutbe+6LDn/MBZSjm8D9XtkxAt/74YEUuygNh79/8HFCBvw1cO7YpYKz3CUaorpk2H6VnmXmfgZL2A= X-Received: by 2002:a17:902:d488:b0:191:8cb:fbe6 with SMTP id c8-20020a170902d48800b0019108cbfbe6mr678600plg.60.1671469199878; Mon, 19 Dec 2022 08:59:59 -0800 (PST) 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 References: <1955021.aDjkhKmpDe@ravel> <8351812.Gc231LQI4k@ravel> In-Reply-To: From: Rick Macklem Date: Mon, 19 Dec 2022 08:59:48 -0800 Message-ID: Subject: Re: RFC: nfsd in a vnet jail To: kib@freebsd.org, James Gritton , "Bjoern A. Zeeb" Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e96d9105f0313fba" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NbQtT63gmz3lp2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --000000000000e96d9105f0313fba Content-Type: text/plain; charset="UTF-8" Hi, Kostik expressed some concern w.r.t. using a non-default VNET_NFSD kernel build option and I understand his concern, given that many prefer to use a GENERIC kernel and binary updates. Right now there are 29 NFS variables VNET_DEFINED() and several of them are arrays currently sized at 500. One of the reasons for the non-default VNET_NFSD kernel option was the bloat this caused to the vnet. (Chris expressed concern that adding mountd/nfsd to the vnet would result in bloat/overhead in a previous post to this thread.) Another issue with putting all these variables in the vnet is that the nfsd.ko cannot be loaded (it complains the vnet is out of space) and, as such, options NFSD must be used with VNET_NFSD so that the nfsd is linked into the kernel. As such, I am wondering what others think of this alternate plan? - Pull all the VNET_DEFINE()'d variable (except the 3 manipulated by sysctls) into a structure. - Define a single VNET_DEFINE()'d variable that is a pointer to that structure and then malloc() the structure in the function called by VNET_SYSINIT(). This would result in a malloc'd structure for each vnet jail (for kernels built with VMIMAGE), but would only add 4 variables to the vnet. If a small C file that only consists of the VNET_DEFINE()s for the 4 variables is linked into the kernel whenever the VIMAGE option is specified, then I think nfsd.ko would be loadable. Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_gss for Kerberized mounts or vnet'ng NFS-over-TLS, but those could be handled in a similar manner, I think? So, what do others think of this alternate plan? rick ps: Every use of the vnet'd variables is currently wrapped in a macro called NFSD_VNET(), so the change is pretty easy to do by just re-writing this macro. --000000000000e96d9105f0313fba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Kostik= expressed some concern w.r.t. using a non-default VNET_NFSD kernel
build option and= I understand his concern, given that many prefer to use
a GENERIC kernel and binary= updates.

Rig= ht now there are 29 NFS variables VNET_DEFINED() and several of them
<= div class=3D"gmail_default" style=3D"font-family:monospace">are arrays curr= ently sized at 500. One of the reasons for the non-default
VNET_NFSD kernel option = was the bloat this caused to the vnet.
(Chris <bsd-lists@bsdforge.com> expressed concern that adding mountd= /nfsd
=C2= =A0to the vnet would result in bloat/overhead in a previous post to this
=C2=A0threa= d.)

<= /div>
Another i= ssue with putting all these variables in the vnet is that the nfsd.ko
=
cannot be load= ed (it complains the vnet is out of space) and, as such,
options NFSD must be used w= ith VNET_NFSD so that the nfsd is linked into the
kernel.

As such, I am wondering what others thi= nk of this alternate plan?
- Pull all the VNET_DEFINE()'d variable (except the 3= manipulated by sysctls)
=C2=A0 into a structure.
- Define a single VNET_DEFINE()'d varia= ble that is a pointer to that structure
=C2=A0 and then malloc() the structure in th= e function called by VNET_SYSINIT().
This would result in a malloc'd structure f= or each vnet jail (for kernels
built with VMIMAGE), but would only add 4 variables t= o the vnet.

I= f a small C file that only consists of the VNET_DEFINE()s for the 4 variabl= es
is lin= ked into the kernel whenever the VIMAGE option is specified, then I
think nfsd.ko wo= uld be loadable.

Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_= gss for
K= erberized mounts or vnet'ng NFS-over-TLS, but those could be handled in= a
simila= r manner, I think?

So, what do others think of this alternate plan?

rick
ps: Every use of the vnet'd varia= bles is currently wrapped in a macro called
=C2=A0 =C2=A0 NFSD_VNET(), so the change= is pretty easy to do by just re-writing this macro.

--000000000000e96d9105f0313fba--