From nobody Sat Oct 19 23:50:40 2024 X-Original-To: dev-commits-src-all@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 4XWJHC0VRJz5ZSnL; Sat, 19 Oct 2024 23:50:47 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4XWJHC016Hz4VDF; Sat, 19 Oct 2024 23:50:47 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729381847; 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=BMUAAqo+ub4HUhbGdTmGNtYGlr1Cf9fAfPwL8x/8Kb8=; b=Y3GhbDt613kNws5xzvXgyhhmefYtrF8p7IJ28ZMfRFSJZV5xkF5n3QW5gVT5znytABPQ4T W1Dws+7egyn9V/UMv7s16AttDTwgxaQp00HWL/a441S5WHjGSpMbVjfdyLLakcRQOfe7Qb rrxOfoHJvOp48zbA13c7IKQ8xi/Ap4/QINxL8SJbOVx2l61LkWuagzST4yhvSobOpA7ZGs gUEdB5ZyVgmRQWJlUpOj7D0T/NzSkDgXj+77WQnCf8lDCec1WMI8/W1qm6oEw1hwqZGgaQ ND3oD/4KkzXNH2m7jV0gXnJ+Utguh/uoW5vuNLmrbMFLOD/c0PrOLifRPMMCQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729381847; 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=BMUAAqo+ub4HUhbGdTmGNtYGlr1Cf9fAfPwL8x/8Kb8=; b=cIh9p6l9yWOsCFd0SH0+q4H6EEzecLjL77JXTkiZ2mfh3ODbNpUfUztgaTVrkkLMz73/HV 4i2h8JiDn4s9+OpEzsmQFN1IKiYLjsvPDB/vKRv/KlTAbX9BojMijEJiGLqjuzW2VW2/TA bGp/iMgb4qZ3SJCctA7Z2xd+wzQH7TDqLMcLvCDZ+A4/qIqw2UOhaB3D/8MQ1ebLkC2k/y HyGYPFerTON7TMciookvJywcbW1oVLrv/kmhBKu0l4TKgmC6TcHdb2oyUdCHz3rql2Exbj hMlTXze3pyrGIZPb3d6mR3fo7xJNg+5zL/tKTe89Dqn60GjQ6eeozFJqeqsljQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1729381847; a=rsa-sha256; cv=none; b=rG/XIxpYNeoZyHRAcxVuCA100rjlkEJYQNizyCeYEGzHPBkAGjQMm1ZDZDSve0h6ETibeY QU+QYLG0fVhbn60cV5gzxPr1gRwK1F6ZJ5aV9bQkJcn/4bufY5HNorP1Z60n2I6ACbfsmu Ve1CRhzOoM0U4pWevhL9VP0V8K3dufBixpmgdw+oezsMa9915bQ4RaN5SikYhoe+RnSfOl JgOk3j76g9Q+2XG4AwtMh2AILaY9UU0+q4XfrzkAOfd5Y7KMV3uIVXBMfuePQWIKO1rBUO TWw1dg2Lgpa6qkaI5vW+dNZKltXV4bBkmytLoogQprRXrT2nizJ7hS4PRDxwCw== 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 4XWJHB55Yhz1B09; Sat, 19 Oct 2024 23:50:46 +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 C7B06A64805; Sat, 19 Oct 2024 23:50:38 +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 22D1F2D029D8; Sat, 19 Oct 2024 23:50:43 +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 ko2asN4NCXVe; Sat, 19 Oct 2024 23:50:41 +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 C05082D029D2; Sat, 19 Oct 2024 23:50:41 +0000 (UTC) Date: Sat, 19 Oct 2024 23:50:40 +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 all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@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 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 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? >> In fact, I think that bus level is better. At least, I know that detach >> also might need something by vnet (e.g. mce(4) needs to clear the IPSEC >> offload database on detach, although it still does not do). > > Shouldn't something like this be handled by > if_detach()/ether_ifdetach()? Posed another way, why does device detach > itself need to care about the VNET? IPSec should probably be handled in the per-AF specific data of the interface and be cleared up automatically. If that needs downcalls into HW that's likely where they belong. It has nothing to do with ether(4); wrong layer. > I tend to agree that having VNET knowledge in subr_bus.c is a hack. My > aim was just to fix the panic without making the hack worse. > >> It sounds as if bus_topo_lock() is the right place. May be some other >> name for it is better, like bus_topo_changes_enter(). > -- Bjoern A. Zeeb r15:7