From nobody Sun Oct 20 00:48:56 2024 X-Original-To: dev-commits-src-main@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 4XWKZP193gz5ZWn9; Sun, 20 Oct 2024 00:49:01 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XWKZP0gbgz4d2x; Sun, 20 Oct 2024 00:49:01 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729385341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xxF8zjJWG9c6EOc5HFwhYmStgiLu+pwLAaCnfwMA5QA=; b=yuHqDgyAsNkpB4tEqd7lKHefzB2d1JW4jxrbEZRjTOSqXkOBdrSYF4CUmtmNW6k3FMzX/6 W82TAOYnYNSHEpVUeULqZ+VZFFy927g25KpaBripGQkm0U2nPbhmGaC6sg6TfbWs8BseT5 K8Pkf5DLPoQgD8aDuqtrLWa9+8Besh7QAyBM4PDt085adZtie1PCdtFRRT2q+PkaybBZv5 evuZMQvRZlbkLPyPLL5Bkk4mthQVK01rA2gArSxeJKNmdJZDXOC+fXlapUo4QSdFyBqecy 26dRex6QncVnQf94xsj6ee4Z+Z87CA6WnSNyWgLwsTTHYBwlnN3sjL+Oy+FbSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729385341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xxF8zjJWG9c6EOc5HFwhYmStgiLu+pwLAaCnfwMA5QA=; b=f//Ld/qt6mY+ONHJyEPYUzTfPSxOuqOzbmylekutnYy8ZCGOaRXSTYYsepX7LO+6aeAcRH 1Ch+VGQ1cRyqVMyeua/npKjs9SezrHuagBBb22eD0C0W7yR1gI9VwThKBrbPOklWGQDeXk k1ewmvqQQyiQKVpZhUokCDhsiMfA1hIqN59f4WCZLCzSAqdZ4Kn6waw+F1mBN2xlAZ5A0Y Rk2apOhKU6dFOZS5fpxW/YOEee2gZCHQqGEy34CvvinIXDGxVklgWG7bu4s1SFErg8K2WM p3COEwm4/l5JD5bn34lIHn6z6NcebCmbtSHDeUBMzWw8xQmgFwhsaEtVYEODQQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1729385341; a=rsa-sha256; cv=none; b=KuCky3CqdQbe5b/FlMLsbyKaNHHqYMouTrBPm/8O272U+C+QNItCEQKrhILqXO5ZdnwhPZ ueI1t9KT8BQ0Q8ojzHwBgt46KySwwsPy9RRy+t3zobLm3uomAVgnNUNANg2S3TQKL9ms83 o2ncEbUAi5Hb1Hr10nZrs5uZIUfAYno27DrS+Ji6bTxXwH8slvo7barlOL0JQ4yO3pm5u2 57gnuHwrX8CUyQlVlkPZsTSAJWSZ8C3e7nP3Z5/bdrw88jUsKmgXqsu3jQdWisDYghg1R+ mdRlM6m/5GOJjEjZxW72bwNErUiNP1Pvlao7ETBMiLQsyTzfBiH0iBtZwbeShw== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XWKZN5fSTz19rP; Sun, 20 Oct 2024 00:49:00 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 49F52A64806; Sun, 20 Oct 2024 00:48:54 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id AF57E2D029D8; Sun, 20 Oct 2024 00:48:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id TOXHN9KTOpEh; Sun, 20 Oct 2024 00:48:57 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3A4E22D029D2; Sun, 20 Oct 2024 00:48:57 +0000 (UTC) Date: Sun, 20 Oct 2024 00:48:56 +0000 (UTC) From: "Bjoern A. Zeeb" To: Mark Johnston cc: Konstantin Belousov , John Baldwin , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: f4e35c044c89 - main - bus: Set the current VNET in device_attach() In-Reply-To: Message-ID: References: <202410191304.49JD4JoM084001@gitrepo.freebsd.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 19 Oct 2024, Mark Johnston wrote: > On Sat, Oct 19, 2024 at 11:50:40PM +0000, Bjoern A. Zeeb wrote: >> On Sat, 19 Oct 2024, Mark Johnston wrote: >> >>> On Sat, Oct 19, 2024 at 07:10:53PM +0300, Konstantin Belousov wrote: >>>> On Sat, Oct 19, 2024 at 11:36:32AM -0400, John Baldwin wrote: >>>>> On 10/19/24 09:04, Mark Johnston wrote: >>>>>> The branch main has been updated by markj: >>>>>> >>>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=f4e35c044c8988b7452cefbdcc417f5fd723e021 >>>>>> >>>>>> commit f4e35c044c8988b7452cefbdcc417f5fd723e021 >>>>>> Author: Mark Johnston >>>>>> AuthorDate: 2024-10-19 13:03:56 +0000 >>>>>> Commit: Mark Johnston >>>>>> CommitDate: 2024-10-19 13:03:56 +0000 >>>>>> >>>>>> bus: Set the current VNET in device_attach() >>>>>> Some drivers, in particular anything which creates an ifnet during >>>>>> attach, need to have the current VNET set, as if_attach_internal() and >>>>>> its callees access VNET-global variables. >>>>>> device_probe_and_attach() handles this, but this is not the only way to >>>>>> arrive in DEVICE_ATTACH. In particular, bus drivers may invoke >>>>>> device_attach() directly, as does devctl2's DEV_ENABLE ioctl handler. >>>>>> So, set the current VNET in device_attach() instead. >>>>>> I believe it is always safe to use vnet0, as devctl2 ioctls are not >>>>>> permitted within a jail. >>>>>> PR: 282168 >>>>>> Reviewed by: zlei, kevans, bz, imp, glebius >>>>>> MFC after: 1 week >>>>>> Differential Revision: https://reviews.freebsd.org/D47174 >>>>> >>>>> Hmm, there was some other review I thought that had a completely different change. >>>>> That change removed all the vnet stuff from new-bus and instead handled it in >>>>> if.c. Specifically, that if_attach would set a default vnet to vnet0 if there >>>>> wasn't an active vnet at the time. See all the discussion in >>>>> https://reviews.freebsd.org/D42678 which has a patch that I think is correct >>>>> in the comments. >> >> There it was; thanks I didn't misremeber but couldn't find it. >> >> >>> Gleb's proposal, described a bit in D47147, is to require device-based >>> ifnet drivers to fully detach themselves from the parent bus in order to >>> change VNETs. The intent is to eliminate the need for if_vmove() and >>> all the complexity it entails. This would also eliminate the need for a >>> "home" VNET, referenced in the patch that you reference here. >> >> Will it? >> >> I asked for a discussion elsewhere but it seems we are having it here now... > > I'm responding to John's question and Kostik's follow-up, nothing else. > The inline patch in D42678 seems fine, I don't have strong feelings > about it, but I believe it is not sufficient to fix the PR in question > (it still assumes that the current vnet is already set). > >> I am still inclined to ask: >> - how do you want a vnet to attach an unknown to itself device? From >> the outside? >> - How to you pass it to a child-vnet without escalating priviledges to >> outside of the host system (vnet0)? >> - Is, e.g., a vcc device [CXGBE(4)] a physical interface? >> - How do you pass a controlled set of other non-clonable devices in (or >> did we get rid of them all)? The inital idea was still that the >> "host" has somehow control over what child can create... >> { I recently tried tuntap in a vnet and it blew up badly by not going >> away } >> - exmaple: I really would love, e.g., a vlan interface to be passed to a >> vnet but but not the pyhsical interface. Can we? >> - How will we do with wlan interfaces (which are cloned) but may not own >> the hardware (kind-of similar to the vcc example)? I know there are >> special PRIV checks for those currently. >> - how does a detach in a vnet work and where will the physical interface >> re-appear for (automatic) attachment? just detached in that jail? >> vnet0? the parent jail? >> - what happens on vnet destroy? (same as last question)? >> - Are we just going to build a vmove on a layer which doesn't have >> anything to do with networking per-se as a special case for some >> interfaces but not others? > > These are excellent questions which should be posed to Gleb when his > proposal is fleshed out. In the meantime, I only aimed to fix an > obvious shortcoming of an existing hack which has been around for over > 10 years. ACK & ACK -- Bjoern A. Zeeb r15:7