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 B7A6B36C587 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=C0p68Sgg5bfEr+0Dvljy0/BK/ReORJkNT/0hHPZ5EWaqBll93jW4Vu/vA/rkDRQBt85doI+qkCh/Ur66AO9s9LGu/h+owbAXeWgpuEB9+osjyqcThf34CVD5dht7u2btLcsHoGbyXwgatmi6nKBnqDPBVlvlWmxNgot6W26T1w8= 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=DvIR4Xa2; 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="DvIR4Xa2"; 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=1771340924; 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=DvIR4Xa2UBXNvZfVQYJO07QOSLpI6nzQAapaS1fU15OuzIAfjiO4nNnvkQ6k7M3na8OvtE Gsmoz+aeWuYw61WjPynjf9B1ULdyKHHC2Gove/VsGa66uOWcWYqoDtEu0WWALRiV/50hN4 o0Eo+ulmiga0gZrJMnav3w914Zfbukg= 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-477-AsP68V2KOrazWjuHT5AgDA-1; Tue, 17 Feb 2026 10:08:42 -0500 X-MC-Unique: AsP68V2KOrazWjuHT5AgDA-1 X-Mimecast-MFC-AGG-ID: AsP68V2KOrazWjuHT5AgDA_1771340921 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4806cfffca6so50580955e9.2 for ; Tue, 17 Feb 2026 07:08:42 -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=Udvb+exsuAyfiKWRZxwUaxO8CbU0bITQ+wd8PsUtKtexO9FzRcAAbrQTkcWte4v/b/ WMLI82qqWk4AzwydCNAGm+ut3wlL1JZwriuhvEUr4Gylrk/r6GCfy4tD/1ReiVXKJVvV bwBNdN8/X50fs5OVwei24IrFpiw4Py157f/Bw3yU8xddymW2LJlNNN/sAXvEyBqwNUCK CuUVaMu9af8Z5HPvbKPBiW3NYAqLidEAhlwSI9iyZl1rI6gL0GGXkQTZbrcTs46RbUh+ 3Ui/yPFfLXfke3O1fQC+1sSBZ6fa/BmjjdIRSEwp1KvJUVwirp8cdRTP812xZpEaWZ+7 suQQ== X-Forwarded-Encrypted: i=1; AJvYcCUyk96NImPBrgsE4F7KBFKh6L5dOq+pTe74WR/TaINI0iOzpaot+hmIR2+ruHCbuARseVBymaF2TLOI6SQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzflWTtP6+wq7P+XJWcdFJdZNMVMzcgrgSJni+xL+OVTiN50d5J msKXpFxzoeftpwx3BZ63N1givDApQs7vdBaTkakrGAzd3KwGrynDYZefYVUS1X8uTEi3xL37IAh Edc/a4NVApU06o8Vq8vDfONPuIFcFTHp5VdQrH9Iu/epRlGXATZEZiB+5xo3kwxd7Sg== X-Gm-Gg: AZuq6aJjH9RsrWpQLcne//+7snofAS6P1XNCSldzGOfDcP43evv7rV+7uP4mpNI6Zl0 tUbWiBJCF/djKdEkBV9E7ht5TG590t7aOtdWJH0MEl434aXbLs6ajnsuPQ/rofZq5m9PHBOWnJ1 uC+fc8WIH3vtbWkYJMV/vhv9upJIfGy0ya7atnYX7Hx6MB+c2eLpt7SFj3j4LM0vl9t1/rShaNn uzkMtBcTmENgbnzXvyI7/qG2uO2vUrUn0qRp2TM37t83w48tqEMZf6e96VwKvgZIcbBCnP20QUF 3W2Smqh6ua4ToX4x3qYtgx96r1lcRsmfLQcYun0HHiBzVfZcNFk1TdxWoBHjjHVy2jyBh/ljddJ Y4TT+Cxhj5+Lp6Qx2i1Csm5Lal0rBHPfVV997C3qISZLGRqen5j+L+obqFuMJezqCzpDEaM8= X-Received: by 2002:a05:600c:1c1c:b0:477:7b16:5fb1 with SMTP id 5b1f17b1804b1-483739ff8damr256414735e9.7.1771340920714; 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: linux-kernel@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