linux-kernel - Re: [RFC PATCH] memcg: adjust memcg used to charge for new simple

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]

Date:   Thu, 18 Aug 2022 14:27:43 +0200
From:   Michal Koutný <mkoutny@...e.com>
To:     Vasily Averin <vvs@...nvz.org>
Cc:     Roman Gushchin <roman.gushchin@...ux.dev>, tj@...nel.org,
        gregkh@...uxfoundation.org, hannes@...xchg.org, kernel@...nvz.org,
        linux-kernel@...r.kernel.org, mhocko@...e.com, shakeelb@...gle.com,
        songmuchun@...edance.com, viro@...iv.linux.org.uk,
        Christian Brauner <brauner@...nel.org>
Subject: Re: [RFC PATCH] memcg: adjust memcg used to charge for new
 simple_xattrs objects

On Thu, Aug 18, 2022 at 12:10:45PM +0300, Vasily Averin <vvs@...nvz.org> wrote:
> sys_set[f]xattr uses simple_xattr infrastructure to create a new
> extended attribute for in-memory file systems like sysfs and tmpfs.
> Number and size of allocated objects are controlled by user space,
> they are always living in memory and its lifetime is indefinitely long.
> Therefore this memory should be properly accounted.
> 
> By default new memory is accounted to memcg of creator process.

despite objects aren't bound to this process lifetime.

(I think this was the main argument for this approach and should be in
the commit message then.)

> As a result, neighboring xattrs of the same inode can be charged to
> different memcgs. This looks unexpected and makes hard the
> investigation of the memcg accounting issues.
> 
> This patch adjust memcg used for such allocations. For kernfs
> it gives memcg from kernfs node, for shmem -- from shmem_info.
> This allows to cahrge all inode-sepcific objects to the same
> memory cgroup.

IIUC you intend to inherit association from shmem_inode_info (i.e.
whoever created the inode). shmem_inode_cachep has SLAB_ACCOUNT, so it's valid.

Thanks,
Michal