On Tue, Aug 23, 2022 at 10:24:50AM +0100, Richard W.M. Jones wrote: > io_uring (https://en.wikipedia.org/wiki/Io_uring) is an important > kernel facility, essentially an alternate way of dispatching system > calls more efficiently. It's used in a lot of high performance > situations. Although you can talk to it directly, most users should > be using liburing, a C library. > > We haven't updated liburing for "a while", since April 2021 to > liburing 2.0. There have been several upstream versions since then, > the latest is liburing 2.2, released in June. > > In theory this version is compatible and uses symbol versions: > > $ rpm -q --provides liburing > liburing = 2.2-1.fc38 > liburing(x86-64) = 2.2-1.fc38 > liburing.so.2()(64bit) > liburing.so.2(LIBURING_2.0)(64bit) > liburing.so.2(LIBURING_2.1)(64bit) > liburing.so.2(LIBURING_2.2)(64bit) > > so in theory this is not an ABI break. In practice I'm told that the > API of liburing is not very stable. Indeed, while it is perhaps ABI comaptible, it wasn't fully API compatible, as the 2.2 changes broke QEMU builds when using -Werror due to changed data type sizes. See this upstream QEMU fix (should already be in version of QEMU in Fedora): commit 8a947c7a586e16a048894e1a0a73d154435e90ef Author: Haiyue Wang <haiyue.wang@xxxxxxxxx> Date: Tue Feb 22 00:24:01 2022 +0800 aio-posix: fix build failure io_uring 2.2 The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit": https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b130000619cff40141bb1fc3615b This leads to build failure: ../util/fdmon-io_uring.c: In function ‘add_poll_remove_sqe’: ../util/fdmon-io_uring.c:182:36: error: passing argument 2 of ‘io_uring_prep_poll_remove’ makes integer from pointer without a cast [-Werror=int-conversion] 182 | io_uring_prep_poll_remove(sqe, node); | ^~~~ | | | AioHandler * In file included from /root/io/qemu/include/block/aio.h:18, from ../util/aio-posix.h:20, from ../util/fdmon-io_uring.c:49: /usr/include/liburing.h:415:17: note: expected ‘__u64’ {aka ‘long long unsigned int’} but argument is of type ‘AioHandler *’ 415 | __u64 user_data) | ~~~~~~^~~~~~~~~ cc1: all warnings being treated as errors Use LIBURING_HAVE_DATA64 to check whether the io_uring supports 64-bit variants of the get/set userdata, to convert the paramter to the right data type. Signed-off-by: Haiyue Wang <haiyue.wang@xxxxxxxxx> Message-Id: <20220221162401.45415-1-haiyue.wang@xxxxxxxxx> Signed-off-by: Stefan Hajnoczi <stefanha@xxxxxxxxxx> > TBH I don't really know how best to test this except to just do it. > The packages that depend on liburing shouldn't have any RPM dependency > problems (I already installed the update on my Rawhide machine), but > it's possible they might break in subtle ways, which is in a way > worse. They are: I think the respective package maintainers just need to be aware of the change and do whatever testing they feel is needed. Ideally the respective upstream projects ought to already be doing CI covering this kind of scenario. I don't think its reasonable to expect the distro maintainers of liburing to do comprehensive testing of each of these consumers, given their broad scope & complexity. > - ceph > - folly > - glusterfs > - plocate > - qemu > - raft > - rocksdb > - root > - samba > > (so nothing important!) > > I have the update prepared and ready to push to Rawhide, but open to > suggestions if there is a better way to do this. At least with QEMU any usage of liburing is strictly opt-in per-VM disk configuration, and I expect the number of people who've done so is close to zero. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
