linux-kernel - Re: [PATCH] fs: handle shrinker registration failure in sget

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: <20171123134629.ba5fzofrq37tmt7n@dhcp22.suse.cz>
Date:   Thu, 23 Nov 2017 14:46:29 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     jack@...e.cz, viro@...iv.linux.org.uk, david@...morbit.com,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        akpm@...ux-foundation.org
Subject: Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 22:35:34, Tetsuo Handa wrote:
> Jan Kara wrote:
> > Looks good to me now. You can add:
> > 
> > Reviewed-by: Jan Kara <jack@...e.cz>
> > 
> 
> It does not look good to me, for "goto fail" can call
> destroy_unused_super() before s->s_shrink.list is initialized.
> Also, the comment block saying "this object isn't exposed yet"
> wants to be updated?
> 
> ---
>  fs/super.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/super.c b/fs/super.c
> index 80b118c..44f0c6b 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -197,6 +197,7 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags,
>  	if (!s)
>  		return NULL;
>  
> +	INIT_LIST_HEAD(&s->s_shrink.list);
>  	INIT_LIST_HEAD(&s->s_mounts);
>  	s->s_user_ns = get_user_ns(user_ns);
>  

You are right. I will move it.

> @@ -260,9 +261,8 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags,
>  	s->s_shrink.count_objects = super_cache_count;
>  	s->s_shrink.batch = 1024;
>  	s->s_shrink.flags = SHRINKER_NUMA_AWARE | SHRINKER_MEMCG_AWARE;
> -	INIT_LIST_HEAD(&s->s_shrink.list);
> -	return s;
> -
> +	if (register_shrinker(&s->s_shrink) == 0)
> +		return s;
>  fail:
>  	destroy_unused_super(s);
>  	return NULL;

But I am not sure this is correct. So what protects shrinker invocation
while the object is not initialized yet?

-- 
Michal Hocko
SUSE Labs