summaryrefslogtreecommitdiff
path: root/scripts/generate_rust_target.rs
diff options
context:
space:
mode:
authorSergey Senozhatsky <senozhatsky@chromium.org>2025-09-09 13:48:35 +0900
committerAndrew Morton <akpm@linux-foundation.org>2025-09-15 20:01:45 -0700
commitce4be9e4307c5a60701ff6e0cafa74caffdc54ce (patch)
tree0379bbb43db4651c4e9d9de7b70725c86dc6b788 /scripts/generate_rust_target.rs
parent025e87f8ea2ae3a28bf1fe2b052bfa412c27ed4a (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