[PATCH libX11] fix for Xlib 32-bit request number issues

Olivier Fourdan ofourdan at redhat.com
Mon Apr 13 23:58:22 PDT 2015


Hi all,

Anyone got a chance to look further into this? (this is an old bug with several unsuccessful attempted fixes)

Chris, what do you think of the wrap test for the sequence that must remain in 32bits?

Cheers,
Olivier

----- Original Message -----
From: "Olivier Fourdan" <ofourdan at redhat.com>
To: "Christian Linhart" <chris at demorecorder.com>, xorg-devel at lists.x.org
Sent: Tuesday, March 31, 2015 2:22:11 PM
Subject: Re: [PATCH libX11] fix for Xlib 32-bit request number issues

Hi Christian,

On 27/03/15 15:50, Olivier Fourdan wrote:
> On 21/03/15 15:32, Christian Linhart wrote:
> [...]
>
> I am not a libX11 maintainer, so it's not really a review or anything,
> it's just some comments :-)

So I looked further into your patch (took me some time!) and came to the 
following ideas:

1. The changes in Xlib.h are not needed as we already have LONG64 
defined for the same purpose and already used in different place in libX11.

2. As a result, the changes in Xlibint.h would rely on LONG64 being 
defined (or not) instead of X_UNSIGNED_LONG_IS_32BIT

3. For the _XAsyncErrorState's "min_sequence_number" and 
"max_sequence_number", if we cannot change those to be 64bit, then we 
ought to use a different technique as assigning these 64bit values will 
make no difference.

Thankfully, these are used in comparison, so we can check for a wrap 
using something like that for the 32bit version:

#define  SEQUENCE_CMP(a,op,b) \
     (((a op b) && (b - a op (UINT32_MAX >> 1))) || \
      ((b op a) && ((UINT32_MAX >> 1) op a - b)))

Which (if my maths are correct) is supposed to compare "a" and "b" 
within a 32bit floating window, which is more than enough, as I would 
not expect the 32bit wrapping to occur more than once between a request 
and its async reply.

That macro is defined and used in XlibAsync.c

4. For the code that uses the standard _XAsyncErrorState struct, there 
is no need to use 64bit extended sequence number so the macro above 
would work without changing the code - The list of sources is this case 
is Fonts.c, ReconfWM.c and obviously XlibAsync.c

5. For others that use their own struct, these can use 64bit sequence 
number and therefore benefit from your change, that's GetWAttrs.c and 
IntAtom.c

6. There are some unnecessary changes in your patch that seem unrelate 
to the issue being addressed, like for example renaming "sent" as 
"xcb_sent" in require_socket() from src/xcb_io.c or splitting the for() 
loop in 4 lines in _XSend() from src/xcb_io.c - These are cosmetic 
changes and, if really needed, should be part of a separate patch IMHO.

7. These changes will rely on xcb exposing the 64bit sequence number, ie 
an API addition in libxcb, so you will need to update the libxcb 
required version in configure.ac:

X11_REQUIRES='xproto >= 7.0.17 xextproto xtrans xcb >= 1.1.92'
X11_EXTRA_DEPS="xcb >= 1.1.92"

But obviously that needs to be done once the patches in libxcb are 
merged, so this is left out for now.

tl;dr:

I am attaching a "git diff" against current git master's head so you can 
see what I mean (code is usually easier than a lengthy explanation) - I 
leave it to you to decide and send a new patch with "git am" if you 
think it's correct (or at least moving in the right direction) - I don't 
want to step on your toes here, just trying to help :-)

Cheers,
Olivier



_______________________________________________
xorg-devel at lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


More information about the xorg-devel mailing list