Notices by Jens Axboe (axboe@fosstodon.org)

@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/