From nobody Sat Feb 7 06:21:32 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 07BF3350D44; Wed, 29 Oct 2025 12:21:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761740510; cv=none; b=KcswvWOS2FDNpH9yDkjIGOZkRXe3w9hCTPiBfBr1dIvU2B2tD8oxDHawPX6RN3/mEMDkpx3PpvVulWCf8Q+bxpwbWmQ93+ur+rrE8/gHE6Sk1SoWl0aYjhDEuFSgQ8P8Zr8rwgHH2XJcHZ9iIrPHX/4Le73lbC2bHpDdIehNYH8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761740510; c=relaxed/simple; bh=MytxepP0DfHSoS+/OXNPO9l7OLu6SuN3axgNA99B+CQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=H5wEHtVsarN4k+Vub6jUHdvocyor8sq8eNT3eqBNddv3wpnAt/6ALuEYtb+22eABdeDXHXjtM21MVR6nR3s2JzlHMjjX/BSO+CI7wZnPLkSw9O/2zAsyjpr3a+NPgRbC2mUojFG3jkO4roM74zSHI3N0tH74xfNuM5foVioi6rg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IESlURWP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IESlURWP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBE97C4CEF7; Wed, 29 Oct 2025 12:21:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761740509; bh=MytxepP0DfHSoS+/OXNPO9l7OLu6SuN3axgNA99B+CQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=IESlURWPE9H7GfHgu5SdcDuWq6OnRHQitBMAr7+NniY5jzdAP9YvZ49kW5qvx52Gx eQ3CdZmjM2YJektWQZ8Ed378B/94RoDNQs9jlPuHZl9lzUirH8KCEld9v7EW4WxII3 dS2YR4w3HThA64wuFJP5bVNph6FcKrnm/c071qcPw49LARQeZES90TvCyF41FdLOJ5 4MrXdhmyKjzOa//5ZpV+Yf9o1h6ueW4RXvWCDmIYfKaZCJBoI83cuL0nyjK4tv1w5t v0TSfzptikfV5kqEi5ePpPVntpLTQK3dCMBb4OD5CTwt9v237LiocdHVm1dGEG6uL3 yY0z/g7fD0ivw== From: Christian Brauner Date: Wed, 29 Oct 2025 13:20:27 +0100 Subject: [PATCH v4 14/72] nstree: allow lookup solely based on inode 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20251029-work-namespace-nstree-listns-v4-14-2e6f823ebdc0@kernel.org> References: <20251029-work-namespace-nstree-listns-v4-0-2e6f823ebdc0@kernel.org> In-Reply-To: <20251029-work-namespace-nstree-listns-v4-0-2e6f823ebdc0@kernel.org> To: linux-fsdevel@vger.kernel.org, Josef Bacik , Jeff Layton Cc: Jann Horn , Mike Yuan , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , Lennart Poettering , Daan De Meyer , Aleksa Sarai , Amir Goldstein , Tejun Heo , Johannes Weiner , Thomas Gleixner , Alexander Viro , Jan Kara , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, bpf@vger.kernel.org, Eric Dumazet , Jakub Kicinski , netdev@vger.kernel.org, Arnd Bergmann , Christian Brauner X-Mailer: b4 0.15-dev-96507 X-Developer-Signature: v=1; a=openpgp-sha256; l=1240; i=brauner@kernel.org; h=from:subject:message-id; bh=MytxepP0DfHSoS+/OXNPO9l7OLu6SuN3axgNA99B+CQ=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWQysfUYR+/ZEPnpq60cd8W5gga5wB/bWH/O+V/KVX4lg 9Hhd9q8jlIWBjEuBlkxRRaHdpNwueU8FZuNMjVg5rAygQxh4OIUgImYvmBkOPfxsU/VtU+bzW8z LusV/jlRoGWdluVPY8nyC+mnI0seLmdkmH54kX2X+1m/Gp71ktt26N0SCPxx/ZRGyxl5DQvhQLN fvAA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 The namespace file handle struct nsfs_file_handle is uapi and userspace is expressly allowed to generate file handles without going through name_to_handle_at(). Allow userspace to generate a file handle where both the inode number and the namespace type are zero and just pass in the unique namespace id. The kernel uses the unified namespace tree to find the namespace and open the file handle. When the kernel creates a file handle via name_to_handle_at() it will always fill in the type and the inode number allowing userspace to retrieve core information. Signed-off-by: Christian Brauner --- fs/nsfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nsfs.c b/fs/nsfs.c index a6a28d9cb55d..201d6de53353 100644 --- a/fs/nsfs.c +++ b/fs/nsfs.c @@ -502,8 +502,8 @@ static struct dentry *nsfs_fh_to_dentry(struct super_bl= ock *sb, struct fid *fh, return NULL; =20 VFS_WARN_ON_ONCE(ns->ns_id !=3D fid->ns_id); - VFS_WARN_ON_ONCE(ns->ns_type !=3D fid->ns_type); - VFS_WARN_ON_ONCE(ns->inum !=3D fid->ns_inum); + if (fid->ns_inum && (fid->ns_inum !=3D ns->inum)) + return NULL; =20 /* * This is racy because we're not actually taking an --=20 2.47.3