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:	Tue, 3 May 2016 10:18:01 +0800
From:	Ganesh Mahendran <opensource.ganesh@...il.com>
To:	Dan Streetman <ddstreet@...e.org>
Cc:	Minchan Kim <minchan@...nel.org>, Nitin Gupta <ngupta@...are.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Seth Jennings <sjenning@...hat.com>,
	Yu Zhao <yuzhao@...gle.com>, Linux-MM <linux-mm@...ck.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Dan Streetman <dan.streetman@...onical.com>
Subject: Re: [PATCH] mm/zsmalloc: don't fail if can't create debugfs info

Hello, Dan:

2016-04-28 23:36 GMT+08:00 Dan Streetman <ddstreet@...e.org>:
> Change the return type of zs_pool_stat_create() to void, and
> remove the logic to abort pool creation if the stat debugfs
> dir/file could not be created.
>
> The debugfs stat file is for debugging/information only, and doesn't
> affect operation of zsmalloc; there is no reason to abort creating
> the pool if the stat file can't be created.  This was seen with
> zswap, which used the same name for all pool creations, which caused
> zsmalloc to fail to create a second pool for zswap if
> CONFIG_ZSMALLOC_STAT was enabled.
>
> Cc: Dan Streetman <dan.streetman@...onical.com>
> Signed-off-by: Dan Streetman <ddstreet@...e.org>
> ---
>  mm/zsmalloc.c | 17 +++++++----------
>  1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index e72efb1..25a7db2 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -567,17 +567,17 @@ static const struct file_operations zs_stat_size_ops = {
>         .release        = single_release,
>  };
>
> -static int zs_pool_stat_create(const char *name, struct zs_pool *pool)
> +static void zs_pool_stat_create(const char *name, struct zs_pool *pool)
>  {
>         struct dentry *entry;
>
>         if (!zs_stat_root)
> -               return -ENODEV;
> +               return;

Since the error will not be propagated, Would it be better if you
add some pr_warn information here(also in zs_stat_init() if you
send your V2 patch as Minchan suggested)? It will be useful for
developers to know the reason of failed to create debugfs file/dir.

Thanks.

>
>         entry = debugfs_create_dir(name, zs_stat_root);
>         if (!entry) {
>                 pr_warn("debugfs dir <%s> creation failed\n", name);
> -               return -ENOMEM;
> +               return;
>         }
>         pool->stat_dentry = entry;
>
> @@ -586,10 +586,8 @@ static int zs_pool_stat_create(const char *name, struct zs_pool *pool)
>         if (!entry) {
>                 pr_warn("%s: debugfs file entry <%s> creation failed\n",
>                                 name, "classes");
> -               return -ENOMEM;
> +               return;
>         }
> -
> -       return 0;
>  }
>
>  static void zs_pool_stat_destroy(struct zs_pool *pool)
> @@ -607,9 +605,8 @@ static void __exit zs_stat_exit(void)
>  {
>  }
>
> -static inline int zs_pool_stat_create(const char *name, struct zs_pool *pool)
> +static inline void zs_pool_stat_create(const char *name, struct zs_pool *pool)
>  {
> -       return 0;
>  }
>
>  static inline void zs_pool_stat_destroy(struct zs_pool *pool)
> @@ -1956,8 +1953,8 @@ struct zs_pool *zs_create_pool(const char *name, gfp_t flags)
>
>         pool->flags = flags;
>
> -       if (zs_pool_stat_create(name, pool))
> -               goto err;
> +       /* debug only, don't abort if it fails */
> +       zs_pool_stat_create(name, pool);
>
>         /*
>          * Not critical, we still can use the pool
> --
> 2.7.4
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ