linux-kernel - Re: [PATCH v1 2/3] fuse: use GFP_KERNEL_ACCOUNT for allocations in fuse_dev

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEivzxc4=p63Wgp_i+J7YVw=LrKTt_HfC5fAL=vGT9AXjUgqaw@mail.gmail.com>
Date: Thu, 18 Jul 2024 12:00:39 +0200
From: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: mszeredi@...hat.com, Amir Goldstein <amir73il@...il.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Christian Brauner <brauner@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Shakeel Butt <shakeel.butt@...ux.dev>
Subject: Re: [PATCH v1 2/3] fuse: use GFP_KERNEL_ACCOUNT for allocations in fuse_dev_alloc

On Mon, Feb 26, 2024 at 12:01 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Fri, 5 Jan 2024 at 16:21, Alexander Mikhalitsyn
> <aleksandr.mikhalitsyn@...onical.com> wrote:
> >
> > fuse_dev_alloc() is called from the process context and it makes
> > sense to properly account allocated memory to the kmemcg as these
> > allocations are for long living objects.

Hi Miklos,

Sorry, this thread just got lost in my inbox. I was revisiting and
rebasing fuse idmapped mounts support series and found this again.

>
> Are the rules about when to use __GFP_ACCOUNT and when not documented somewhere?

The only doc I found is this (memory-allocation.rst):
>Untrusted allocations triggered from userspace should be a subject
>of kmem accounting and must have ``__GFP_ACCOUNT`` bit set.

>
> I notice that most filesystem objects are allocated with
> __GFP_ACCOUNT, but struct super_block isn't.  Is there a reason for
> that?

I guess that it just wasn't yet covered with memcg accounting. I can
send a patch to account struct super_block too.

These days, it's pretty safe to use __GFP_ACCOUNT almost anywhere,
because even if memcg is not
determined in a current caller context then memcg charge will be
skipped (look into __memcg_slab_post_alloc_hook() function).

Let's ask what our friends who take care of mmcontrol.c think about this.
+CC Johannes Weiner <hannes@...xchg.org>
+CC Michal Hocko <mhocko@...nel.org>
+CC Roman Gushchin <roman.gushchin@...ux.dev>
+CC Shakeel Butt <shakeel.butt@...ux.dev>

I have also added Christian because he might be interested in
accounting for struct super_block.

Kind regards,
Alex

>
> Thanks,
> Miklos