public inbox for [email protected]
 help / color / mirror / Atom feed
From: Al Viro <[email protected]>
To: Dmitry Kadashev <[email protected]>
Cc: Jens Axboe <[email protected]>, io-uring <[email protected]>,
	[email protected]
Subject: Re: [PATCH 1/2] fs: make do_mkdirat() take struct filename
Date: Mon, 1 Feb 2021 15:00:42 +0000	[thread overview]
Message-ID: <20210201150042.GQ740243@zeniv-ca> (raw)
In-Reply-To: <CAOKbgA4fTyiU4Xi7zqELT+WeU79S07JF4krhNv3Nq_DS61xa-A@mail.gmail.com>

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...

  reply	other threads:[~2021-02-01 15:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16  4:45 [PATCH 0/2] io_uring: add mkdirat support Dmitry Kadashev
2020-11-16  4:45 ` [PATCH 1/2] fs: make do_mkdirat() take struct filename Dmitry Kadashev
2021-01-25  4:38   ` Jens Axboe
2021-01-26 22:55     ` Al Viro
2021-02-01 11:09       ` Dmitry Kadashev
2021-02-01 15:00         ` Al Viro [this message]
2021-02-01 15:29           ` Al Viro
2021-03-31 16:28             ` Eric W. Biederman
2021-03-31 16:46               ` Al Viro
2021-02-02  4:39           ` Dmitry Kadashev
2020-11-16  4:45 ` [PATCH 2/2] io_uring: add support for IORING_OP_MKDIRAT Dmitry Kadashev
2020-12-04 10:57 ` [PATCH 0/2] io_uring: add mkdirat support Dmitry Kadashev
2020-12-15 11:43   ` Dmitry Kadashev
2020-12-15 16:20     ` Jens Axboe
2020-12-16  6:05       ` Dmitry Kadashev
2021-01-20  8:21       ` Dmitry Kadashev
2021-01-26 22:35 ` Jens Axboe
2021-01-27 11:06   ` Dmitry Kadashev
2021-01-27 16:22     ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2020-11-11 13:25 Dmitry Kadashev
2020-11-11 13:25 ` [PATCH 1/2] fs: make do_mkdirat() take struct filename Dmitry Kadashev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210201150042.GQ740243@zeniv-ca \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox