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@xxxxxxxxxxxxxxx # 5.19 > Cc: Minchan Kim <minchan@xxxxxxxxxx> > Cc: Nitin Gupta <ngupta@xxxxxxxxxx> > Cc: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> > Cc: Alexey Romanov <avromanov@xxxxxxxxxxxxxx> > Cc: Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxx> > Cc: Lukas Czerner <lczerner@xxxxxxxxxx> > Cc: Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx> > Signed-off-by: Jiri Slaby <jslaby@xxxxxxx> Reviewed-by: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx>
