From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 549714266B1; Thu, 2 Jul 2026 09:29:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782984570; cv=none; b=ZjxLoMJiyYr1oOGnJmc2Nco32zueRf6s2a0yfdkP9R0N6Uve6zawXxtIFLhfP6yN/35Q0IsBkI7S2kEqgnk4hWKz6gohkzC4wAe8k8G4d2SQpVhU7ItpnYczB3xG9pkYBV5kiQKcU0QMrNs//Fj0p+II4iZuSuL+CJhhcnKBeNQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782984570; c=relaxed/simple; bh=BW4Hg/WHgx/wqWP0dHNwLEanMvutIGbvuRLcltLhx2w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cblM7e7qzixEeAl2HcKmFvr+48m8dpXfVDRUkNg0G63j1TpLM5+H64UkqDAX+z59PbFFeaXjSnDbY+spQyTZb4HNUZAHKYyehXDqwWLzx/Y72Bhoz1rXknstx0VVRrXpHaU9IPSx+DX3M1p6aGQ5bYVLTv3kHW9dTpiCb7I74yE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e1pHYz6M; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e1pHYz6M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 451721F000E9; Thu, 2 Jul 2026 09:29:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782984568; bh=dXbKba1B/CK8l+IdjdOVTRZMbCjkk+ESMNksJd+Czxo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=e1pHYz6M5wc22UEPY39S7MqKIR92W35h+OZlUX2//BA9xeVm6wvj0cP/u3aO6dTZv TIGdOAH18KZ9CiNo9hwRzrtH4q3kCxAjc+BVpLC/mE79gxFg34GOJLmNNPVHPwuZwn QTUBMCFpPGmCmUPxtbpGeUX01UhCAbMPQD0nBOccht09xoOs5VOphvm+jF7QvULdP3 Bl4QTqSqA42sKKvKE4pWXPHR23G7F3Rvp/m/9dsQxmChy3LNDpRsSKfdg1foo4Hx9e 7Pk+jESfziUy3hlUU+M4wL3z9Bt/TjFONYY3iLKAYClvwn7AGspasA4SUBxrZu2Hrb 29+piCtGSKm+A== Date: Thu, 2 Jul 2026 11:29:22 +0200 From: Christian Brauner To: Andy Lutomirski Cc: John Ericson , Li Chen , Cong Wang , linux-arch , LKML , linux-fsdevel , linux-api , Arnd Bergmann , 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 Subject: Re: [RFC] Null Namespaces Message-ID: <20260702-markt-haifisch-kiesgrube-8580a3636064@brauner> References: <20260629-hauer-erhitzen-sobald-96d3dff68707@brauner> <20260630-kippen-jobaussicht-restriktionen-2149cc663b22@brauner> <372c1f13-e6eb-46e6-8685-3c39da4e9f72@app.fastmail.com> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: > > > 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! > > > > Christian, how would you feel about a variant of nullfs that fails all > operations instead of acting as if it were empty? (I'm far from > convinced that this would actually be better, but it at least seems > pretty straightforwardly possible. And obviously the > nullfs-at-the-root-of-everything would not want this variant.) I think it would have to be a separate fs type: failfs. The problem is - if taken to its logical extreme - it would have to refuse statfs and fstatfs as well which means you can't discover it. You'd still be able to get your cwd and root of course via /proc/self/{cwd,root}. So for that we could just add: FD_FAILFS_ROOT I don't have quarrels with that. I can add that and it seems genuinely useful. I'd again keep it as a kernel-only thing (not mountable) for now until we have an idea whether the semantics work out... (Btw, I've done something vaguely similar for kthreads in work to be merged coming cycle. Their root and pwd are in a _separate_ nullfs that can't even be overmounted. Which means you can't do arbitrary lookup or I/O in init's fs state from kthreads anymore without having to use an explicit scoped_with_init_fs() override with init's fs state temporarily. Which means that hopefully things like ksmbd will not happen again...)