linux-ext4 - Re: ext2/zram issue [was: Linux 5.19]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Aug 2022 10:20:10 +0000
From:   Dmitry Rokosov <DDRokosov@...rdevices.ru>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
CC:     Jiri Slaby <jirislaby@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "ngupta@...are.org" <ngupta@...are.org>, Jan Kara <jack@...e.com>,
        Ted Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        "Ext4 Developers List" <linux-ext4@...r.kernel.org>,
        Aleksey Romanov <AVRomanov@...rdevices.ru>
Subject: Re: ext2/zram issue [was: Linux 5.19]

Hello Sergey,

On Tue, Aug 09, 2022 at 06:20:04PM +0900, Sergey Senozhatsky wrote:
> On (22/08/09 18:11), Sergey Senozhatsky wrote:
> > > > > /me needs to confirm.
> > > > 
> > > > With that commit reverted, I see no more I/O errors, only oom-killer
> > > > messages (which is OK IMO, provided I write 1G of urandom on a machine w/
> > > > 800M of RAM):
> > > 
> > > Hmm... So handle allocation always succeeds in the slow path? (when we
> > > try to allocate it second time)
> > 
> > Yeah I can see how handle re-allocation with direct reclaim can make it more
> > successful, but in exchange it oom-kills some user-space process, I suppose.
> > Is oom-kill really a good alternative though?
> 
> We likely will need to revert e7be8d1dd983 given that it has some
> user visible changes. But, honestly, failing zram write vs oom-kill
> a user-space is a tough choice.

I think oom-kill is an inevitable escape from low memory situation if we
don't solve original problem with high memory consumption in the user
setup. Reclaim-based zram slow path just delays oom if memory eating
root cause is not resolved.

I totally agree with you that all patches which have visible user
degradations should be reverted, but maybe this is more user setup
problem, what do you think?

If you make the decision to revert slow path removal patch, I would
prefer to review the original patch with unneeded code removal again
if you don't mind:
https://lore.kernel.org/linux-block/20220422115959.3313-1-avromanov@sberdevices.ru/

-- 
Thank you,
Dmitry