linux-kernel - Re: [PATCH v3 2/2] fuse: kmemcg account fs data

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: <CAJfpegtevJHaOpeaGCTmj6WMjOt-RsfMs+oJBgNTLTOJt9Je_g@mail.gmail.com>
Date:   Tue, 17 Sep 2019 09:52:12 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Khazhismel Kumykov <khazhy@...gle.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Shakeel B <shakeelb@...gle.com>
Subject: Re: [PATCH v3 2/2] fuse: kmemcg account fs data

On Tue, Sep 17, 2019 at 1:56 AM Khazhismel Kumykov <khazhy@...gle.com> wrote:
>
> account per-file, dentry, and inode data
>
> blockdev/superblock and temporary per-request data was left alone, as
> this usually isn't accounted
>
> Signed-off-by: Khazhismel Kumykov <khazhy@...gle.com>
> Reviewed-by: Shakeel Butt <shakeelb@...gle.com>
> ---
>  fs/fuse/dir.c   | 3 ++-
>  fs/fuse/file.c  | 5 +++--
>  fs/fuse/inode.c | 3 ++-
>  3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index 58557d4817e9..d572c900bb0f 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -279,7 +279,8 @@ static int fuse_dentry_revalidate(struct dentry *entry, unsigned int flags)
>  #if BITS_PER_LONG < 64
>  static int fuse_dentry_init(struct dentry *dentry)
>  {
> -       dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry), GFP_KERNEL);
> +       dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry),
> +                                  GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE);
>
>         return dentry->d_fsdata ? 0 : -ENOMEM;
>  }
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index a2ea347c4d2c..862aff3665b5 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -63,12 +63,13 @@ struct fuse_file *fuse_file_alloc(struct fuse_conn *fc)
>  {
>         struct fuse_file *ff;
>
> -       ff = kzalloc(sizeof(struct fuse_file), GFP_KERNEL);
> +       ff = kzalloc(sizeof(struct fuse_file), GFP_KERNEL_ACCOUNT);
>         if (unlikely(!ff))
>                 return NULL;
>
>         ff->fc = fc;
> -       ff->release_args = kzalloc(sizeof(*ff->release_args), GFP_KERNEL);
> +       ff->release_args = kzalloc(sizeof(*ff->release_args),
> +                                  GFP_KERNEL_ACCOUNT);
>         if (!ff->release_args) {
>                 kfree(ff);
>                 return NULL;
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index 3d598a5bb5b5..6cb445bed89d 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -66,7 +66,8 @@ static struct file_system_type fuseblk_fs_type;
>
>  struct fuse_forget_link *fuse_alloc_forget(void)
>  {
> -       return kzalloc(sizeof(struct fuse_forget_link), GFP_KERNEL);
> +       return kzalloc(sizeof(struct fuse_forget_link),
> +                      GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE);

What does __GFP_RECLAIMBALE signify in slab allocs?

You understand that the forget_link is not reclaimable in the sense,
that it requires action (reading requests from the fuse device) from
the userspace filesystem daemon?

Thanks,
Miklos