Re: [PATCH for-next] io_uring/query: check for loops in in_query()

[Pavel Begunkov <asml.silence@gmail.com>]

On 9/16/25 19:33, Jens Axboe wrote:
> On 9/16/25 9:05 AM, Pavel Begunkov wrote:
>> I'd rather delay non fatal signals and even more so task work
>> processing, it can't ever be reliable in general case otherwise
>> and would always need to be executed in a loop. And the execution
>> should be brief, likely shorter than non-interruptible sections
>> of many syscalls. In this sense capping at 1000 can be a better
>> choice.
> 
> Let's just cap it at 1000, at least that's a more reasonable number. I
> don't think there's a perfect way to solve this problem, outside of
> being able to detect loops, but at least 1000 can be documented as the
> max limit. Not that anyone would ever get anywhere near that...

Fwiw, I don't think the limit is strictly required as long as the
task remains killable, even if it's a nice thing to do. It's that
kind of problem that'd rather seem to come from a malicious user
and not a honest mistake, and in case of the latter it'd be hard
to make it nondeterministic. IOW, if the user tests the code, it
should be able to easily find and fix it.

>> You was pretty convincing insisting that extra waiting on teardown is
>> not tolerable. In the same spirit there were discussions on how fast
>> you can create rings. I wouldn't care if it's one or two extra
>> syscalls, but I reasonably expect that it might grow to low double
>> digit queries at some point, and 10-15 syscalls doesn't sound that
>> comfortable while that can be easily avoided.
> 
> Those are completely different matters. The teardown slowness caused
> 100-150x slowdowns, doing 10-15 extra syscalls for setup is utter noise

Another worry is the possibility that the number of queries goes
considerably up. E.g. a query type that returns info about a
specified req opcode, and some library doing it for each opcode.

> and nobody would ever notice that, let alone complain about it. But I'm
> willing to compromise on some sane lower limit, even if I think the
> better API is just doing single queries at the time because that is the
> sanest API when we don't need to care about squeezing out the last bit
> of efficiency.

If you have a bunch of them, it might be neater from the user code
perspective as well instead of making multiple calls. I guess can
be abstracted out by a library, but struct layouts would need to
be smart.

-- 
Pavel Begunkov