On Thu, 12 Dec 2024 17:40:24 +0900 Sergey Senozhatsky senozhatsky@chromium.org wrote:
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.
Andrew, I'm leaning toward asking you to drop this patch. zram cannot (nor should probably) do anything about upper layer modifying the page data during write(). It's a bug in the upper layer which zram should not hide.
No probs, I already have a "don't do anything with this" note so I'm awaiting resolution.
I often hold onto "wrong" fixes as a reminder that a "right" fix is needed. Rather a weird bug tracking system, but it works for me ;)