1. 20 Mar, 2017 4 commits
    • 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
  2. 19 Mar, 2017 5 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
    • Mike Gabriel's avatar
      b7c389b9
    • Ulrich Sibiller's avatar
      Keystroke.c: ignore CapsLock and NumLock most of the time · 7065e0bf
      Ulrich Sibiller authored
      CapsLock and NumLock will only be taken into account for keystrokes
      that explicitly require them. This is implemented for convenience and
      fixes ArcticaProject/nx-libs#397
      7065e0bf
  3. 17 Mar, 2017 5 commits
  4. 15 Mar, 2017 3 commits
    • Keith Packard's avatar
      os: Add NotifyFd interfaces · 86110d6e
      Keith Packard authored
       Backported from X.org:
      
       commit 0c41b7af4ab0c8d22b88f201293f59524d1e7317
       Author: Keith Packard <keithp@keithp.com>
       Date:   Wed Nov 11 22:02:02 2015 -0800
      
          os: Add NotifyFd interfaces
      
          This provides a callback-based interface to monitor file
          descriptors beyond the usual client and device interfaces.
      
          Modules within the server using file descriptors for reading and/or
          writing can call
      
              Bool SetNotifyFd(int fd, NotifyFdProcPtr notify_fd, int mask, void *data);
      
          mask can be any combination of X_NOTIFY_READ and X_NOTIFY_WRITE.
      
          When 'fd' becomes readable or writable, the notify_fd function will be
          called with the 'fd', the ready conditions and 'data' values as arguments,
      
          When the module no longer needs to monitor the fd, it will call
      
              void RemoveNotifyFd(int fd);
      
          RemoveNotifyFd may be called from the notify function.
      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>
      86110d6e
    • Mike Gabriel's avatar
    • Keith Packard's avatar
      os/xdmcp: Just send XDMCP keepalive packets once every three minute · 9f000842
      Keith Packard authored
       Backported from X.org:
      
       commit db1089eafc1c5371fa0030202de588d2e2b4f8e5
       Author: Keith Packard <keithp@keithp.com>
       Date:   Mon Sep 21 07:16:17 2015 +0100
      
          os/xdmcp: Just send XDMCP keepalive packets once every three minutes
      
          There was a complicated scheme to increase the time between keepalives
          from 3 minutes up to as much as 24 hours in an attempt to reduce
          network traffic from idle X terminals. X terminals receiving X
          traffic, or receiving user input would use the 3 minute value; X
          terminals without any network traffic would use a longer value.
      
          However, this was actually broken -- any activity in the X server,
          either client requests or user input, would end up resetting the
          keepalive timeout, so a user mashing on the keyboard would never
          discover that the XDMCP master had disappeared and have the session
          terminated, which was precisely the design goal of the XDMCP keepalive
          mechanism.
      
          Instead of attempting to fix this, accept the cost of a pair of XDMCP
          packets once every three minutes and just perform keepalives
          regularly.
      
          This will also make reworking the block and wakeup handler APIs to
          eliminate select masks easier.
      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>
      9f000842
  5. 13 Mar, 2017 23 commits