On (24/11/29 19:04), Andrew Morton wrote: [..]
When using ext4 on zram, the following panic occasionally occurs under high memory usage
The reason is that when the handle is obtained using the slow path, it will be re-compressed. If the data in the page changes, the compressed length may exceed the previous one. Overflow occurred when writing to zs_object, which then caused the panic.
Comment the fast path and force the slow path. Adding a large number of read and write file systems can quickly reproduce it.
The solution is to re-obtain the handle after re-compression if the length is different from the previous one.
Link: https://lkml.kernel.org/r/20241129115735.136033-1-baicaiaichibaicai@gmail.co... Signed-off-by: caiqingfu caiqingfu@ruijie.com.cn Cc: Minchan Kim minchan@kernel.org Cc: Sergey Senozhatsky senozhatsky@chromium.org Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org
Reviewed-by: Sergey Senozhatsky senozhatsky@chromium.org
A side note: Well, we should not crash the kernel or corrupt memory, in this regard the patch makes sense, however, if data is being modified concurrently with zram write() then zram simply should not be used, we can't decompress data that is unstable at the time of compression.