Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Michael Tokarev

08.11.2022 17:50, Michael Tokarev wrote:

08.11.2022 17:11, Guillem Jover wrote:
[..]

If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.


Well. I already deleted my test chroot. I can't say for 100% now that it
breaks the other way around. I'll have to double-check.  It took me quite
quite some time especially due to other urgent things I'm doing today.
I can check if 2.2-compiled samba works with 2.3-uring but a bit later
today.  Even if it works, it is not exactly conclusive, since samba only
uses certain code paths.  But ofc if it doesn't work, it *is* conclusive :)


Ok, I double-verified this: samba compiled against older liburing works
with liburing 2.3 after upgrading liburing2 package.  So it must be just
me being too tired when debugging all this.  So it appears to be backwards-
compatible (non-conclusive! ;)), just needs new lib for newly compiled
programs.

It's a rare case really, because of the rather heavy usage of inline
functions for access, - so parts of the library are actually compiled
into the program, and now you've more pieces to keep in sync.

It's an interesting case really.

Thank you!

/mjt



Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Michael Tokarev

08.11.2022 16:44, Guillem Jover wrote:

Hi!

On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:

On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:

Source: liburing
Version: 2.3-1
Severity: grave

liburing 2.3 broke binary compatibility without bumping the soname.


Indeed. :/ Should make a habit of checking the header diffs, as this
is not the first time this has happened.


Actually this is interesting. Maybe it would be better for me to just
wait till new liburing migrates to testing, and re-run samba autopkgtests,
instead of filing this bugreport...  (Provided it works the other way
around, which I'm not sure about yet).

/mjt



Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Michael Tokarev

08.11.2022 17:11, Guillem Jover wrote:
[..]

If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.


Well. I already deleted my test chroot. I can't say for 100% now that it
breaks the other way around. I'll have to double-check.  It took me quite
quite some time especially due to other urgent things I'm doing today.
I can check if 2.2-compiled samba works with 2.3-uring but a bit later
today.  Even if it works, it is not exactly conclusive, since samba only
uses certain code paths.  But ofc if it doesn't work, it *is* conclusive :)

Thanks,

/mjt



Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Guillem Jover
Hi!

I've forwarded this upstream now.

On Tue, 2022-11-08 at 14:44:25 +0100, Guillem Jover wrote:
> On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
> > On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:
> > > In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
> > > their sizes. Both of these structures are parts of io_uring structure
> > > which the main part of the API.  Here's the difference:
> > > 
> > > @@ -43,7 +79,9 @@
> > > @@ -56,13 +94,18 @@
> > > size_t ring_sz;
> > > void *ring_ptr;
> > > -   unsigned pad[4];
> > > +   unsigned ring_mask;
> > > +   unsigned ring_entries;
> > > +
> > > +   unsigned pad[2];
> > 
> > This does not look like it is changing the size actually, - I haven't
> > noticed it adjusts pad[] accordingly. So this is not the issue here.
> > 
> > But the end result is the same: samba compiled with liburing 2.2 does
> > not work with runtime liburing 2.3, and samba compiled with liburing
> > 2.3 does not work with runtime liburing 2.2.

I've checked the code and this is weird, the new code is taking care of
initializing all members with the new shared library. So I'd expect
samba built against the old liburing to work with the new one. But the
problem seems to be that code built against the new liburing will not
work with the old liburing, as that one does not initialize the new
members being used from the inline functions.

If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.

Thanks,
Guillem



Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Guillem Jover
Hi!

On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
> On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:
> > Source: liburing
> > Version: 2.3-1
> > Severity: grave
> > 
> > liburing 2.3 broke binary compatibility without bumping the soname.

Indeed. :/ Should make a habit of checking the header diffs, as this
is not the first time this has happened.

> > In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
> > their sizes. Both of these structures are parts of io_uring structure
> > which the main part of the API.  Here's the difference:
> > 
> > @@ -43,7 +79,9 @@
> > @@ -56,13 +94,18 @@
> > size_t ring_sz;
> > void *ring_ptr;
> > -   unsigned pad[4];
> > +   unsigned ring_mask;
> > +   unsigned ring_entries;
> > +
> > +   unsigned pad[2];
> 
> This does not look like it is changing the size actually, - I haven't
> noticed it adjusts pad[] accordingly. So this is not the issue here.
> 
> But the end result is the same: samba compiled with liburing 2.2 does
> not work with runtime liburing 2.3, and samba compiled with liburing
> 2.3 does not work with runtime liburing 2.2.
> 
> I'm just too tired now to dig further.

The problem is that this release has deprecated the kring_mask and
kring_entries, and does not have fallback code to use them if they are
being used by the callers.

I'll report this upstream to see how they want to fix this, either
with a SOVERSION bump or trying to add dynamic fallback code or
similar.

For sid, I guess I could bump the affected functions required minimal
versions in the symbols file, and then add breaks on the old packages
using the old ABI, but meh. :/

Thanks,
Guillem



Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Michael Tokarev

On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:

Source: liburing
Version: 2.3-1
Severity: grave

liburing 2.3 broke binary compatibility without bumping the soname.

In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
their sizes. Both of these structures are parts of io_uring structure
which the main part of the API.  Here's the difference:

@@ -43,7 +79,9 @@
@@ -56,13 +94,18 @@
size_t ring_sz;
void *ring_ptr;
 
-   unsigned pad[4];

+   unsigned ring_mask;
+   unsigned ring_entries;
+
+   unsigned pad[2];


This does not look like it is changing the size actually, - I haven't
noticed it adjusts pad[] accordingly. So this is not the issue here.

But the end result is the same: samba compiled with liburing 2.2 does
not work with runtime liburing 2.3, and samba compiled with liburing
2.3 does not work with runtime liburing 2.2.

I'm just too tired now to dig further.

/mjt



Bug#1023654: liburing 2.3 breaks binary compatibility

2022-11-08 Thread Michael Tokarev
Source: liburing
Version: 2.3-1
Severity: grave

liburing 2.3 broke binary compatibility without bumping the soname.

In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
their sizes. Both of these structures are parts of io_uring structure
which the main part of the API.  Here's the difference:

@@ -43,7 +79,9 @@
 struct io_uring_sq {
unsigned *khead;
unsigned *ktail;
+   // Deprecated: use `ring_mask` instead of `*kring_mask`
unsigned *kring_mask;
+   // Deprecated: use `ring_entries` instead of `*kring_entries`
unsigned *kring_entries;
unsigned *kflags;
unsigned *kdropped;
@@ -56,13 +94,18 @@
size_t ring_sz;
void *ring_ptr;
 
-   unsigned pad[4];
+   unsigned ring_mask;
+   unsigned ring_entries;
+
+   unsigned pad[2];
 };

...
struct io_uring {
  struct io_uring_sq sq;
  struct io_uring_cq cq;
  ...
}

So, a program which uses struct io_uring compiled with version 2.2 of the
library is completely incompatible when run with version 2.3 of the library,
and vise versa - since many user-visible members of this structure, even when
manipulated by the inline functions offered by uring.h, are completely
incompatible.

This breaks other software.  For example, samba compiled against liburing 2.3
will silently break when liburing 2.2 is used at the run time, and there's no
way for apt/dpkg to tell that liburing2.so upgrade is needed.  The same way,
samba compiled against liburing 2.2 breaks when liburing is upgraded to 2.3,
but in a different way.