On (22/08/10 09:06), Jiri Slaby wrote:
This reverts commit e7be8d1dd983156bbdd22c0319b71119a8fbb697 as it causes zram failures. It does not revert cleanly, PTR_ERR handling was introduced in the meantime. This is handled by appropriate IS_ERR.
When under memory pressure, zs_malloc() can fail. Before the above commit, the allocation was retried with direct reclaim enabled (GFP_NOIO). After the commit, it is not -- only __GFP_KSWAPD_RECLAIM is tried.
So when the failure occurs under memory pressure, the overlaying filesystem such as ext2 (mounted by ext4 module in this case) can emit failures, making the (file)system unusable: EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to inode 16386 starting block 159744) Buffer I/O error on device zram0, logical block 159744
With direct reclaim, memory is really reclaimed and allocation succeeds, eventually. In the worst case, the oom killer is invoked, which is proper outcome if user sets up zram too large (in comparison to available RAM).
This very diff doesn't apply to 5.19 (stable) cleanly (see PTR_ERR note above). Use revert of e7be8d1dd983 directly.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1202203 Fixes: e7be8d1dd983 ("zram: remove double compression logic") Cc: stable@vger.kernel.org # 5.19 Cc: Minchan Kim minchan@kernel.org Cc: Nitin Gupta ngupta@vflare.org Cc: Sergey Senozhatsky senozhatsky@chromium.org Cc: Alexey Romanov avromanov@sberdevices.ru Cc: Dmitry Rokosov ddrokosov@sberdevices.ru Cc: Lukas Czerner lczerner@redhat.com Cc: Ext4 Developers List linux-ext4@vger.kernel.org Signed-off-by: Jiri Slaby jslaby@suse.cz
Reviewed-by: Sergey Senozhatsky senozhatsky@chromium.org