1. 17 Jan, 2023 1 commit
    • Oran Agra's avatar
      Revert change to KEYS command from (#11676) · e12aacf3
      Oran Agra authored
      in Redis 7.0 this fix covers KEYS as well, but in 6.2 and 6.0 it doesn't,
      this is because in 7.0 there's a mechanism to avoid sending partial replies
      to the client, and in older releases there isn't, and without it there's a
      risk that the client would be able to read what looks like a complete KEYS
      command.
      e12aacf3
  2. 16 Jan, 2023 1 commit
    • Oran Agra's avatar
      Obuf limit, exit during loop in *RAND* commands and KEYS · 3148f3e8
      Oran Agra authored
      Related to the hang reported in #11671
      Currently, redis can disconnect a client due to reaching output buffer limit,
      it'll also avoid feeding that output buffer with more data, but it will keep
      running the loop in the command (despite the client already being marked for
      disconnection)
      
      This PR is an attempt to mitigate the problem, specifically for commands that
      are easy to abuse, specifically: KEYS, HRANDFIELD, SRANDMEMBER, ZRANDMEMBER.
      The RAND family of commands can take a negative COUNT argument (which is not
      bound to the number of elements in the key), so it's enough to create a key
      with one field, and then these commands can be used to hang redis.
      For KEYS the caller can use the existing keyspace in redis (if big enough).
      3148f3e8
  3. 12 Dec, 2022 1 commit
  4. 01 Jun, 2021 1 commit
  5. 19 Apr, 2021 1 commit
    • sundb's avatar
      Fix ouput buffer limit test (#8803) · 3a955d9a
      sundb authored
      The tail size of c->reply is 16kb, but in the test only publish a
      few chars each time, due to a change in #8699, the obuf limit
      is now checked a new memory allocation is made, so this test
      would have sometimes failed to trigger a soft limit disconnection
      in time.
      
      The solution is to write bigger payloads to the output buffer, but
      still limit their rate (not more than 100k/s).
      3a955d9a
  6. 27 Sep, 2020 1 commit
  7. 24 Sep, 2020 1 commit
    • Wang Yuan's avatar
      Don't write replies if close the client ASAP (#7202) · 57709c4b
      Wang Yuan authored
      
      
      Before this commit, we would have continued to add replies to the reply buffer even if client
      output buffer limit is reached, so the used memory would keep increasing over the configured limit.
      What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
      because that doesn't conform to its definition and we will close all clients flagged with
      'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
      
      Because of code execution order, before this, we may firstly write to part of the replies to
      the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
      since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
      for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
      and close the connection, but before, we close the client firstly and write the reply to reply
      buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
      
      We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
      client after executing commands and send all entire replies, so that we can write replies to
      reply buffer during executing commands, send replies to clients, and close them later.
      
      We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
      all commands will be executed completely in redis and clients will not read any reply instead of
      partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
      it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
      in 'multi/exec'.
      
      We added some tests for output buffer limit breach during multi-exec and using a pipeline of
      many small commands rather than one with big response.
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      57709c4b
  8. 13 May, 2019 1 commit
    • antirez's avatar
      Fix test false positive introduced by threaded I/O. · 4f4676a1
      antirez authored
      Now clients that are ready to be terminated asynchronously are processed
      more often in beforeSleep() instead of being processed in serverCron().
      This means that the test will not be able to catch the moment the client
      was terminated, also note that the 'omem' figure now changes in big
      steps, because of the new client output buffers layout.
      
      So we have to change the test range in order to accomodate for that.
      Yet the test is useful enough to be worth taking, even if its precision
      is reduced by this commit. Probably if we get more problems, a thing
      that makes sense is just to check that the limit is < 200k. That's more
      than enough actually.
      4f4676a1
  9. 25 Mar, 2013 1 commit
  10. 22 Feb, 2012 1 commit
  11. 30 Jan, 2012 1 commit
  12. 26 Jan, 2012 1 commit
  13. 25 Jan, 2012 2 commits