liburing 2.3 API/ABI breakage

liburing 2.3 API/ABI breakage

[Stefan Hajnoczi]

[-- 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 --]

Re: liburing 2.3 API/ABI breakage

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

> 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.

Good news, I realized that io_uring_prep_getxattr() and friends are
static inline functions. ABI breakage doesn't come into play because
they are compiled into the application.

The const char * to char * API breakage issue still remains but there's
a pretty good chance that real applications already pass in char *.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: liburing 2.3 API/ABI breakage

[Dylan Yudaken]

On Wed, 2022-11-09 at 20:58 -0500, Stefan Hajnoczi wrote:
> > 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.
> 
> Good news, I realized that io_uring_prep_getxattr() and friends are
> static inline functions. ABI breakage doesn't come into play because
> they are compiled into the application.

Additionally the inline code was doing the narrowing cast anyway, so
there was no narrowing issues.

I really should have put this explanation in the commit message though
- will remember for next time.

> 
> The const char * to char * API breakage issue still remains but
> there's
> a pretty good chance that real applications already pass in char *.

If an application was passing a const pointer, it is probably
preferrable to get a compilation error here - as this would otherwise
lead to bugs (since it is very much treated as non-const).

Re: liburing 2.3 API/ABI breakage

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Thu, Nov 10, 2022 at 09:43:48AM +0000, Dylan Yudaken wrote:
> On Wed, 2022-11-09 at 20:58 -0500, Stefan Hajnoczi wrote:
> > > 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.
> > 
> > Good news, I realized that io_uring_prep_getxattr() and friends are
> > static inline functions. ABI breakage doesn't come into play because
> > they are compiled into the application.
> 
> Additionally the inline code was doing the narrowing cast anyway, so
> there was no narrowing issues.
> 
> I really should have put this explanation in the commit message though
> - will remember for next time.

Thanks, that will help!

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]