- 07 Nov, 2018 1 commit
-
-
antirez authored
Thanks to @NicolasLM, see issue #5537.
-
- 21 Oct, 2018 1 commit
-
-
hujie authored
-
- 13 Sep, 2018 1 commit
-
-
antirez authored
-
- 11 Sep, 2018 2 commits
- 05 Sep, 2018 1 commit
-
-
antirez authored
See issue #5250 and issue #5292 for more info.
-
- 27 Aug, 2018 3 commits
- 30 Jul, 2018 1 commit
-
-
antirez authored
-
- 23 Jul, 2018 1 commit
-
-
antirez authored
This way we can remember what the user configured HZ is, but change the actual HZ dynamically if needed in the dynamic HZ feature implementation.
-
- 13 Jul, 2018 1 commit
-
-
WuYunlong authored
-
- 02 Jul, 2018 1 commit
-
-
antirez authored
-
- 27 Jun, 2018 1 commit
-
-
Oran Agra authored
-
- 13 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 12 Jun, 2018 1 commit
-
-
Shen Longxing authored
The active-defrag-threshold-lower/active-defrag-threshold-upper min/max value in redis.conf should be consistent with 'config set' command.
-
- 09 Jun, 2018 2 commits
-
-
Itamar Haber authored
-
shenlongxing authored
-
- 07 Jun, 2018 2 commits
-
-
Itamar Haber authored
-
antirez authored
-
- 24 May, 2018 1 commit
-
-
antirez authored
They failed when active defrag could not be activated because the Jemalloc version does not include the additional APIs.
-
- 15 Mar, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 14 Mar, 2018 1 commit
-
-
antirez authored
This commit, in some parts derived from PR #3041 which is no longer possible to merge (because the user deleted the original branch), implements the ability of slaves to have a special configuration preventing that they try to start a failover when the master is failing. There are multiple reasons for wanting this, and the feautre was requested in issue #3021 time ago. The differences between this patch and the original PR are the following: 1. The flag is saved/loaded on the nodes configuration. 2. The 'myself' node is now flag-aware, the flag is updated as needed when the configuration is changed via CONFIG SET. 3. The flag name uses NOFAILOVER instead of NO_FAILOVER to be consistent with existing NOADDR. 4. The redis.conf documentation was rewritten. Thanks to @deep011 for the original patch.
-
- 12 Mar, 2018 1 commit
-
-
Oran Agra authored
- big keys are not defragged in one go from within the dict scan instead they are scanned in parts after the main dict hash bucket is done. - add latency monitor sample for defrag - change default active-defrag-cycle-min to induce lower latency - make active defrag start a new scan right away if needed, so it's easier (for the test suite) to detect when it's done - make active defrag quick the current cycle after each db / big key - defrag some non key long term global allocations - some refactoring for smaller functions and more reusable code - during dict rehashing, one scan iteration of the dict, can end up scanning one bucket in the smaller dict and many many buckets in the larger dict. so waiting for 16 scan iterations before checking the time, may be much too long.
-
- 26 Jan, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 11 Jan, 2018 2 commits
- 29 Dec, 2017 1 commit
-
-
Oran Agra authored
-
- 06 Dec, 2017 1 commit
-
-
antirez authored
The main change introduced by this commit is pretending that help arrays are more text than code, thus indenting them at level 0. This improves readability, and is an old practice when defining arrays of C strings describing text. Additionally a few useless return statements are removed, and the HELP subcommand capitalized when printed to the user.
-
- 03 Dec, 2017 1 commit
-
-
Itamar Haber authored
-
- 27 Nov, 2017 1 commit
-
-
zhaozhao.zz authored
-
- 15 Jul, 2017 1 commit
-
-
WuYunlong authored
-
- 20 Feb, 2017 1 commit
-
-
antirez authored
This change attempts to switch to an hash function which mitigates the effects of the HashDoS attack (denial of service attack trying to force data structures to worst case behavior) while at the same time providing Redis with an hash function that does not expect the input data to be word aligned, a condition no longer true now that sds.c strings have a varialbe length header. Note that it is possible sometimes that even using an hash function for which collisions cannot be generated without knowing the seed, special implementation details or the exposure of the seed in an indirect way (for example the ability to add elements to a Set and check the return in which Redis returns them with SMEMBERS) may make the attacker's life simpler in the process of trying to guess the correct seed, however the next step would be to switch to a log(N) data structure when too many items in a single bucket are detected: this seems like an overkill in the case of Redis. SPEED REGRESION TESTS: In order to verify that switching from MurmurHash to SipHash had no impact on speed, a set of benchmarks involving fast insertion of 5 million of keys were performed. The result shows Redis with SipHash in high pipelining conditions to be about 4% slower compared to using the previous hash function. However this could partially be related to the fact that the current implementation does not attempt to hash whole words at a time but reads single bytes, in order to have an output which is endian-netural and at the same time working on systems where unaligned memory accesses are a problem. Further X86 specific optimizations should be tested, the function may easily get at the same level of MurMurHash2 if a few optimizations are performed.
-
- 11 Jan, 2017 1 commit
-
-
antirez authored
-
- 30 Dec, 2016 1 commit
-
-
oranagra authored
-
- 19 Dec, 2016 1 commit
-
-
antirez authored
You can still force the logo in the normal logs. For motivations, check issue #3112. For me the reason is that actually the logo is nice to have in interactive sessions, but inside the logs kinda loses its usefulness, but for the ability of users to recognize restarts easily: for this reason the new startup sequence shows a one liner ASCII "wave" so that there is still a bit of visual clue. Startup logging was modified in order to log events in more obvious ways, and to log more events. Also certain important informations are now more easy to parse/grep since they are printed in field=value style. The option --always-show-logo in redis.conf was added, defaulting to no.
-
- 16 Dec, 2016 2 commits
-
-
antirez authored
The new algorithm provides the same speed with a smaller error for cardinalities in the range 0-100k. Before switching, the new and old algorithm behavior was studied in details in the context of issue #3677. You can find a few graphs and motivations there.
-
Harish Murthy authored
Config option to use LogLog-Beta Algorithm for Cardinality
-
- 26 Sep, 2016 1 commit
-
-
antirez authored
This commit fixes a vunlerability reported by Cory Duplantis of Cisco Talos, see TALOS-2016-0206 for reference. CONFIG SET client-output-buffer-limit accepts as client class "master" which is actually only used to implement CLIENT KILL. The "master" class has ID 3. What happens is that the global structure: server.client_obuf_limits[class] Is accessed with class = 3. However it is a 3 elements array, so writing the 4th element means to write up to 24 bytes of memory *after* the end of the array, since the structure is defined as: typedef struct clientBufferLimitsConfig { unsigned long long hard_limit_bytes; unsigned long long soft_limit_bytes; time_t soft_limit_seconds; } clientBufferLimitsConfig; EVALUATION OF IMPACT: Checking what's past the boundaries of the array in the global 'server' structure, we find AOF state fields: clientBufferLimitsConfig client_obuf_limits[CLIENT_TYPE_OBUF_COUNT]; /* AOF persistence */ int aof_state; /* AOF_(ON|OFF|WAIT_REWRITE) */ int aof_fsync; /* Kind of fsync() policy */ char *aof_filename; /* Name of the AOF file */ int aof_no_fsync_on_rewrite; /* Don't fsync if a rewrite is in prog. */ int aof_rewrite_perc; /* Rewrite AOF if % growth is > M and... */ off_t aof_rewrite_min_size; /* the AOF file is at least N bytes. */ off_t aof_rewrite_base_size; /* AOF size on latest startup or rewrite. */ off_t aof_current_size; /* AOF current size. */ Writing to most of these fields should be harmless and only cause problems in Redis persistence that should not escalate to security problems. However unfortunately writing to "aof_filename" could be potentially a security issue depending on the access pattern. Searching for "aof.filename" accesses in the source code returns many different usages of the field, including using it as input for open(), logging to the Redis log file or syslog, and calling the rename() syscall. It looks possible that attacks could lead at least to informations disclosure of the state and data inside Redis. However note that the attacker must already have access to the server. But, worse than that, it looks possible that being able to change the AOF filename can be used to mount more powerful attacks: like overwriting random files with AOF data (easily a potential security issue as demostrated here: http://antirez.com/news/96), or even more subtle attacks where the AOF filename is changed to a path were a malicious AOF file is loaded in order to exploit other potential issues when the AOF parser is fed with untrusted input (no known issue known currently). The fix checks the places where the 'master' class is specifiedf in order to access configuration data structures, and return an error in this cases. WHO IS AT RISK? The "master" client class was introduced in Redis in Jul 28 2015. Every Redis instance released past this date is not vulnerable while all the releases after this date are. Notably: Redis 3.0.x is NOT vunlerable. Redis 3.2.x IS vulnerable. Redis unstable is vulnerable. In order for the instance to be at risk, at least one of the following conditions must be true: 1. The attacker can access Redis remotely and is able to send the CONFIG SET command (often banned in managed Redis instances). 2. The attacker is able to control the "redis.conf" file and can wait or trigger a server restart. The problem was fixed 26th September 2016 in all the releases affected.
-
- 09 Aug, 2016 1 commit
-
-
antirez authored
-