Re: [PATCH v2 1/1] iomap: propagate nowait to block layer

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

On 3/4/25 19:22, Darrick J. Wong wrote:
...
>> Assuming you're suggesting to implement that, I can't say I'm excited by
>> the idea of reworking a non trivial chunk of block layer to fix a problem
>> and then porting it up to some 5.x, especially since it was already
>> attempted before by someone and ultimately got reverted.

Clarification: the mentioned work was reverted or pulled out _upstream_,
it wasn't about back porting.

> [I'm going to ignore the sarcasm downthread because I don't like it and
> will not participate in prolonging that.]
> 
> So don't.  XFS LTS generally doesn't pull large chunks of new code into

I agree, and that's why I'm trying to have a small fix. I think
this patch is concise if you disregard comments taking some
lines. And Christoph even of confirmed that the main check in the patch
does what's intended, i.e. disallowing setups where multiple bios
would be generated from the iterator.

> old kernels, we just tell people they need to keep moving forward if
> they want new code, or even bug fixes that get really involved.  You

It's still a broken io_uring uapi promise though, and I'd still need
to address it in older kernels somehow. For example we can have a
patch like this, and IMHO it'd be the ideal option.

Another option is to push all io_uring filesystem / iomap requests
to the slow path (where blocking is possible) and have a meaningful
perf regression for those who still use fs+io_uring direct IO. And
I don't put any dramaticism into it, it's essentially what users
who detect the problem already do, either that but from the user
space or disabling io_uring all together.

Even then it'd leave the question how to fix it upstream, I don't see
the full scope, but it has non trivial nuances and might likely turn
out to be a very involving project and take a lot of time I don't have
at the moment.

Darrick, any thoughts on the patch? Is there any problem why
it wouldn't work?

> want an XFS that doesn't allocate xfs_bufs from reclaim?  Well, you have
> to move to 6.12, we're not going to backport a ton of super invasive
> changes to 6.6, let alone 5.x.
> 
> We don't let old kernel source dictate changes to new kernels.

-- 
Pavel Begunkov