Commit b8bb300
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: 7126803 ("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>1 parent faf3863 commit b8bb300
1 file changed
+3
-5
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1795 | 1795 | | |
1796 | 1796 | | |
1797 | 1797 | | |
| 1798 | + | |
1798 | 1799 | | |
1799 | 1800 | | |
1800 | 1801 | | |
| |||
1832 | 1833 | | |
1833 | 1834 | | |
1834 | 1835 | | |
| 1836 | + | |
1835 | 1837 | | |
1836 | 1838 | | |
1837 | 1839 | | |
| |||
1855 | 1857 | | |
1856 | 1858 | | |
1857 | 1859 | | |
1858 | | - | |
1859 | | - | |
1860 | | - | |
1861 | | - | |
1862 | | - | |
1863 | 1860 | | |
1864 | 1861 | | |
1865 | 1862 | | |
| |||
1901 | 1898 | | |
1902 | 1899 | | |
1903 | 1900 | | |
| 1901 | + | |
1904 | 1902 | | |
1905 | 1903 | | |
1906 | 1904 | | |
| |||
0 commit comments