From nobody Thu Dec 19 13:41:03 2024 X-Original-To: freebsd-jail@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 4YDWsf65Xpz5hDVR for ; Thu, 19 Dec 2024 13:41:10 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YDWsf2ffKz4ZPq; Thu, 19 Dec 2024 13:41:10 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-3a8ed4c8647so5119875ab.1; Thu, 19 Dec 2024 05:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734615669; x=1735220469; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=kHWUUM/ckJQixBdHGp1puj8DV9ks8pUJJ4RxoJGnF/M=; b=LbcDMcF2rNQyaqZ4Qixkdc1UR2jvbHztwI7tOtmVdNW55pkqvlNuXXQf20PXZUXeTW QDYepN6OfKt91tNErhSmopcf/SbeGEFysvSexUCbpwwhdFJM5PuUVM0HLRV1oxtR+ZzS LmWCjJ5jyht2ug7Zb1VRhFoL7sdLQCND6UsWVFOVDqQcbWn78SFpD9lKa5rkY94k5s0y y6QYy+RcXk/1g8DNga5dpaiqdKiS2Gd+gy5k2zMIDvyr8MWpgwkxwNw2iu0SiTE+fFRF H3Jrbxdbt5uQKq+Swsl+TGr/9SV/Zv6aN8BfDa0w785mB0wJnt5oZN7/MDfR6vMpSBLt 1lJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734615669; x=1735220469; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kHWUUM/ckJQixBdHGp1puj8DV9ks8pUJJ4RxoJGnF/M=; b=IR30NVme8zyMk846+11uX6ay/j6fMz6x8V/959Jx3g6UQeS+8M8a6i2Z/31baIxbBJ HvOP5c4+RmJZtnYWRLQhWl3dZ82tTyWFyLDokTNFwXHUf91hD5BJ0gVv4zs1X7DQHCe1 BvrnFDbt10FFmQTQ6y23xp0q9LENYLAdvtKM3E54t00brqxEhMbEVFOZGa4/eAUjkjrL DVqh6H+5HvGlXNQK/OHtDR7zU2nFCnCmjeuOABzEenvFST0rWnCl+0IEaQJevB085K/N avjQlNX9pM+/enqZ5xD+DNEYZWVPC+qLWUZESCEHMRNf2fkcrvU10r/5e1yocO6PHEGN C+MQ== X-Gm-Message-State: AOJu0YwR1i5ouQyq/2tXmnnmzgykjmB+7BOEewMAsI9oE/vqCnaIzsBr VkjkXcDB22wt9VqylzKJ21VaHpRBPTgQ1BnUW4OQNmexFYpUKoVZXtDJHg== X-Gm-Gg: ASbGncvDu5bUf/m0mD8IJMbO4laFYdzu9j80c0EmgbMHVMpKlqFcmcCvQaskiWTdNQ4 4w992tt5aZ8mCfZyR6mkd0bJdAQR50jyQZnlUPaE46Myq38ksWv8rBrYqzTblGtX1Ws/dAzK8ZN yaKYl3cu0wUbpCtYzZahlV5IulibjsAfHS2U3H8a057+imO55+MxY+xnQzmYwYY4EYjTHpdAmQP LCiHDg6LfC8m/h68oydFgIefrOfs+SnuqrwMCuYtNX2rmvdvpD/0sH6c/H+8xWo3Mf/6ws= X-Google-Smtp-Source: AGHT+IEt7vaAsFJ7LE9kCh2ZxXBS1XoXMOlDPcBVxCSjxxsWlwAqtvNZYjdsJyzpY3H+fOi3ioUMTA== X-Received: by 2002:a05:6e02:3b89:b0:3a7:dd62:e954 with SMTP id e9e14a558f8ab-3bdbb355fe7mr70927995ab.0.1734615669012; Thu, 19 Dec 2024 05:41:09 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3c0de052ed2sm3180535ab.2.2024.12.19.05.41.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Dec 2024 05:41:06 -0800 (PST) Date: Thu, 19 Dec 2024 08:41:03 -0500 From: Mark Johnston To: Zhenlei Huang Cc: freebsd-jail@freebsd.org Subject: Re: setting VNET tunables in a new jail Message-ID: References: <765C6033-2A81-4CDA-9366-4742F1750421@FreeBSD.org> List-Id: Discussion about FreeBSD jail(8) List-Archive: https://lists.freebsd.org/archives/freebsd-jail List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-jail@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4YDWsf2ffKz4ZPq X-Spamd-Bar: ---- On Thu, Dec 19, 2024 at 11:07:09AM +0800, Zhenlei Huang wrote: > > > > On Dec 19, 2024, at 12:43 AM, Mark Johnston wrote: > > > > On Wed, Dec 18, 2024 at 11:05:46AM +0800, Zhenlei Huang wrote: > >> > >> > >>> On Dec 18, 2024, at 5:19 AM, Mark Johnston > wrote: > >>> > >>> We have a number of sysctls which are defined as tunables, whose values > >>> cannot be changed after boot. Some of these sysctls, such as net.fibs, > >>> are per-VNET so could in principle be changed at jail creation time. > >> > >> For current/15, it is actually doable since my previous work [1] and [2]. > >> > >> A usage example is the test plan in https://reviews.freebsd.org/D41825 > . > >> > >> For short, `kenv some.kenv=foo`, and then create vnet jail, `jail -c xxx persist` . > > > > Oh nice, I didn't know about that. > > > >> Those commits are not MFCed to stable/14 and stable/13, as I'm not satisfied > >> with the implementation. The current implementation is somewhat hacky > >> and I planed to re-work it. > > > > I think it's not quite enough for what I want to do. My main use-case > > is the regression test suite, which I typically run in parallel, so > > there's lots of concurrent jail creation and destruction. Some of those > > jail creation operations may want to set kenv values. Modifying the > > kenv is a global operation, so I can't do that from concurrent test > > runners. > > > >>> I'd find it useful to be able to pass a set of tunables to jail_set(2), > >>> so that corresponding VNET jail has tunables set to the specified > >>> values. For instance, it'd be useful in test suites where I want to > >>> exercise the network stack with different VNET sysctl settings, without > >>> having to configure the test runner at boot time. > >>> > >>> I think the implementation would involve passing an environment to > >>> vnet_alloc(), which would copy the parent VNET context and then iterate > >>> over all VNET tunables in the system, invoking > >>> sysctl_load_tunable_by_oid_locked() in such a way that the custom > >>> environment is used to update the tunable's value. > >> > >> That is per-jail kenv, quite close to my working copy. > > > > You mean, you have some out-of-tree work in progress? > > Yes. I'll publish it when ready. Recently busy working on SYSINIT stuff. Awesome. Please let me know if I can help review or test. > The idea (per-vnet kenv) came when I was working on vnet tunables feature. > > I have ever mentioned this in D46653 [1], but been ignored. I think you hit this once again :) Oops, I'm sorry Zhenlei, I completely missed that. :( > 1. https://reviews.freebsd.org/D46653 > > > > >>> Is there already some way to do what I want? If not, is there some > >>> reason we shouldn't implement this feature? Are there examples of VNET > >>> tunables for which it'd be unsafe to have values differing from the > >>> parent VNET? One can print a list of such variables with "sysctl > >>> -aVNT"; the list is pretty short and I don't see many obvious problems > >>> with allowing them to be modified. > >>> > >> > >> Best regards, > >> Zhenlei > > >