On Thu, 12 Dec 2024 17:40:24 +0900 Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> 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 ;)
