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...
next prev parent 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