1. 16 Apr, 2014 30 commits
  2. 25 Mar, 2014 9 commits
    • antirez's avatar
      Fix off by one bug in freeMemoryIfNeeded() eviction pool. · 046e691a
      antirez authored
      Bug found by the continuous integration test running the Redis
      with valgrind:
      
      ==6245== Invalid read of size 8
      ==6245==    at 0x4C2DEEF: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:876)
      ==6245==    by 0x41F9E6: freeMemoryIfNeeded (redis.c:3010)
      ==6245==    by 0x41D2CC: processCommand (redis.c:2069)
      
      memmove() size argument was accounting for an extra element, going
      outside the bounds of the array.
      046e691a
    • antirez's avatar
    • antirez's avatar
      adjustOpenFilesLimit() refactoring. · c69c40a4
      antirez authored
      In this commit:
      * Decrement steps are semantically differentiated from the reserved FDs.
        Previously both values were 32 but the meaning was different.
      * Make it clear that we save setrlimit errno.
      * Don't explicitly handle wrapping of 'f', but prevent it from
        happening.
      * Add comments to make the function flow more readable.
      
      This integrates PR #1630
      c69c40a4
    • Matt Stancliff's avatar
      Fix potentially incorrect errno usage · b2a02cc9
      Matt Stancliff authored
      errno may be reset by the previous call to redisLog, so capture
      the original value for proper error reporting.
      b2a02cc9
    • Matt Stancliff's avatar
      Add REDIS_MIN_RESERVED_FDS define for open fds · 01fe750c
      Matt Stancliff authored
      Also update the original REDIS_EVENTLOOP_FDSET_INCR to
      include REDIS_MIN_RESERVED_FDS. REDIS_EVENTLOOP_FDSET_INCR
      exists to make sure more than (maxclients+RESERVED) entries
      are allocated, but we can only guarantee that if we include
      the current value of REDIS_MIN_RESERVED_FDS as a minimum
      for the INCR size.
      01fe750c
    • Matt Stancliff's avatar
      Fix infinite loop on startup if ulimit too low · 1e7b9980
      Matt Stancliff authored
      Fun fact: rlim_t is an unsigned long long on all platforms.
      
      Continually subtracting from a rlim_t makes it get smaller
      and smaller until it wraps, then you're up to 2^64-1.
      
      This was causing an infinite loop on Redis startup if
      your ulimit was extremely (almost comically) low.
      
      The case of (f > oldlimit) would never be met in a case like:
      
          f = 150
          while (f > 20) f -= 128
      
      Since f is unsigned, it can't go negative and would
      take on values of:
      
          Iteration 1: 150 - 128 => 22
          Iteration 2:  22 - 128 => 18446744073709551510
          Iterations 3-∞: ...
      
      To catch the wraparound, we use the previous value of f
      stored in limit.rlimit_cur.  If we subtract from f and
      get a larger number than the value it had previously,
      we print an error and exit since we don't have enough
      file descriptors to help the user at this point.
      
      Thanks to @bs3g for the inspiration to fix this problem.
      Patches existed from @bs3g at antirez#1227, but I needed to repair a few other
      parts of Redis simultaneously, so I didn't get a chance to use them.
      1e7b9980
    • Matt Stancliff's avatar
      Improve error handling around setting ulimits · f701a347
      Matt Stancliff authored
      The log messages about open file limits have always
      been slightly opaque and confusing.  Here's an attempt to
      fix their wording, detail, and meaning.  Users will have a
      better understanding of how to fix very common problems
      with these reworded messages.
      
      Also, we handle a new error case when maxclients becomes less
      than one, essentially rendering the server unusable.  We
      now exit on startup instead of leaving the user with a server
      unable to handle any connections.
      
      This fixes antirez#356 as well.
      f701a347
    • Matt Stancliff's avatar
      Replace magic 32 with REDIS_EVENTLOOP_FDSET_INCR · 6f4be459
      Matt Stancliff authored
      32 was the additional number of file descriptors Redis
      would reserve when managing a too-low ulimit.  The
      number 32 was in too many places statically, so now
      we use a macro instead that looks more appropriate.
      
      When Redis sets up the server event loop, it uses:
          server.maxclients+REDIS_EVENTLOOP_FDSET_INCR
      
      So, when reserving file descriptors, it makes sense to
      reserve at least REDIS_EVENTLOOP_FDSET_INCR FDs instead
      of only 32.  Currently, REDIS_EVENTLOOP_FDSET_INCR is
      set to 128 in redis.h.
      
      Also, I replaced the static 128 in the while f < old loop
      with REDIS_EVENTLOOP_FDSET_INCR as well, which results
      in no change since it was already 128.
      
      Impact: Users now need at least maxclients+128 as
      their open file limit instead of maxclients+32 to obtain
      actual "maxclients" number of clients.  Redis will carve
      the extra REDIS_EVENTLOOP_FDSET_INCR file descriptors it
      needs out of the "maxclients" range instead of failing
      to start (unless the local ulimit -n is too low to accomidate
      the request).
      6f4be459
    • Matt Stancliff's avatar
      Fix maxclients error handling · 49b576cb
      Matt Stancliff authored
      Everywhere in the Redis code base, maxclients is treated
      as an int with (int)maxclients or `maxclients = atoi(source)`,
      so let's make maxclients an int.
      
      This fixes a bug where someone could specify a negative maxclients
      on startup and it would work (as well as set maxclients very high)
      because:
      
          unsigned int maxclients;
          char *update = "-300";
          maxclients = atoi(update);
          if (maxclients < 1) goto fail;
      
      But, (maxclients < 1) can only catch the case when maxclients
      is exactly 0.  maxclients happily sets itself to -300, which isn't
      -300, but rather 4294966996, which isn't < 1, so... everything
      "worked."
      
      maxclients config parsing checks for the case of < 1, but maxclients
      CONFIG SET parsing was checking for case of < 0 (allowing
      maxclients to be set to 0).  CONFIG SET parsing is now updated to
      match config parsing of < 1.
      
      It's tempting to add a MINIMUM_CLIENTS define, but... I didn't.
      
      These changes were inspired by antirez#356, but this doesn't
      fix that issue.
      49b576cb
  3. 24 Mar, 2014 1 commit