- 21 Jul, 2021 1 commit
-
-
Huang Zhw authored
On 32 bit platform, the bit position of GETBIT/SETBIT/BITFIELD/BITCOUNT,BITPOS may overflow (see CVE-2021-32761) (#9191) GETBIT, SETBIT may access wrong address because of wrap. BITCOUNT and BITPOS may return wrapped results. BITFIELD may access the wrong address but also allocate insufficient memory and segfault (see CVE-2021-32761). This commit uses `uint64_t` or `long long` instead of `size_t`. related https://github.com/redis/redis/pull/8096 At 32bit platform: > setbit bit 4294967295 1 (integer) 0 > config set proto-max-bulk-len 536870913 OK > append bit "\xFF" (integer) 536870913 > getbit bit 4294967296 (integer) 0 When the bit index is larger than 4294967295, size_t can't hold bit index. In the past, `proto-max-bulk-len` is limit to 536870912, so there is no problem. After this commit, bit position is stored in `uint64_t` or `long long`. So when `proto-max-bulk-len > 536870912`, 32bit platforms can still be correct. For 64bit platform, this problem still exists. The major reason is bit pos 8 times of byte pos. When proto-max-bulk-len is very larger, bit pos may overflow. But at 64bit platform, we don't have so long string. So this bug may never happen. Additionally this commit add a test cost `512MB` memory which is tag as `large-memory`. Make freebsd ci and valgrind ci ignore this test. * This test is disabled in this version since bitops doesn't rely on proto-max-bulk-len. some of the overflows can still occur so we do want the fixes. (cherry picked from commit 71d45287) (cherry picked from commit 2be8f1de1d452886fbf45030409707c52323da20)
-
- 22 Feb, 2021 3 commits
-
-
Oran Agra authored
-
杨博东 authored
After fork, the child process(redis-aof-rewrite) will get the fd opened by the parent process(redis), when redis killed by kill -9, it will not graceful exit(call prepareForShutdown()), so redis-aof-rewrite thread may still alive, the fd(lock) will still be held by redis-aof-rewrite thread, and redis restart will fail to get lock, means fail to start. This issue was causing failures in the cluster tests in github actions. Co-authored-by:
Oran Agra <oran@redislabs.com> (cherry picked from commit cbaf3c5b)
-
George Prekas authored
Older arm64 Linux kernels have a bug that could lead to data corruption during background save under the following scenario: 1) jemalloc uses MADV_FREE on a page, 2) jemalloc reuses and writes the page, 3) Redis forks the background save process, and 4) Linux performs page reclamation. Under these conditions, Linux will reclaim the page wrongfully and the background save process will read zeros when it tries to read the page. The bug has been fixed in Linux with commit: ff1712f953e27f0b0718762ec17d0adb15c9fd0b ("arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect()") This Commit adds an ignore-warnings config, when not found, redis will print a warning and exit on startup (default behavior). Co-authored-by:
Oran Agra <oran@redislabs.com> (cherry picked from commit b02780c4)
-
- 27 Oct, 2020 1 commit
-
-
Oran Agra authored
Similarly to EXPIREAT with TTL in the past, which implicitly deletes the key and return success, RESTORE should not store key that are already expired into the db. When used together with REPLACE it should emit a DEL to keyspace notification and replication stream. (cherry picked from commit 5977a948) (cherry picked from commit 95ba01b5)
-
- 23 Apr, 2020 1 commit
-
-
srzhao authored
Checking OOM by `getMaxMemoryState` inside script might get different result with `freeMemoryIfNeededAndSafe` at script start, because lua stack and arguments also consume memory. This leads to memory `borderline` when memory grows near server.maxmemory: - `freeMemoryIfNeededAndSafe` at script start detects no OOM, no memory freed - `getMaxMemoryState` inside script detects OOM, script aborted We solve this 'borderline' issue by saving OOM state at script start to get stable lua OOM state. related to issue #6565 and #5250.
-
- 19 Nov, 2019 2 commits
- 14 Nov, 2019 1 commit
-
-
antirez authored
-
- 06 Nov, 2019 3 commits
-
-
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.
-
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.
-
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.
-
- 25 Sep, 2019 1 commit
-
-
antirez authored
-
- 05 Sep, 2019 1 commit
-
- 13 May, 2019 2 commits
-
-
Yossi Gottlieb authored
-
Yossi Gottlieb authored
-
- 10 May, 2019 1 commit
-
-
zhaozhao.zz authored
-
- 10 Apr, 2019 1 commit
-
-
Oran Agra authored
when redis appends the blocked client reply list to the real client, it didn't bother to check if it is in fact the master client. so a slave executing that module command will send replies to the master, causing the master to send the slave error responses, which will mess up the replication offset (slave will advance it's replication offset, and the master does not)
-
- 14 Mar, 2019 4 commits
-
-
Guy Benoish authored
In some cases processMultibulkBuffer uses sdsMakeRoomFor to expand the querybuf, but later in some cases it uses that query buffer as is for an argv element (see "Optimization"), which means that the sds in argv may have a lot of wasted space, and then in case modules keep that argv RedisString inside their data structure, this space waste will remain for long (until restarted from rdb).
-
antirez authored
Based on ideas and code in PR #5560 by @MeirShpilraien.
-
antirez authored
-
MeirShpilraien authored
-
- 12 Dec, 2018 1 commit
-
-
antirez authored
Related to issue #5686 and PR #5689.
-
- 11 Dec, 2018 2 commits
-
-
antirez authored
Thanks to @soloestoy for discovering this issue in #5667. This is an alternative fix in order to avoid both cycling the clients and also disconnecting clients just having valid read-only transactions pending.
-
Oran Agra authored
these metrics become negative when RSS is smaller than the used_memory. This can easily happen when the program allocated a lot of memory and haven't written to it yet, in which case the kernel doesn't allocate any pages to the process
-
- 17 Oct, 2018 2 commits
-
-
antirez authored
Keep vanilla stream commands at toplevel, see #5426.
-
zhaozhao.zz authored
XSTREAM CREATE <key> <id or *> -- Create a new empty stream. XSTREAM SETID <key> <id or $> -- Set the current stream ID.
-
- 15 Oct, 2018 1 commit
-
-
antirez authored
Issue #5433.
-
- 09 Oct, 2018 1 commit
-
-
antirez authored
The idea is to have an API for the cases like -BUSY state and DEBUG RELOAD where we have to manually deinstall the read handler. See #4804.
-
- 03 Oct, 2018 1 commit
-
-
antirez authored
-
- 14 Sep, 2018 2 commits
- 04 Sep, 2018 2 commits
- 29 Aug, 2018 3 commits
-
-
antirez authored
Note: this breaks backward compatibility with Redis 4, since now slaves by default are exact copies of masters and do not try to evict keys independently.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
This is an optimization for processing pipeline, we discussed a problem in issue #5229: clients may be paused if we apply `CLIENT PAUSE` command, and then querybuf may grow too large, the cost of memmove in sdsrange after parsing a completed command will be horrible. The optimization is that parsing all commands in queyrbuf , after that we can just call sdsrange only once.
-
- 02 Aug, 2018 2 commits
-
-
zhaozhao.zz authored
-
antirez authored
-
- 30 Jul, 2018 1 commit
-
-
antirez authored
-