diff options
author | Sergey Senozhatsky <senozhatsky@chromium.org> | 2025-09-09 13:48:35 +0900 |
---|---|---|
committer | Andrew Morton <akpm@linux-foundation.org> | 2025-09-15 20:01:45 -0700 |
commit | ce4be9e4307c5a60701ff6e0cafa74caffdc54ce (patch) | |
tree | 0379bbb43db4651c4e9d9de7b70725c86dc6b788 /scripts/generate_rust_target.rs | |
parent | 025e87f8ea2ae3a28bf1fe2b052bfa412c27ed4a (diff) |
zram: fix slot write race condition
Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles. Schematically we can have something like this:
CPU0 CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
compress compress
handle = zs_malloc() handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early. In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope.
Link: https://lkml.kernel.org/r/20250909045150.635345-1-senozhatsky@chromium.org
Fixes: 71268035f5d7 ("zram: free slot memory early during write")
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reported-by: Changhui Zhong <czhong@redhat.com>
Closes: https://lore.kernel.org/all/CAGVVp+UtpGoW5WEdEU7uVTtsSCjPN=ksN6EcvyypAtFDOUf30A@mail.gmail.com/
Tested-by: Changhui Zhong <czhong@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions