From nobody Sun Oct 20 00:19:41 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 4XWJwg3B3bz5ZVVT; Sun, 20 Oct 2024 00:19:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4XWJwf6WL4z4YFS; Sun, 20 Oct 2024 00:19:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-7b13fe8f4d0so236961285a.0; Sat, 19 Oct 2024 17:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729383585; x=1729988385; 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=Waggl5AcbEDmS92nNLGGK8ioa7ic3rijA3i5QgoUFcc=; b=YLl/iM8voQ+tQL9aGzWdh2ChRrzOfEtcS3R/HpwyEJ0xPMJEYLtIhKge1eDtUleuKt a+bfQz43jkt9qc5WSM1kxJ3ougYe3G4kQ4An7mV2cHtac8an6LDBHlZchWH8lAO+CDjm 4tQM1zC/8TtfCeo7ZoxBCQM+8GIKrjkULz1WbY6z//hyXILFPgsh77xOjUjT6/VKge/y PCQNR60zHkJOgzg16EYRbxKYuOWJPoUCcTPdvnCmdJMAsMhVMJljpDT9OJA94mSTqjnx VBStDFjhZwqvU5O9fgeuDADNnRJY5g+aA1Pnb3gkUls8G1shzu+bc6lDIWbKpYw31mlW CtqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729383585; x=1729988385; 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=Waggl5AcbEDmS92nNLGGK8ioa7ic3rijA3i5QgoUFcc=; b=GtRAjaoS9Ot3AjOZHJNiZxn0VkNUurZvN43ZG806VKUu1UieKe4l6R7AxYPJrQOQ0Q jDVe7iaF80egVIPWUzrs6EUkqQTVZcU070Lv0sRgoiNQYkz/HU9JNLpt0iMloHuXu2jV NOnYYzq8jAlr9pWeSk7uggb/+kLvp8z9lV++OKuqon3efx58+qw/Z/dis9y7c4oZl0IK QzJE8p9Xws8CehfLkTJuvds1QwHcBm/Me7KCt/RBilzrpDhZckxZ3Wlg3vPRf0+kYMKd JDTRC5DhqA1y/XiizxNDoYvbT0TXEpzbSLQHZi2ctrVqXR2QfVerSuXCywC3cO9K8lFe Myaw== X-Forwarded-Encrypted: i=1; AJvYcCUAx2GHc8RKFQBdu9a3g0VmF7iEpnTOit2A8xmTc/TwmMyz/2dbLniMEaPl4kqB+4Y2/wc8@freebsd.org, AJvYcCVfYhXN083+2KINxALgDAf6HorBLKXNLSuzbL1tBs6KbVw+vXY+vyyJJjPOym3/igPrKTUrAG3An/qtujLfFT4S9NbL@freebsd.org, AJvYcCVpdHCDj2skAq1QgNHRzpIVqOLpK5CmUNAjC3Dk6obqQ+kNHhTKBS16y+c+0yXzIhy1FFiH4AhnYYVnNPLqkuotKAlWrZk=@freebsd.org, AJvYcCWXBzoegTxvoA8fAen/3QYgnCKEucwPWh1v5xPLx0AolNG66+d/+kIMApL6BrtZ8OoYRKojSDyVl25fhJWDArI=@freebsd.org X-Gm-Message-State: AOJu0Yx3PjyOKTNEasMmgIWvQ8FFXzPbhvwBfWATqeCcnEPOCEOBfi3B noYLKTiq+JPZQ2SkXO6BRocoNHZbpTAmlsjTeV69IMqBZqVN/PaN5j8jMEjT X-Google-Smtp-Source: AGHT+IET5xHO6eCEcmBZp7IRCbafRI71eguYpBkmCmuLA7XwQTji6QOMSROdSkRwgOt/1hNvd5HPJQ== X-Received: by 2002:a05:620a:4709:b0:7b1:48a5:9290 with SMTP id af79cd13be357-7b157be6bbcmr833014385a.50.1729383585030; Sat, 19 Oct 2024 17:19:45 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b165a5df50sm25593685a.97.2024.10.19.17.19.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Oct 2024 17:19:44 -0700 (PDT) Date: Sat, 19 Oct 2024 20:19:41 -0400 From: Mark Johnston To: "Bjoern A. Zeeb" 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() Message-ID: References: <202410191304.49JD4JoM084001@gitrepo.freebsd.org> 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 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: 4XWJwf6WL4z4YFS X-Spamd-Bar: ---- 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.