Notices by Jens Axboe (axboe@fosstodon.org)

Leave Tridge alone. Seriously. Just mind your own business. Various people stirring up drama, with a cohort of seemingly terrible followers. Fork it and do the work yourself, if you can think you can do better. If not, STFU, and let the man cook however he wants.

@vbabka fixing his own regressions:

https://lore.kernel.org/linux-mm/202603112232.f53ebe5d-lkp@intel.com/

@osandov man those comments are a whole other level of insane. I never read phoronix comments, this confirms that is a good decision!

In today’s news: man with zero self reflection goes on lengthy one sided rant highlighting just that.

Just like I did for 6.10, I wrote up a "what's new with io_uring" but for the 6.11/12 kernels. 6.11 wasn't super exciting in terms of features, so bundled these into a single page.

https://github.com/axboe/liburing/wiki/What's-new-with-io_uring-in-6.11-12

Having worked on the kernel for decades, and imposing a lot of the same code/git hygiene for liburing, there can be a disconnect for contributors on what is expected of a commit and commit message, and what series of commits should look like. I attempted to provide a basic guideline here:

https://github.com/axboe/liburing/blob/master/CONTRIBUTING.md

and would appreciate feedback from folks on what I missed, what isn't clear, etc.

@ljs @marcan > I guess Jens point is that dancing around who it is adds to the 'fuck (other :) kernel maintainers' vibes.

Yes indeed, it hurts somewhat that a few (maybe more than a few, but definitely the minority) rotten apples ends up being a generalization against the kernel as a whole. And if I or others can help make that better, I'm surely all for it.

If you enjoy the hairiest of bug hunts with a thrilling conclusion, this one is for you. The hunt and hair pulling:

https://lore.kernel.org/regressions/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/

and the conclusion:

https://lore.kernel.org/regressions/1105090647.48374193.1700351103830.JavaMail.zimbra@raptorengineeringinc.com/

Hats off to Timothy for seeing this one through to completion!

Busy day, three patchsets posted:

xfs/iomap async dio improvements:
https://lore.kernel.org/io-uring/20230711203325.208957-1-axboe@kernel.dk/

async waitid support for io_uring:
https://lore.kernel.org/io-uring/20230711204352.214086-1-axboe@kernel.dk/

futex support (wait/wake/waitv) for io_uring:
https://lore.kernel.org/io-uring/20230712004705.316157-1-axboe@kernel.dk/

@torvalds Yep, we certainly could do that. I did that in io_uring, I'd be weary of doing it generically without auditing all the callers. Some callers assume you'll get an ITER_IOVEC out of those helpers, would make me nervous to do it wholesale inside the functions.

For liburing specifically, I'd want to add a patch that just turns io_uring_prep_{readv,writev} into read/write instead. Because the iovec copy overhead is noticeable too, and the ITER_UBUF conversion only saves iterator overhead.

@torvalds My kvm boots fine with:

diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 274014e4eafe..06e46530cb3d 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1868,7 +1868,7 @@ int import_single_range(int rw, void __user *buf, size_t len,

iov->iov_base = buf;
iov->iov_len = len;
- iov_iter_init(i, rw, iov, 1, len);
+ iov_iter_ubuf(i, rw, buf, len);
return 0;
}
EXPORT_SYMBOL(import_single_range);

Let me try the __import_iovec() as well...

One of my pet peeves - people using vectored IO operations with single segments. At least now we'll make it a bit better, though still wasting time on copying in a single iovec.

https://lore.kernel.org/io-uring/43cb1fb7-b30b-8df1-bba6-e50797d680c6@kernel.dk/