From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A42436165D for ; Tue, 17 Feb 2026 15:08:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771340925; cv=none; b=ktWpuXoN4jmhVZTGGKA/u6zfb9QCODkrr4Hj8XZZ9PcEIke8Gk7miVwpZPwo7oL/9toyfW2RnJP4z2zgaj8+riKdsxKEZwe2o+1REImPivoMx8L5JC554r9PHRlh+CPrEkwtfkHlOp6/fXAuipIYWmpBf3gMVHKhiDFX41XwcEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771340925; c=relaxed/simple; bh=FATg9XsSiPlYwAbae8L/USKuKRBil6Mn8gqbYCmEG2I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=h0GxTSCaL9rK0fhiZIqMy/w3aMVB1wZ3jc7Ar0oFQMloHay/SqPyyFWOyE3jMqkEPo5RaPEz9Xzwu9OnY3YnTysSg140kCqio8VYFV3P5PAficAdyZ/xq491Fymc0vYvLilKHnbPJhnZIXSSHQlaTSip9Hb+uTIKP6forYSsUuA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=a52M6v0x; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Q2wmJ0DP; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="a52M6v0x"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Q2wmJ0DP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771340923; 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=jEc67c+eucBHPlMa8Z8GafQvzyfH5CJQ48/ZIvcQG9w=; b=a52M6v0xqTqdHwvW8OEODxURgLPi+5r7F96w68uz9vr7BQEvYWtS4OZM4czFpgD5aHjldp 0P3wDskid7WK0i+IWEFsr9JkAYwpbjIUMTTfMeBICDjYKtInepmbZVh1zNKxtELa+v5nnX DDVdyvgZlNbSfNcU8a6K3Q4Tb51azSU= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-227-Bp9vg8l_PfS1QNJkgrdx0w-1; Tue, 17 Feb 2026 10:08:42 -0500 X-MC-Unique: Bp9vg8l_PfS1QNJkgrdx0w-1 X-Mimecast-MFC-AGG-ID: Bp9vg8l_PfS1QNJkgrdx0w_1771340921 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4832c4621c2so47324575e9.3 for ; Tue, 17 Feb 2026 07:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1771340921; x=1771945721; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jEc67c+eucBHPlMa8Z8GafQvzyfH5CJQ48/ZIvcQG9w=; b=Q2wmJ0DPwomE3lsee1BYstQjxqAnEoTsy5rJ+GWkPVk8D2TXrPTr+q9n8RfHUtq6SU QkMKme1nOLQPh3W91U2V+9xYt6kUNqX56HkI+vksqVJHb6CzSYBoBA04iEkLOkgvJfCN Ak9ZVvabnKDg1E6BW13xVNL6Sa8FLyHglfTZqy7QFyBj+p/48xxZCUIIJM4N+rEyGXRS fKIP2GV0s0i0ZcDAVrdZ+qjYM5Z0bSsjw5cdpD8bvUd3kH5FphEqA1D4QKB6MteiGUIV yfznMv6w5ra0fpKcDt+HWEkfAb+DPIZNnqqil2+Y7sk0/jNVnCXcsc9CyiIpOav8I+n5 dBPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771340921; x=1771945721; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jEc67c+eucBHPlMa8Z8GafQvzyfH5CJQ48/ZIvcQG9w=; b=q9vYfA3JwIgkqiaNi00PX4OpQ/Al6X1qHHtrqchNI43ZgAUBuUxu50ffmzg12j7nYV FJugk8CEjIzeRhxPWs3US8nukxWnpFnARrWtk0QqkvvSRtLqKTJTlcHn5Kq7uljjmpdt l1gWpmL4J3r+1/3dfwndmiN1PZmiiyelmELWabVbGYToAKrGuuhPCJTVf6StCFHTiR76 +/kijaEIEDqdmhGF2uujgb3zmXMQsj+k3WUD2TWnMFL4ECjBl9f60eEZL61eGuGMKTqq iiOVAX7SFVNM7Xjzty5AFiMDh4xMwhNqShaHDjHVn+Ew305DOt+xiaTYVm8XbEAm+c1o z7xQ== X-Forwarded-Encrypted: i=1; AJvYcCXSFabdcugGJuEXmYnxAK/cdKWQUb8lRs8mRFKxOcsFMqeIxCZtIprFhU1zfXqJpFdyxmJOfHw=@vger.kernel.org X-Gm-Message-State: AOJu0YzuX9iepRfpxyv4Ir0bcYKRRU5zWX+Xa5bC8iinUKUxqd8q6LKi CVCjrjzgCvELPkLeStJLtapLnjgnvIsApaZdK3YkmPDn/2TvuMtMbSCgAs6KOKvbyAk9fCjsllS zkmSB2P4KGVDdXn38YXvu7vdV62emtb1mIEp2oZT4+HI2z1mAeBHSvXVzwA== X-Gm-Gg: AZuq6aJ28BsKn9cU9m80ecDhoOgDWWI0zKWmc8FFl2rlESgfHbiw73GJKlktX8mVjDd JZ8UEcHeDRo/laZmBBx3pJ4bs+XNjdHAreBr6+JW8eDzpz0jCIWLvFZ4xC8AvIldktWpLxZclWU ROh/E+IRIAGfqnwMV/tpqCxc2Mg2yQZut2iK8EhtMBa01bNQkq3ZxPjLYFOW187Le94hlC4gz58 KJUR6WqotkbfBYZq2Y9KHyrc94RPdY8gTgH7tO/sE5A9kgEhryw/+5XD37Ao9r73H7lY2mZuRR1 8j978GW+HDZ0JOAJyCVOMLxCFi3S0Y9wCocSzWm4h/3HSCEx85IXSUr3x3dLbVIf8mGvBCH0Dlb b5CJZX50MwV97QzF/Gk1gFhTOlc53uFM881IB6SmEXUpqp7rzBHnkKYFT8IaLelVkAxSoIhI= X-Received: by 2002:a05:600c:1c1c:b0:477:7b16:5fb1 with SMTP id 5b1f17b1804b1-483739ff8damr256414545e9.7.1771340920684; Tue, 17 Feb 2026 07:08:40 -0800 (PST) X-Received: by 2002:a05:600c:1c1c:b0:477:7b16:5fb1 with SMTP id 5b1f17b1804b1-483739ff8damr256413865e9.7.1771340920135; Tue, 17 Feb 2026 07:08:40 -0800 (PST) Received: from sgarzare-redhat (host-82-53-134-58.retail.telecomitalia.it. [82.53.134.58]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4837b64b08bsm102571985e9.6.2026.02.17.07.08.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 07:08:39 -0800 (PST) Date: Tue, 17 Feb 2026 16:08:33 +0100 From: Stefano Garzarella To: Bobby Eshleman , Paolo Abeni , Jakub Kicinski , Daan De Meyer , "Michael S. Tsirkin" Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Stefan Hajnoczi , "Michael S. Tsirkin" , Jason Wang , Eugenio =?utf-8?B?UMOpcmV6?= , Xuan Zhuo , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Bryan Tan , Vishnu Dasa , Broadcom internal kernel review list , Shuah Khan , Long Li , Jonathan Corbet , linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, netdev@vger.kernel.org, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kselftest@vger.kernel.org, berrange@redhat.com, Sargun Dhillon , linux-doc@vger.kernel.org, Bobby Eshleman Subject: Re: [PATCH net-next v16 01/12] vsock: add netns to vsock core Message-ID: References: <20260121-vsock-vmtest-v16-0-2859a7512097@meta.com> <20260121-vsock-vmtest-v16-1-2859a7512097@meta.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260121-vsock-vmtest-v16-1-2859a7512097@meta.com> Hi, On Wed, Jan 21, 2026 at 02:11:41PM -0800, Bobby Eshleman wrote: >From: Bobby Eshleman > >Add netns logic to vsock core. Additionally, modify transport hook >prototypes to be used by later transport-specific patches (e.g., >*_seqpacket_allow()). > >Namespaces are supported primarily by changing socket lookup functions >(e.g., vsock_find_connected_socket()) to take into account the socket >namespace and the namespace mode before considering a candidate socket a >"match". > >This patch also introduces the sysctl /proc/sys/net/vsock/ns_mode to >report the mode and /proc/sys/net/vsock/child_ns_mode to set the mode >for new namespaces. talking about this new feature with Daan (in CC) we were discussing a possible change to `child_ns_mode`. Currently, if two or more administrator processes in the same namespace set `child_ns_mode`, they compete. Obviously, after unshare()/clone(), the process can always access `ns_mode` to check if everything went well and eventually retry. Daan suggested a more conservative approach, allowing `child_ns_mode` to be written only once (a bit like we did in the old version when the child could change the mode only once). This way, most users who want isolation write `local` in `child_ns_mode` at startup in the init_ns. At that point the user and can be sure that no other process (including administrators, e.g., container managers) can change it, so all new namespaces will have `local` mode. I think we should support this option in some way, because it seems to simplify the user space in most common cases (ensure isolation). I see few options for doing this: 1. Change the behavior of `child_ns_mode` to be written only once, but this would limit other possible use cases where `child_ns_mode` can be changed more than once (I don't know if Bobby had any in mind). 2. Add a new sysctl `child_ns_mode_lockin` (or something similar), which can only be written once with a mode (local or global). A write on this will also locks `child_ns_mode`, of course. 3. Add a new `local-locked` mode, reusing the same sysctl. If we go for 1, maybe we can do it in 7.0, or not? 2 and 3, on the other hand, may have to wait until the next release. What do you think? Any comments? Thanks, Stefano