> > In any case, zram should ensure that its data is not damaged > > zram cannot ensure that, it's not zram's job. Nothing stops > the buggy actor from modifiying the page at any random point, > zram might not even be able to decompress the page in the end, > it's not only the zs_handle allocation slow-path case. What I mean is that if the length after recompression is longer than before, writing directly to zs_obj will cause the next zs_obj to be corrupted, eventually leading to panic. zram must ensure that its own zs_obj will not be written to overflow, not page.
