1. 18 Nov, 2019 1 commit
  2. 15 Nov, 2019 1 commit
  3. 14 Nov, 2019 1 commit
  4. 06 Nov, 2019 1 commit
    • antirez's avatar
      Update PR #6537: use a fresh time outside call(). · 8b2c0f90
      antirez authored
      One problem with the solution proposed so far in #6537 is that key
      lookups outside a command execution via call(), still used a cached
      time. The cached time needed to be refreshed in multiple places,
      especially because of modules callbacks from timers, cluster bus, and
      thread safe contexts, that may use RM_Open().
      
      In order to avoid this problem, this commit introduces the ability to
      detect if we are inside call(): this way we can use the reference fixed
      time only when we are in the context of a command execution or Lua
      script, but for the asynchronous lookups, we can still use mstime() to
      get a fresh time reference.
      8b2c0f90
  5. 05 Nov, 2019 2 commits
    • antirez's avatar
      Update PR #6537 patch to for generality. · 824f5f0b
      antirez authored
      After the thread in #6537 and thanks to the suggestions received, this
      commit updates the original patch in order to:
      
      1. Solve the problem of updating the time in multiple places by updating
      it in call().
      2. Avoid introducing a new field but use our cached time.
      
      This required some minor refactoring to the function updating the time,
      and the introduction of a new cached time in microseconds in order to
      use less gettimeofday() calls.
      824f5f0b
    • zhaozhao.zz's avatar
      expires: refactoring judgment about whether a key is expired · e542132b
      zhaozhao.zz authored
      Calling lookupKey*() many times to search a key in one command
      may get different result.
      
      That's because lookupKey*() calls expireIfNeeded(), and delete
      the key when reach the expire time. So we can get an robj before
      the expire time, but a NULL after the expire time.
      
      The worst is that may lead to Redis crash, for example
      `RPOPLPUSH foo foo` the first time we get a list form `foo` and
      hold the pointer, but when we get `foo` again it's expired and
      deleted. Now we hold a freed memory, when execute rpoplpushHandlePush()
      redis crash.
      
      To fix it, we can refactor the judgment about whether a key is expired,
      using the same basetime `server.cmd_start_mstime` instead of calling
      mstime() everytime.
      e542132b
  6. 29 Oct, 2019 1 commit
    • Oran Agra's avatar
      Modules hooks: complete missing hooks for the initial set of hooks · 51c3ff8d
      Oran Agra authored
      * replication hooks: role change, master link status, replica online/offline
      * persistence hooks: saving, loading, loading progress
      * misc hooks: cron loop, shutdown, module loaded/unloaded
      * change the way hooks test work, and add tests for all of the above
      
      startLoading() now gets flag indicating what is loaded.
      stopLoading() now gets an indication of success or failure.
      adding startSaving() and stopSaving() with similar args and role.
      51c3ff8d
  7. 28 Oct, 2019 1 commit
    • zhaozhao.zz's avatar
      Modules: make unloading module more safe · c74398e1
      zhaozhao.zz authored
      As we know if a module exports module-side data types,
      unload it is not allowed. This rule is the same with
      blocked clients in module, because we use background
      threads to implement module blocked clients, and it's
      not safe to unload a module if there are background
      threads running. So it's necessary to check if any
      blocked clients running in this module when unload it.
      
      Moreover, after that we can ensure that if no modules,
      then no module blocked clients even module unloaded.
      So, we can call moduleHandleBlockedClients only when
      we have installed modules.
      c74398e1
  8. 24 Oct, 2019 1 commit
  9. 15 Oct, 2019 1 commit
  10. 10 Oct, 2019 1 commit
    • antirez's avatar
      Cluster: fix memory leak of cached master. · 747be463
      antirez authored
      This is what happened:
      
      1. Instance starts, is a slave in the cluster configuration, but
      actually server.masterhost is not set, so technically the instance
      is acting like a master.
      
      2. loadDataFromDisk() calls replicationCacheMasterUsingMyself() even if
      the instance is a master, in the case it is logically a slave and the
      cluster is enabled. So now we have a cached master even if the instance
      is practically configured as a master (from the POV of
      server.masterhost value and so forth).
      
      3. clusterCron() sees that the instance requires to replicate from its
      master, because logically it is a slave, so it calls
      replicationSetMaster() that will in turn call
      replicationCacheMasterUsingMyself(): before this commit, this call would
      overwrite the old cached master, creating a memory leak.
      747be463
  11. 09 Oct, 2019 1 commit
  12. 07 Oct, 2019 5 commits
    • Yossi Gottlieb's avatar
      TLS: Configuration options. · 61733ded
      Yossi Gottlieb authored
      Add configuration options for TLS protocol versions, ciphers/cipher
      suites selection, etc.
      61733ded
    • Oran Agra's avatar
      TLS: Implement support for write barrier. · 6b629480
      Oran Agra authored
      6b629480
    • Oran Agra's avatar
      diskless replication rdb transfer uses pipe, and writes to sockets form the parent process. · 5a477946
      Oran Agra authored
      misc:
      - handle SSL_has_pending by iterating though these in beforeSleep, and setting timeout of 0 to aeProcessEvents
      - fix issue with epoll signaling EPOLLHUP and EPOLLERR only to the write handlers. (needed to detect the rdb pipe was closed)
      - add key-load-delay config for testing
      - trim connShutdown which is no longer needed
      - rioFdsetWrite -> rioFdWrite - simplified since there's no longer need to write to multiple FDs
      - don't detect rdb child exited (don't call wait3) until we detect the pipe is closed
      - Cleanup bad optimization from rio.c, add another one
      5a477946
    • Yossi Gottlieb's avatar
      TLS: Connections refactoring and TLS support. · b087dd1d
      Yossi Gottlieb authored
      * Introduce a connection abstraction layer for all socket operations and
      integrate it across the code base.
      * Provide an optional TLS connections implementation based on OpenSSL.
      * Pull a newer version of hiredis with TLS support.
      * Tests, redis-cli updates for TLS support.
      b087dd1d
    • Oran Agra's avatar
      fix issues found by a static analyzer · d1a005ab
      Oran Agra authored
      cluster.c - stack buffer memory alignment
          The pointer 'buf' is cast to a more strictly aligned pointer type
      evict.c - lazyfree_lazy_eviction, lazyfree_lazy_eviction always called
      defrag.c - bug in dead code
      server.c - casting was missing parenthesis
      rax.c - indentation / newline suggested an 'else if' was intended
      d1a005ab
  13. 02 Oct, 2019 2 commits
    • Oran Agra's avatar
      RED-31295 - redis: avoid race between dlopen and thread creation · 2e19b941
      Oran Agra authored
      It seeems that since I added the creation of the jemalloc thread redis
      sometimes fails to start with the following error:
      
      Inconsistency detected by ld.so: dl-tls.c: 493: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed!
      
      This seems to be due to a race bug in ld.so, in which TLS creation on the
      thread, collide with dlopen.
      
      Move the creation of BIO and jemalloc threads to after modules are loaded.
      
      plus small bugfix when trying to disable the jemalloc thread at runtime
      2e19b941
    • antirez's avatar
      Speedup INFO server section. · 758b39be
      antirez authored
      758b39be
  14. 30 Sep, 2019 2 commits
  15. 27 Sep, 2019 3 commits
  16. 26 Sep, 2019 1 commit
  17. 25 Sep, 2019 2 commits
  18. 23 Sep, 2019 1 commit
    • Mike A. Owens's avatar
      Seed SipHash with 128-bit key · 0a4d2bbd
      Mike A. Owens authored
      SipHash expects a 128-bit key, and we were indeed generating 128-bits,
      but restricting them to hex characters 0-9a-f, effectively giving us
      only 4 bits-per-byte of key material, and 64 bits overall.
      
      Now, we skip the hex conversion and supply 128 bits of unfiltered
      random data.
      0a4d2bbd
  19. 22 Sep, 2019 1 commit
  20. 18 Sep, 2019 1 commit
  21. 02 Sep, 2019 1 commit
  22. 25 Aug, 2019 1 commit
  23. 31 Jul, 2019 1 commit
  24. 24 Jul, 2019 2 commits
  25. 23 Jul, 2019 3 commits
  26. 22 Jul, 2019 1 commit
  27. 17 Jul, 2019 1 commit
    • Oran Agra's avatar
      Module API for Forking · 56258c6b
      Oran Agra authored
      * create module API for forking child processes.
      * refactor duplicate code around creating and tracking forks by AOF and RDB.
      * child processes listen to SIGUSR1 and dies exitFromChild in order to
        eliminate a valgrind warning of unhandled signal.
      * note that BGSAVE error reply has changed.
      
      valgrind error is:
        Process terminating with default action of signal 10 (SIGUSR1)
      56258c6b