1. 27 Feb, 2018 4 commits
    • antirez's avatar
      ae.c: insetad of not firing, on AE_BARRIER invert the sequence. · 9d797fe1
      antirez authored
      AE_BARRIER was implemented like:
      
          - Fire the readable event.
          - Do not fire the writabel event if the readable fired.
      
      However this may lead to the writable event to never be called if the
      readable event is always fired. There is an alterantive, we can just
      invert the sequence of the calls in case AE_BARRIER is set. This commit
      does that.
      9d797fe1
    • antirez's avatar
      AOF: fix a bug that may prevent proper fsyncing when fsync=always. · 50571f57
      antirez authored
      In case the write handler is already installed, it could happen that we
      serve the reply of a query in the same event loop cycle we received it,
      preventing beforeSleep() from guaranteeing that we do the AOF fsync
      before sending the reply to the client.
      
      The AE_BARRIER mechanism, introduced in a previous commit, prevents this
      problem. This commit makes actual use of this new feature to fix the
      bug.
      50571f57
    • antirez's avatar
      Cluster: improve crash-recovery safety after failover auth vote. · 9176f4b9
      antirez authored
      Add AE_BARRIER to the writable event loop so that slaves requesting
      votes can't be served before we re-enter the event loop in the next
      iteration, so clusterBeforeSleep() will fsync to disk in time.
      Also add the call to explicitly fsync, given that we modified the last
      vote epoch variable.
      9176f4b9
    • antirez's avatar
      ae.c: introduce the concept of read->write barrier. · e6043981
      antirez authored
      AOF fsync=always, and certain Redis Cluster bus operations, require to
      fsync data on disk before replying with an acknowledge.
      In such case, in order to implement Group Commits, we want to be sure
      that queries that are read in a given cycle of the event loop, are never
      served to clients in the same event loop iteration. This way, by using
      the event loop "before sleep" callback, we can fsync the information
      just one time before returning into the event loop for the next cycle.
      This is much more efficient compared to calling fsync() multiple times.
      
      Unfortunately because of a bug, this was not always guaranteed: the
      actual way the events are installed was the sole thing that could
      control. Normally this problem is hard to trigger when AOF is enabled
      with fsync=always, because we try to flush the output buffers to the
      socekt directly in the beforeSleep() function of Redis. However if the
      output buffers are full, we actually install a write event, and in such
      a case, this bug could happen.
      
      This change to ae.c modifies the event loop implementation to make this
      concept explicit. Write events that are registered with:
      
          AE_WRITABLE|AE_BARRIER
      
      Are guaranteed to never fire after the readable event was fired for the
      same file descriptor. In this way we are sure that data is persisted to
      disk before the client performing the operation receives an
      acknowledged.
      
      However note that this semantics does not provide all the guarantees
      that one may believe are automatically provided. Take the example of the
      blocking list operations in Redis.
      
      With AOF and fsync=always we could have:
      
          Client A doing: BLPOP myqueue 0
          Client B doing: RPUSH myqueue a b c
      
      In this scenario, Client A will get the "a" elements immediately after
      the Client B RPUSH will be executed, even before the operation is persisted.
      However when Client B will get the acknowledge, it can be sure that
      "b,c" are already safe on disk inside the list.
      
      What to note here is that it cannot be assumed that Client A receiving
      the element is a guaranteed that the operation succeeded from the point
      of view of Client B.
      
      This is due to the fact that the barrier exists within the same socket,
      and not between different sockets. However in the case above, the
      element "a" was not going to be persisted regardless, so it is a pretty
      synthetic argument.
      e6043981
  2. 21 Nov, 2017 1 commit
  3. 08 Nov, 2017 1 commit
  4. 06 Nov, 2017 1 commit
    • antirez's avatar
      Fix saving of zero-length lists. · 0aa0cdf7
      antirez authored
      Normally in modern Redis you can't create zero-len lists, however it's
      possible to load them from old RDB files generated, for instance, using
      Redis 2.8 (see issue #4409). The "Right Thing" would be not loading such
      lists at all, but this requires to hook in rdb.c random places in a not
      great way, for a problem that is at this point, at best, minor.
      
      Here in this commit instead I just fix the fact that zero length lists,
      materialized as quicklists with the first node set to NULL, were
      iterated in the wrong way while they are saved, leading to a crash.
      
      The other parts of the list implementation are apparently able to deal
      with empty lists correctly, even if they are no longer a thing.
      0aa0cdf7
  5. 31 Oct, 2017 1 commit
    • antirez's avatar
      Fix buffer overflows occurring reading redis.conf. · 5727d7ec
      antirez authored
      There was not enough sanity checking in the code loading the slots of
      Redis Cluster from the nodes.conf file, this resulted into the
      attacker's ability to write data at random addresses in the process
      memory, by manipulating the index of the array. The bug seems
      exploitable using the following techique: the config file may be altered so
      that one of the nodes gets, as node ID (which is the first field inside the
      structure) some data that is actually executable: then by writing this
      address in selected places, this node ID part can be executed after a
      jump. So it is mostly just a matter of effort in order to exploit the
      bug. In practice however the issue is not very critical because the
      bug requires an unprivileged user to be able to modify the Redis cluster
      nodes configuration, and at the same time this should result in some
      gain. However Redis normally is unprivileged as well. Yet much better to
      have this fixed indeed.
      
      Fix #4278.
      5727d7ec
  6. 21 Sep, 2017 1 commit
  7. 18 Sep, 2017 1 commit
    • Oran Agra's avatar
      Flush append only buffers before existing. · 13e8e538
      Oran Agra authored
      when SHUTDOWN command is recived it is possible that some of the recent
      command were not yet flushed from the AOF buffer, and the server
      experiences data loss at shutdown.
      13e8e538
  8. 28 Jul, 2017 1 commit
  9. 24 Jul, 2017 8 commits
  10. 11 Jul, 2017 1 commit
  11. 30 Jun, 2017 2 commits
    • antirez's avatar
      Fix abort typo in Lua debugger help screen. · 7018d27d
      antirez authored
      7018d27d
    • antirez's avatar
      Added GEORADIUS(BYMEMBER)_RO variants for read-only operations. · d557144e
      antirez authored
      Issue #4084 shows how for a design error, GEORADIUS is a write command
      because of the STORE option. Because of this it does not work
      on readonly slaves, gets redirected to masters in Redis Cluster even
      when the connection is in READONLY mode and so forth.
      
      To break backward compatibility at this stage, with Redis 4.0 to be in
      advanced RC state, is problematic for the user base. The API can be
      fixed into the unstable branch soon if we'll decide to do so in order to
      be more consistent, and reease Redis 5.0 with this incompatibility in
      the future. This is still unclear.
      
      However, the ability to scale GEO queries in slaves easily is too
      important so this commit adds two read-only variants to the GEORADIUS
      and GEORADIUSBYMEMBER command: GEORADIUS_RO and GEORADIUSBYMEMBER_RO.
      The commands are exactly as the original commands, but they do not
      accept the STORE and STOREDIST options.
      d557144e
  12. 27 Jun, 2017 6 commits
  13. 22 Jun, 2017 4 commits
  14. 20 Jun, 2017 4 commits
  15. 14 Jun, 2017 1 commit
  16. 17 May, 2017 1 commit
  17. 15 May, 2017 1 commit
  18. 21 Apr, 2017 1 commit