linux-kernel - Re: [External] Re: [RFC PATCH 0/2] zram: objects charge to mem

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 linux-cve-announce 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]

Message-ID: <ZKvgTTqwTnUXiY3m@dhcp22.suse.cz>
Date:   Mon, 10 Jul 2023 12:41:17 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     贺中坤 <hezhongkun.hzk@...edance.com>
Cc:     minchan@...nel.org, senozhatsky@...omium.org, david@...hat.com,
        yosryahmed@...gle.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [RFC PATCH 0/2] zram: objects charge to mem_cgroup

On Mon 10-07-23 17:35:07, 贺中坤 wrote:
> On Fri, Jul 7, 2023 at 10:44 PM Michal Hocko <mhocko@...e.com> wrote:
> >
> > Why do we want/need that?
> 
> Applications can currently escape their cgroup memory containment when
> zram is enabled regardless of indirect(swapfile) or direct usage(disk) .
> This patch adds memcg accounting to fix it.
> 
> Zram and zswap have the same problem，please refer to the patch
> corresponding to zswap[1].
> 
> [1] https://lore.kernel.org/all/20220510152847.230957-7-hannes@cmpxchg.org/
> 
> >
> > > summarize the previous discussion:
> > > [1] As I can see, Michal's concern is that the charges are going to fail
> > > and swapout would fail.
> > >
> > > The indirect use of zram is in the context of PF_MEMALLOC, so
> > > the charge must be successful.
> >
> > No, this was not my concern. Please read through that more carefully. My
> > concern was that the hard limit reclaim would fail. PF_MEMALLOC will not
> > help in that case as this is not a global reclaim path.
> >
> 
> Sorry for my expression. I mean the hard limit reclaim would fail.
> As i can see, the PF_MEMALLOC is not only used in global reclaim path
> but the mem_cgroup reclaim.
> 
> try_charge_memcg
>   try_to_free_mem_cgroup_pages
>      noreclaim_flag = memalloc_noreclaim_save();
>      nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
>      memalloc_noreclaim_restore(noreclaim_flag);

My bad, I have overlooked this. I forgot about 89a2848381b5f. 

> > Also let's assume you allow swapout charges to succeed similar to
> > PF_MEMALLOC. That would mean breaching the limit in an unbounded way,
> > no?
> > --
> 
> Chage compressed page once, mean a page will be freed. the size of compressed
> page is less than or equal to the page to be freed. So not an unbounded way.

OK, this is an important detail to mention. Also have tried to get some
numbers of how much excess is happening for a mixed bag of compressible
memory?
-- 
Michal Hocko
SUSE Labs