From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-a6-smtp.messagingengine.com (flow-a6-smtp.messagingengine.com [103.168.172.141]) (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 189493D6692; Tue, 30 Jun 2026 17:20:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.141 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782840032; cv=none; b=uDYY3lqekG8GPlyy7SQ4sc6YhU+HumuO8PMeQ/aOA2JTGf4xEWcNj7B1UDwowxgUI5YOabsV/RWLhbo68ttOuW46ITh2QrYcfTi0zj5OYDAcej/DycTjUWLcUb17+4pGu+Pzoc2Fyi14XHG1VofXkxOF3Pw9MnnHAB+70YFs1O0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782840032; c=relaxed/simple; bh=SyX5kxtOy/n74SGPEGriKku/5TzujsXwQuC4sCWCa54=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=tNYWytLwvmVhVHWWpwkGfjoMIrpa/4dffYpGKyFJ//EA8WIETc87vcm6GRiIHuybvXqiyuSGvraGarWR3jZSLRX+9vNaduey7jTPwp4LXiOiARyAtJvhyDtd/joGvFfFms4IDvzzY8HG5KfxdIHlZnmMsx0aOuqnD/snDaQfOng= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=johnericson.me; spf=pass smtp.mailfrom=johnericson.me; dkim=pass (2048-bit key) header.d=johnericson.me header.i=@johnericson.me header.b=VNtiFqsK; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=CYop166X; arc=none smtp.client-ip=103.168.172.141 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=johnericson.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=johnericson.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=johnericson.me header.i=@johnericson.me header.b="VNtiFqsK"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="CYop166X" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailflow.phl.internal (Postfix) with ESMTP id 1204B1380313; Tue, 30 Jun 2026 13:20:29 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-05.internal (MEProxy); Tue, 30 Jun 2026 13:20:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnericson.me; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm3; t=1782840029; x=1782847229; bh=SyX5kxtOy/n74SGPEGriKku/5TzujsXw QuC4sCWCa54=; b=VNtiFqsK12Z2kwgdsJ3lfywwskbJMc2rhxDft+sKYWFuVBt0 7OILp0i7EFr19XwjkGlgPs0xQ8QdhMJ1aes1nUUDDrP8pqk7kMVXEN58Ez9Rq0Kc 5JKk7Y3s5JsUqpQ0zTX7mvjrJXYf1L4FnQwqNcmzbKeBrIHBFs86fQIGRdJPfoRU OAmeWJnZCNBV/biE1Ck8YAd2gP0aTzCufXIgBIGYNUcyh5+Ub4CPet07XxwV7ccq ac/TmrNLRUOXL2zgAUEB18kKXFrOhrZO7Dr87YMxao+obSkF+QF2EIYvMJ67w9Ly gKPGG2uchhMAH8n6SCK7Y+XnCA8TKPIZDtjFSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1782840029; x= 1782847229; bh=SyX5kxtOy/n74SGPEGriKku/5TzujsXwQuC4sCWCa54=; b=C Yop166XSLBUkfqOPPw/sv9X7RkOaFOoclhcUodPzDfhSnoVNxgszsKRHqAjo4Auf 04kSrh/E3cLWbe1giLrZvlBpG530vS0oI4k/8ktuwEBN6BGfjgdMn2cUjTiecZpq 2WvEYlfekZvMgrp5o7nRigiDaw7stBO7rly3c5GJ+LeZXhbkLZ/dodrh0FkLJ2cM YapEgyWG5mpyclwsq0Qco4vmgkAHBpVBmkmb7b0/vocw+xQYT7wJsSEDaGTLovvp 2a/PKjLcTVhRIll3PS/Hmr4C/xzbVDikhRBGDCB6Db3ZE40XGK8GhiO34EU9UQ00 PCJFObds4xk5IcPJp0PTA== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGGgGolmyu0ogXLBjub7n86zRQ8XQCuZCS7KOAZMtm7jSuchTomZHqxhb4BMv4fT2 Ki9o5wI9FRu97zHnR7tqI+245ASJaJWBYdvu78Q2qjp/3PcTMYHqOiieul8IObhuxuQdCq plibFZfr9ky0RpzNl6/aOxlZHtUhFkwvRVoOfzghSvX3zyigdWfVFHa+A4d8UnxjYuL+9p HxOw/RsRTDTSJ7/1q122mn8TY6ycs1f/1om/ukNAh2kwTKUplffaoBB2PtW+DK7nVSYNCr Aktrtzs8VVIGlZ7brOUO+nHNiXCnN7zlB/ycbwtyfFz94EHVGJ6VlLNEA8mt4EkEc2lmZ6 AUVIpkL8ejRp52DHJRgprvWQRh4Z/qxSsnld4WCGAoMQzdG4emkMNkye2OyTF2daRormSz nH5J3x5OEs4DbiR6e8ojAaAziMUyHFXI/a+nEI0PKOS0sKvKUj84osa0MObLifw5o/Z7nq xW7EVBbILtlGwH8d79uE7geBnzh7NUUnusOogiITfdfavVIKO/oPLlAptcdcN/j3QJRjP/ fv+xASlb0UPOQzZqFfAPUq+e0rG/UOnr3I7XCd4SgE6Q2LOmLn3Y5eKdioLoQ94JPTZsHv 8TD1pdf1KQdUU1E3V1BBNVpDlFDM8pM3W1Y1iVBTYDgUlvIeMUXNAlxUzk2w X-ME-Proxy: Feedback-ID: ieb4144f1:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 6BBD82CC0083; Tue, 30 Jun 2026 13:20:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AG8qDlxFSDr7 Date: Tue, 30 Jun 2026 13:20:05 -0400 From: "John Ericson" To: "Christian Brauner" Cc: "Li Chen" , "Cong Wang" , linux-arch , LKML , linux-fsdevel , linux-api , "Arnd Bergmann" , "Andy Lutomirski" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "H. Peter Anvin" , "Jan Kara" , "Jonathan Corbet" , "Shuah Khan" , "Al Viro" , "Kees Cook" , "Sergei Zimmerman" , "Farid Zakaria" Message-Id: <372c1f13-e6eb-46e6-8685-3c39da4e9f72@app.fastmail.com> In-Reply-To: <20260630-kippen-jobaussicht-restriktionen-2149cc663b22@brauner> References: <20260629-hauer-erhitzen-sobald-96d3dff68707@brauner> <20260630-kippen-jobaussicht-restriktionen-2149cc663b22@brauner> Subject: Re: [RFC] Null Namespaces Content-Type: text/plain Content-Transfer-Encoding: 7bit I'll throw in the towel after this email, I promise :) On Tue, Jun 30, 2026, at 3:14 AM, Christian Brauner wrote: > I think Al is about to have a stroke reading this... and I might too. Hahaha. Alas, C does have a longstanding beef with discriminated unions --- I can't do anything about that! (Well, other than wait 15 years for this stuff to eventually be rewritten in Rust, that is ;).) > I agree with the sentiment Thanks, I appreciate it :). > You know what the easy solution is: don't allow a struct path to be > empty... Just so we're clear, my quibble here is purely behavioral: the nullfs directory can be opened, right? And that open directory can also be getdents64ed (yielding no entries, since it is empty), right? If I am wrong about these things then sure, no objections from me --- let's ship nullfs FDs right away! My reasoning for being a bit of a weenie on that behavior is just that I think "fail fast" is good. A lot of userspace programs crawl the file space pretty willy-nilly (e.g. they are doing some caching thing, or they are looking for something, etc.). I suspect the nullfs approach is going to result in more "red herring" error messages and google searches about "why can't I write to the working directory, not even as root" etc. I just think "no directory" vs "immutable empty directory" sends a clearer message to userspace, and will align mental models more rapidly. Put another way, if there were no implementation downsides to either approach, I assume everyone else would also slightly prefer "no directory" over "immutable empty directory". >From that premise, I am further presuming that any non-empty `struct path` to a directory that doesn't exist would be a real VFS crime, and so making `optional_path` one way or another is the proper way to implement this behavior. If I am wrong about either step of my reasoning --- that nullfs like every sort of FS ought to be openable/readdirable with sufficient perms at the root, that a valid `struct path` to a "non-object" is bad design --- do say so, and I'll drop the `optional_path` stuff completely. > I disagree with the details of this You mean the unergonomics of making a valid `optional_path`, right? > and touching the whole kernel for this. I want to make sure this is a difference in opinion and not a difference in the view of the facts. The linchpin of my prior email was that very little of the kernel cares about these fields in `struct fs_struct`, or even cares about `struct fs_struct` at all, so this is *not* a "whole kernel" change. Yes, thanks to `current`, a bunch of code *could* look at this stuff if it wants to. But it should *not* want to, regardless of what we do. If there were a way to make parts of `struct task_struct` opaque (without including another header) to enforce this design principle, I would definitely go contribute that. (I remember the desire for something like this coming up with the "fast headers" patches, but there wasn't a good implementation strategy in C, alas.) Likewise, for the tiny few usages outside of `fs/namei.c` that I found, I would be happy to more creatively look at that code to see if I can indeed avoid `struct fs_struct` altogether. Cheers, John P.S. The "regardless of what we do" part was key to my earlier code review argument that gave you "mixture of amusement and slight anger": of course I don't expect other maintainers to keep abreast of subtle null pointer invariants, but the simple rule that nothing but `fs/namei.c` really ought to be consuming these `struct fs_struct` fields is, I believe, all three of: good, already true, and intuitive.