Re: [RFC PATCH 0/8] experimental struct filename followups

Christian Brauner <[email protected]>
Newsgroups org.kernel.vger.audit,org.kernel.vger.io-uring,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel
Message-ID <20260114-wildschwein-halbieren-bf41844e3f38@brauner>
On Wed, Jan 14, 2026 at 02:15:47AM +0000, Al Viro wrote:
> On Mon, Jan 12, 2026 at 11:00:10AM +0100, Christian Brauner wrote:
> > On Thu, Jan 08, 2026 at 07:41:53AM +0000, Al Viro wrote:
> > > This series switches the filename-consuming primitives to variants
> > > that leave dropping the reference(s) to caller.  These days it's
> > > fairly painless, and results look simpler wrt lifetime rules:
> > > 	* with 3 exceptions, all instances have constructors and destructors
> > > happen in the same scope (via CLASS(filename...), at that)
> > > 	* CLASS(filename_consume) has no users left, could be dropped.
> > > 	* exceptions are:
> > > 		* audit dropping the references it stashed in audit_names
> > > 		* fsconfig(2) creating and dropping references in two subcommands
> > > 		* fs_lookup_param() playing silly buggers.
> > > 	  That's it.
> > > If we go that way, this will certainly get reordered back into the main series
> > > and have several commits in there ripped apart and folded into these ones.
> > > E.g. no sense to convert do_renameat2() et.al. to filename_consume, only to
> > > have that followed by the first 6 commits here, etc.
> > > 
> > > For now I've put those into #experimental.filename, on top of #work.filename.
> > > Comments would be very welcome...
> > 
> > Yeah, that looks nice. I like this a lot more than having calleee
> > consume it.
> > Reviewed-by: Christian Brauner <[email protected]>
> 
> FWIW, I've folded that into #work.filename and reordered the things to a somewhat
> saner shape.  Will post the updated series shortly.
> 
> Open questions:
> 
> 	* Exports.  Currently we have getname_kernel() and putname()
> exported, while the rest of importers is not.  There is exactly one

Tbh, I don't find that too bad. It would be elegant if we could wipe
that completely but I don't think that this is a big deal...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.