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: <CACSyD1NX7sfPu2Wi1ep0gJ-wt1O8-+++321Uhw4YK1Uz4rxj-g@mail.gmail.com>
Date:   Mon, 10 Jul 2023 17:35:07 +0800
From:   贺中坤 <hezhongkun.hzk@...edance.com>
To:     Michal Hocko <mhocko@...e.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 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);

> 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.

> Michal Hocko
> SUSE Labs