On (24/12/13 13:56), caiqingfu wrote: > > > 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. The data must not change. That's the only "must" thing. zram cannot and must not tolerate buggy upper layer that do not respect BLK_FEAT_STABLE_WRITES.
