Re: [GIT PULL] io_uring updates for 5.14-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/30/21 2:05 PM, Linus Torvalds wrote:
> On Tue, Jun 29, 2021 at 1:43 PM Jens Axboe <axboe@xxxxxxxxx> wrote:
>>
>> - Support for mkdirat, symlinkat, and linkat for io_uring (Dmitry)
> 
> I pulled this, and then I unpulled it again.
> 
> I hate how makes the rules for when "putname()" is called completely
> arbitrary and very confusing. It ends up with multiple cases of
> something like
> 
>         error = -ENOENT;
>         goto out_putnames;
> 
> that didn't exist before.
> 
> And worse still ends up being that unbelievably ugly hack with
> 
>         // On error `new` is freed by __filename_create, prevent extra freeing
>         // below
>         new = ERR_PTR(error);
>         goto out_putpath;
> 
> that ends up intentionally undoing one of the putnames because the
> name has already been used.
> 
> And none of the commits have acks by Al. I realize that he can
> sometimes be a bit unresponsive, but this is just *UGLY*. And we've
> had too many io_uring issues for me to just say "I'm sure it's fine".

I think Dmitry has been beyond patient for this series, I think we
beyond 6 months of very little feedback on the core changes. I've
pinged Al multiple times, but we did have Christian Brauner make
suggestions and acking it. That's not to say that it's perfect,
we'll make changes and improve things.

> I can see a few ways to at least de-uglify things:
> 
>  - Maybe we can make putname() just do nothing for IS_ERR_OR_NULL() names.
> 
>    We have that kind of rules for a number of path walking things,
> where passing in an error pointer is fine. Things like
> link_path_walk() or filename_lookup() act that way very much by
> design, exactly to make it easy to handle error conditions.
> 
>  - callers of __filename_create() and similar thar eat the name (and
> return a dentry or whatever) could then set the name to NULL, not as
> part of the error handling, but unconditionally as a "it's been used".
> 
> So I think this is fixable.

I like the first suggestion in particular, that should be straight
forward. I'll drop this series for now and hopefully we can get it
in an acceptable form soon.

> But I'm *VERY* tired of io_uring being so buggy and doing "exciting"
> things, and when it then starts affecting very core functionality and
> I don't even see ack's from the one person who understands all of
> that, I put my foot down.
>
> No more flaky io_uring pulls. Give me the unambiguously good stuff,
> not this kind of unacked ugly stuff.

I think you're being very unfair here, last release was pretty
uneventful, and of course 5.12 was a bit too exciting with the
thread changes, but that was both expected and a necessary evil.

-- 
Jens Axboe




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux