Skip to content

N
nx-libs
Switch branch/tag
  1. 27 Mar, 2017 2 commits
  3. 26 Mar, 2017 3 commits
    • Arthur Huillet's avatar
      _XDefaultError: set XlibDisplayIOError flag before calling exit · 00405b27
      Arthur Huillet authored 
      _XReply isn't reentrant, and it can lead to deadlocks when the default error
handler is called: _XDefaultError calls exit(1). It is called indirectly by
_XReply when a X protocol error comes in that isn't filtered/handled by an
extension or the application. This means that if the application (or one of its
loaded shared libraries such as the NVIDIA OpenGL driver) has registered any
_fini destructor, _fini will get called while still on the call stack of
_XReply. If the destructor interacts with the X server and calls _XReply, it
will hit a deadlock, looping on the following in _XReply:

    ConditionWait(dpy, dpy->xcb->reply_notify);

It is legal for an application to make Xlib calls during _fini, and that is
useful for an OpenGL driver to avoid resource leaks on the X server side, for
example in the dlopen/dlclose case. However, the driver can not readily tell
whether its _fini is being called because Xlib called exit, or for another
reason (dlclose), so it is hard to cleanly work around this issue in the driver.

This change makes it so _XReply effectively becomes a no-op when called after
_XDefaultError was called, as though an XIOError had happened. The dpy
connection isn't broken at that point, but any call to _XReply is going to hang.
This is a bit of a kludge, because the more correct solution would be to make
_XReply reentrant, maybe by broadcasting the reply_notify condition before
calling the default error handler. However, such a change would carry a grater
risk of introducing regressions in Xlib.

This change will drop some valid requests on the floor, but this should not
matter, as it will only do so in the case where the application is dying: X will
clean up after it once exit() is done running. There is the case of
XSetCloseDownMode(RETAIN_PERMANENT), but an application using that and wishing
to clean up resources in _fini would currently be hitting a deadlock, which is
hardly a better situation.
Signed-off-by: 's avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: 's avatarJamey Sharp <jamey@minilop.net>
      00405b27
    • Julien Cristau's avatar
      Fix wrong Xfree in XListFonts failure path · 8ad49a03
      Julien Cristau authored 
      'ch' gets moved inside the allocated buffer as we're looping through
fonts, so keep a reference to the start of the buffer so we can pass
that to Xfree in the failure case.

Fixes: commit 20a3f99eba5001925b8b313da3accb7900eb1927 "Plug a memory leak"
Signed-off-by: 's avatarJulien Cristau <jcristau@debian.org>
Reviewed-by: 's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      8ad49a03
    • Mihai Moldovan's avatar
      Merge branch 'sunweaver-pr/dix-dispatch-backports' into 3.6.x · ac03b517
      Mihai Moldovan authored 
      Attributes GH PR #412: https://github.com/ArcticaProject/nx-libs/pull/412
      ac03b517
  5. 24 Mar, 2017 3 commits
  7. 21 Mar, 2017 24 commits
  9. 20 Mar, 2017 5 commits
    • Adam Jackson's avatar
      Don't crash on unconfigured interfaces. (X.org bug #5218, Andrei Barbu) · eac0a8fa
      Adam Jackson authored 
       commit 9d62d1e6903ccc095f784279a699b3f40a8f0cf8
 Author: Adam Jackson <ajax@nwnk.net>
 Date:   Sat Jan 7 00:45:17 2006 +0000

    Bug #5218: Don't crash on unconfigured interfaces. (Andrei Barbu)
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      eac0a8fa
    • Alan Coopersmith's avatar
      Set padding bytes to 0 in WriteToClient · f9123570
      Alan Coopersmith authored 
       commit bed610fcae41ddfe21fa9acde599b17d1d15f5d1
 Author: Alan Coopersmith <alan.coopersmith@oracle.com>
 Date:   Mon Jul 9 19:12:44 2012 -0700

    Set padding bytes to 0 in WriteToClient

    Clear them out when needed instead of leaving whatever values were
    present in previously sent messages.
Signed-off-by: 's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Tested-by: 's avatarDaniel Stone <daniel@fooishbar.org>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      f9123570
    • Aaron Plattner's avatar
      os: Return BadLength instead of disconnecting BigReq clients (#4565) · 2ecd2a00
      Aaron Plattner authored 
       Backported from X.org:

 commit 67c66606c760c263d7a4c2d1bba43ed6225a4e7c
 Author: Robert Morell <rmorell@nvidia.com>
 Date:   Thu May 9 13:09:02 2013 -0700

    os: Reset input buffer's 'ignoreBytes' field

    If a client sends a request larger than maxBigRequestSize, the server is
    supposed to ignore it.

    Before commit cf88363d, the server would simply disconnect the client.  After
    that commit, it attempts to gracefully ignore the request by remembering how
    long the client specified the request to be, and ignoring that many bytes.
    However, if a client sends a BigReq header with a large size and disconnects
    before actually sending the rest of the specified request, the server will
    reuse the ConnectionInput buffer without resetting the ignoreBytes field.  This
    makes the server ignore new X clients' requests.

    This fixes that behavior by resetting the ignoreBytes field when putting the
    ConnectionInput buffer back on the FreeInputs list.
Signed-off-by: 's avatarRobert Morell <rmorell@nvidia.com>
Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>

 commit c80c41767eb101e9dbd8393d8cca7764b4e248a4
 Author: Aaron Plattner <aplattner@nvidia.com>
 Date:   Mon Oct 25 22:01:32 2010 -0700

    os: Fix BigReq ignoring when another request is pending

    Commit cf88363db0ebb42df7cc286b85d30d7898aea840 fixed the handling of
    BigReq requests that are way too large and handles the case where the
    read() syscall returns a short read.  However, it neglected to handle
    the case where it returns a long read, which happens when the client
    has another request in the queue after the bogus large one.

    Handle the long read case by subtracting the smaller of 'needed' and
    'gotnow' from oci->ignoreBytes.  If needed < gotnow, simply subtract
    the two, leaving gotnow equal to the number of extra bytes read.
    Since the code immediately following the (oci->ignoreBytes > 0) block
    tries to handle the next request, advance oci->bufptr immediately
    instead of setting oci->lenLastReq and letting the next call to
    ReadRequestFromClient do it.

    Fixes the XTS pChangeKeyboardMapping-3 test.

             CASES TESTS  PASS UNSUP UNTST NOTIU  WARN   FIP  FAIL UNRES  UNIN ABORT
    -Xproto    122   389   367     2    19     0     0     0     1     0     0     0
    +Xproto    122   389   368     2    19     0     0     0     0     0     0     0
Signed-off-by: 's avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: 's avatarAdam Jackson <ajax@redhat.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>

 commit cf88363db0ebb42df7cc286b85d30d7898aea840
 Author: Aaron Plattner <aplattner@nvidia.com>
 Date:   Fri Aug 27 10:20:29 2010 -0700

    os: Return BadLength instead of disconnecting BigReq clients (#4565)

    If a client sends a big request that's too big (i.e. bigger than
    maxBigRequestSize << 2 bytes), the server just disconnects it.  This makes the
    client receive SIGPIPE the next time it tries to send something.

    The X Test Suite sends requests that are too big when the test specifies the
    TOO_LONG test type.  When the client receives SIGPIPE, XTS marks it as
    UNRESOLVED, which counts as a failure.

    Instead, remember how long the request is supposed to be and then return that
    size.  Dispatch() checks the length and sends BadLength to the client.  Then,
    whenever oci->ignoreBytes is nonzero, ignore the data read instead of trying to
    process it as a request.
Signed-off-by: 's avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      2ecd2a00
    • Peter Harris's avatar
      Fix overflow of ConnectionOutput->size and ->count · cbc2d300
      Peter Harris authored 
       commit 4b0d0df34f10a88c10cb23dd50087b59f5c4fece
 Author: Peter Harris <pharris@opentext.com>
 Date:   Mon Nov 17 14:31:24 2014 -0500

    Fix overflow of ConnectionOutput->size and ->count

    When (long) is larger than (int), and when realloc succeeds with sizes
    larger than INT_MAX, ConnectionOutput->size and ConnectionOutput->count
    overflow and become negative.

    When ConnectionOutput->count is negative, InsertIOV does not actually
    insert an IOV, and FlushClient goes into an infinite loop of writev(fd,
    iov, 0) [an empty list].

    Avoid this situation by killing the client when it has more than INT_MAX
    unread bytes of data.
Signed-off-by: 's avatarPeter Harris <pharris@opentext.com>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      cbc2d300
    • Michel Dänzer's avatar
      dix: Pass ClientPtr to FlushCallback · 65b6a62b
      Michel Dänzer authored 
       Backported X.org commits:

 commit b380f3ac51f40ffefcde7d3db5c4c149f274246d
 Author: Michel Dänzer <michel.daenzer@amd.com>
 Date:   Tue Aug 2 17:53:01 2016 +0900

    dix: Pass ClientPtr to FlushCallback

    This change has two effects:

    1. Only calls FlushCallbacks when we're actually flushing data to a
       client. The unnecessary FlushCallback calls could cause significant
       performance degradation with compositing, which is significantly
       reduced even without any driver changes.

    2. By passing the ClientPtr to FlushCallbacks, drivers can completely
       eliminate unnecessary flushing of GPU commands by keeping track of
       whether we're flushing any XDamageNotify events to the client for
       which the corresponding rendering commands haven't been flushed to
       the GPU yet.
Reviewed-by: 's avatarAdam Jackson <ajax@redha.com>
Signed-off-by: 's avatarMichel Dänzer <michel.daenzer@amd.com>

 commit c65f610e12f9df168d5639534ed3c2bd40afffc8
 Author: Kristian Høgsberg <krh@bitplanet.net>
 Date:   Thu Jul 29 18:52:35 2010 -0400

    Always call the flush callback chain when we flush client buffers

    We were missing the callback in a couple of places.  Drivers may use
    the flush callback to submit batched up rendering before events (for
    example, damage events) are sent out, to ensure that the rendering
    has been queued when the client receives the event.
Signed-off-by: 's avatarKristian Høgsberg <krh@bitplanet.net>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      65b6a62b
  11. 19 Mar, 2017 3 commits
    • Keith Packard's avatar
      Xserver/os/io.c: Bail out early from FlushClient if nothing needs to be written. · af7c3750
      Keith Packard authored 
       Found in X.org commit:

 commit d5bf6f95f31037bd49b11348b500c3c13b7e0c99
 Author: Keith Packard <keithp@keithp.com>
 Date:   Thu Oct 4 14:42:37 2012 -0700

    Fix FlushClient to write extraBuf when provided (regression fix)

    In commit:

        commit 092c57ab173c8b71056f6feb3b9d04d063a46579
        Author: Adam Jackson <ajax@redhat.com>
        Date:   Fri Jun 17 14:03:01 2011 -0400

            os: Hide the Connection{In,Out}put implementation details
Reviewed-by: 's avatarDaniel Stone <daniel@fooishbar.org>
Signed-off-by: 's avatarAdam Jackson <ajax@redhat.com>

    the check for an empty output buffer was moved from one calling
    location into the FlushClient implementation itself. However, this
    neglected the possibility that additional data, in the form of
    'extraBuf' would be passed to FlushClient from other code paths. If the
    output buffer happened to be empty at that time, the extra data would
    never be written to the client.

    This is fixed by checking the total data to be written, which includes
    both pending and extra data, instead of just the pending data.
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
Reviewed-by: 's avatarJulien Cristau <jcristau@debian.org>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      af7c3750
    • Chris Wilson's avatar
      os: Immediately queue initial WriteToClient · 645b757d
      Chris Wilson authored 
       Backported from X.org:

 commit 9bf46610a9d20962854016032de4567974e87957
 Author: Chris Wilson <chris@chris-wilson.co.uk>
 Date:   Fri Jun 21 22:58:31 2013 +0100

    os: Immediately queue initial WriteToClient

    If we immediately put the WriteToClient() buffer into the socket's write
    queue, not only do we benefit from sending the response back to client
    earlier, but we also avoid the overhead of copying the data into our own
    staging buffer and causing extra work in the next select(). The write is
    effectively free as typically we may only send one reply per client per
    select() call, so the cost of the FlushClient() is the same.

    shmget10:   26400 -> 110000
    getimage10: 25000 -> 108000

    shmget500:   3160 -> 13500
    getimage500: 1000 -> 1010

    The knock-on effect is that on a mostly idle composited desktop, the CPU
    overhead is dominated by the memmove in WriteToClient, which is in turn
    eliminated by this patch.
Reviewed-by: 's avatarAdam Jackson <ajax@redhat.com>
Signed-off-by: 's avatarChris Wilson <chris@chris-wilson.co.uk>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      645b757d
    • Mike Gabriel's avatar
      os/xdmcp: Remove dead 'restart' code · 07464670
      Mike Gabriel authored 
       Completing the below X.org commit:

 commit a3a40291330bad10401fe2bcdbc097ce742b026a
 Author: Keith Packard <keithp@keithp.com>
 Date:   Mon Sep 21 07:16:16 2015 +0100

    os/xdmcp: Remove dead 'restart' code

    The X server used to wait for the user to hit a key or move the mouse
    before restarting the session after a keepalive failure. This,
    presumably, was to avoid having the X server continuously spew XDMCP
    protocol on the network while the XDM server was dead.

    Switching into this state was removed from the server some time before
    XFree86 4.3.99.16, so the remaining bits of code have been dead for
    over a decade, and no-one ever noticed.
Reviewed-by: 's avatarAdam Jackson <ajax@redhat.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      07464670