From: Dmitry Kadashev <[email protected]>
To: Linus Torvalds <[email protected]>
Cc: Jens Axboe <[email protected]>, Al Viro <[email protected]>,
io-uring <[email protected]>
Subject: Re: [GIT PULL] io_uring updates for 5.14-rc1
Date: Tue, 6 Jul 2021 19:06:21 +0700 [thread overview]
Message-ID: <CAOKbgA69m7_KbSS-pnEshd9Bp3JEz2QVTOkQ6u--zs5vZobArg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgjvUoOtggcVb7HRAhy2=LfG1+oKrjg5MZh+bSrKDzyAA@mail.gmail.com>
On Tue, Jul 6, 2021 at 4:40 AM Linus Torvalds
<[email protected]> wrote:
>
> [ back looking at this from doing other merge window stuff ]
>
> On Sat, Jul 3, 2021 at 8:27 AM Dmitry Kadashev <[email protected]> wrote:
> >
> > This is how I originally thought it is going to be, but Al suggested
> > that it eats the name on the failure. Now that I spent slightly
> > more time with it I *suspect* the reason (or a part of it) is making it
> > keep the name on failure would require A LOT of changes, since a lot of
> > functions that __filename_create() calls eat the name on failure.
>
> Ok.
>
> Let's try to keep the changes minimal and simple.
>
> Your original approach with __filename_create() looks reasonable, if
> we then just clean up the end result by making putname() ok with an
> error pointer.
>
> The odd conditional putname() calls were the main issue that made me
> go "this is just very ugly and confusing"
>
> How do the patches end up looking with just that cleanup (and some
> clarifying comment about the very odd "out_putpath" case it had?)
OK, I'll send v7 of the series soon and will CC you.
Also, I've looked at the code again, and I think making
__filename_create() and friends not consume the name (even on error) is
not that much of extra work (but some existing code like
filename_parentat() has to be adjusted, so it's still not completely
trivial). I'll try to do that and will send RFC on top of this series,
so if it turns out to look better / be easier to reason about we can
just switch to that (in another release probably).
Thank you for your help, Linus!
--
Dmitry Kadashev
next prev parent reply other threads:[~2021-07-06 12:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 20:43 [GIT PULL] io_uring updates for 5.14-rc1 Jens Axboe
2021-06-30 20:05 ` Linus Torvalds
2021-06-30 20:14 ` Jens Axboe
2021-06-30 20:18 ` Linus Torvalds
2021-06-30 20:21 ` Jens Axboe
2021-07-02 11:32 ` Dmitry Kadashev
2021-07-02 18:33 ` Linus Torvalds
2021-07-03 15:26 ` Dmitry Kadashev
2021-07-05 21:40 ` Linus Torvalds
2021-07-06 12:06 ` Dmitry Kadashev [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-07-01 15:24 Jens Axboe
2021-07-01 19:20 ` pr-tracker-bot
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=CAOKbgA69m7_KbSS-pnEshd9Bp3JEz2QVTOkQ6u--zs5vZobArg@mail.gmail.com \
[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