Re: [PATCH 1/2] fs: make do_mkdirat() take struct filename

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Feb 01, 2021 at 06:09:01PM +0700, Dmitry Kadashev wrote:

> Hi Al,
> 
> I think I need more guidance here. First of all, I've based that code on
> commit 7cdfa44227b0 ("vfs: Fix refcounting of filenames in fs_parser"), which
> does exactly the same refcount bump in fs_parser.c for filename_lookup().  I'm
> not saying it's a good excuse to introduce more code like that if that's a bad
> code though.

It is a bad code.  If you look at that function, you'll see that the entire
mess around put_f is rather hard to follow and reason about.  That's a function
with no users, and I'm not sure we want to keep it long-term.

> What I _am_ saying is we probably want to make the approaches consistent (at
> least eventually), which means we'd need the same "don't drop the name" variant
> of filename_lookup?

"don't drop the name on success", similar to what filename_parentat() does.

> And given the fact filename_parentat (used from
> filename_create) drops the name on error it looks like we'd need another copy of
> it too?

No need.

> Do you think it's really worth it or maybe all of these functions will
> make things more confusing? (from the looks of it right now the convention is
> that the `struct filename` ownership is always transferred when it is passed as
> an arg)
> 
> Also, do you have a good name for such functions that do not drop the name?
> 
> And, just for my education, can you explain why the reference counting for
> struct filename exists if it's considered a bad practice to increase the
> reference counter (assuming the cleanup code is correct)?

The last one is the easiest to answer - we want to keep the imported strings
around for audit.  It's not so much a proper refcounting as it is "we might
want freeing delayed" implemented as refcount.

As for do_mkdirat(), you probably want semantics similar to do_unlinkat(), i.e.
have it consume the argument passed to it.  The main complication comes
from ESTALE retries; want -ESTALE from ->mkdir() itself to trigger "redo
filename_parentat() with LOOKUP_REVAL, then try the rest one more time".
For which you need to keep filename around.  OK, so you want a variant of
filename_create() that would _not_ consume the filename on success (i.e.
act as filename_parentat() itself does).  Which is trivial to implement -
just rename filename_create() to __filename_create() and remove one of
two putname() in there, leaving just the one in failure exits.  Then
filename_create() itself becomes simply

static inline struct dentry *filename_create(int dfd, struct filename *name,
                                struct path *path, unsigned int lookup_flags)
{
	struct dentry *res = __filename_create(dfd, name, path, lookup_flags);
	if (!IS_ERR(res))
		putname(name);
	return res;
}

and in your do_mkdirat() replacement use
	dentry = __filename_create(dfd, filename, &path, lookup_flags);
instead of
        dentry = user_path_create(dfd, pathname, &path, lookup_flags);
and add
	putname(filename);
in the very end.  All it takes...