linux-kernel - [RFC PATCH RESEND v2 0/2] zram: memcg accounting

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20230804075720.207943-1-hezhongkun.hzk@bytedance.com>
Date:   Fri,  4 Aug 2023 15:57:20 +0800
From:   Zhongkun He <hezhongkun.hzk@...edance.com>
To:     minchan@...nel.org, senozhatsky@...omium.org, mhocko@...e.com
Cc:     david@...hat.com, yosryahmed@...gle.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Zhongkun He <hezhongkun.hzk@...edance.com>
Subject: [RFC PATCH RESEND v2 0/2] zram: memcg accounting

Applications can currently escape their cgroup memory
containment when zram is used. This patchset adds
per-cgroup limiting of zram compressed memory to fix it.

As we know, zram can be used in two ways, direct and
indirect, this patchset can charge memory in both cases.
Direct zram usage by process within a cgroup will fail
to charge if there is no memory. Indirect zram usage by
process within a cgroup via swap in PF_MEMALLOC context,
will charge successfully.

This allows some limit overrun, but not enough to matter
in practice.Charge 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. The numbers of excess depend on the
compression ratio only. The maximum amount will not exceed
400KB, and will be smaller than the hard limit finally,
So not an unbounded way.

Changes from V1:
- remove memalloc_noreclaim_save in zram_recompress()
- add gfp_t flag in obj_cgroup_charge_zram()

V1's link:
https://lore.kernel.org/all/20230707044613.1169103-1-hezhongkun.hzk@bytedance.com/

The first patch charged in zsmalloc, now aborted:
https://lore.kernel.org/all/20230615034830.1361853-1-hezhongkun.hzk@bytedance.com/

We charge compressed memory directly in the zram module
instead of in the zsmalloc module because zsmallc may
be used by zswap, zswap objects has been charged once
in the zswap module, so zsmallc will double charge.

Summarize the previous discussion:

[1]Michal's concern is that the hard limit reclaim would fail.

Chage compressed page once, mean a page will be freed, so
allows some limit overrun not exceed 400KB.

[2]David's concern is that if there is a page in the BIO that
is not charged,we can not charge the compressed page for the
fs->zram and whether the recompress case is charged.

As i can see, page caches are alloced by user with cgroup.
For the corner case, ZERO_PAGE will not take up space after
compression. Besides,the recompress case is charged.

Zhongkun He (2):
  memcg: Add support for zram object charge
  zram: charge the compressed RAM to the page's memcgroup

 drivers/block/zram/zram_drv.c | 45 +++++++++++++++++++++++++++++++++++
 drivers/block/zram/zram_drv.h |  1 +
 include/linux/memcontrol.h    | 12 ++++++++++
 mm/memcontrol.c               | 24 +++++++++++++++++++
 4 files changed, 82 insertions(+)

-- 
2.25.1