From: Stefan Hajnoczi <[email protected]>
To: [email protected], [email protected]
Cc: Dylan Yudaken <[email protected]>,
Dominik Thalhammer <[email protected]>,
[email protected], [email protected]
Subject: liburing 2.3 API/ABI breakage
Date: Wed, 9 Nov 2022 16:32:01 -0500 [thread overview]
Message-ID: <Y2wcUfHyS7pjlGNy@fedora> (raw)
[-- Attachment #1: Type: text/plain, Size: 4414 bytes --]
Hi,
While packaging liburing 2.3 for Fedora I came across API/ABI breakage.
By API compatibility I mean that source code that compiled against x.y
also compiles successfully against x.y+1. By ABI compatibility I mean
that executables linked against liburing.so.x continue to work when
upgrading from x.y to x.y+1.
Failure to maintain compatibility creates headaches for application
developers and distros because applications stop compiling or fail at
runtime.
Here are the liburing.h changes I'm concerned about. They were
introduced in commit c0ef135a033d ("Fix constant correctness error in
`getxattr`/`fgetxattr`") and commit 5698e179a130 ("fix len type of
fgettxattr etc"):
@@ -808,9 +989,9 @@ static inline void io_uring_prep_msg_ring(struct io_uring_sqe *sqe, int fd,
static inline void io_uring_prep_getxattr(struct io_uring_sqe *sqe,
const char *name,
- const char *value,
+ char *value,
const char *path,
- size_t len)
+ unsigned int len)
{
io_uring_prep_rw(IORING_OP_GETXATTR, sqe, 0, name, len,
(__u64) (uintptr_t) value);
@@ -823,7 +1004,7 @@ static inline void io_uring_prep_setxattr(struct io_uring_sqe *sqe,
const char *value,
const char *path,
int flags,
- size_t len)
+ unsigned int len)
{
io_uring_prep_rw(IORING_OP_SETXATTR, sqe, 0, name, len,
(__u64) (uintptr_t) value);
@@ -832,10 +1013,10 @@ static inline void io_uring_prep_setxattr(struct io_uring_sqe *sqe,
}
static inline void io_uring_prep_fgetxattr(struct io_uring_sqe *sqe,
- int fd,
+ int fd,
const char *name,
- const char *value,
- size_t len)
+ char *value,
+ unsigned int len)
{
io_uring_prep_rw(IORING_OP_FGETXATTR, sqe, fd, name, len,
(__u64) (uintptr_t) value);
@@ -843,11 +1024,11 @@ static inline void io_uring_prep_fgetxattr(struct io_uring_sqe *sqe,
}
static inline void io_uring_prep_fsetxattr(struct io_uring_sqe *sqe,
- int fd,
- const char *name,
- const char *value,
- int flags,
- size_t len)
+ int fd,
+ const char *name,
+ const char *value,
+ int flags,
+ unsigned int len)
{
io_uring_prep_rw(IORING_OP_FSETXATTR, sqe, fd, name, len,
(__u64) (uintptr_t) value);
Issues:
1. Going from const char * to char * is API breakage. This is mitigated
by the fact that applications should have passed non-const pointers
in the first place because getxattr and fgetxattr modify value.
Technically this is still API breakage because applications that
previously compiled could now encounter a compilation error.
2. Going from size_t to unsigned int is ABI breakage. This is mitigated
on CPU architectures that share 32-bit/64-bit registers (i.e. rax/eax
on x86-64 and r0/x0/w0 on aarch64). There's no guarantee this works
on all architectures, especially when the calling convention passes
arguments on the stack.
With a bit of luck today's applications won't be affected in practice;
xattrs are used relatively rarely and there are mitigating factors.
Please review for API/ABI breakage when merging code.
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2022-11-09 21:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 21:32 Stefan Hajnoczi [this message]
2022-11-10 1:58 ` liburing 2.3 API/ABI breakage Stefan Hajnoczi
2022-11-10 9:43 ` Dylan Yudaken
2022-11-10 13:46 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2wcUfHyS7pjlGNy@fedora \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox