public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: slab: clean up kmem_cache_create_memcg() error handling
Date: Sat, 25 Jan 2014 01:14:35 +0400	[thread overview]
Message-ID: <52E2D7BB.7080801@parallels.com> (raw)
In-Reply-To: <20140124182048.GA31147@redhat.com>

On 01/24/2014 10:20 PM, Dave Jones wrote:
> On Fri, Jan 24, 2014 at 03:33:41AM +0000, Linux Kernel wrote:
>  > Gitweb:     http://git.kernel.org/linus/;a=commit;h=3965fc3652244651006ebb31c8c45318ce84818f
>  > Commit:     3965fc3652244651006ebb31c8c45318ce84818f
>  > Parent:     309381feaee564281c3d9e90fbca8963bb7428ad
>  > Author:     Vladimir Davydov <vdavydov@parallels.com>
>  > AuthorDate: Thu Jan 23 15:52:55 2014 -0800
>  > Committer:  Linus Torvalds <torvalds@linux-foundation.org>
>  > CommitDate: Thu Jan 23 16:36:50 2014 -0800
>  > 
>  >     slab: clean up kmem_cache_create_memcg() error handling
>  >     
>  >     Currently kmem_cache_create_memcg() backoffs on failure inside
>  >     conditionals, without using gotos.  This results in the rollback code
>  >     duplication, which makes the function look cumbersome even though on
>  >     error we should only free the allocated cache.  Since in the next patch
>  >     I am going to add yet another rollback function call on error path
>  >     there, let's employ labels instead of conditionals for undoing any
>  >     changes on failure to keep things clean.
>
> ...
>
>  > +out_unlock:
>  >  	mutex_unlock(&slab_mutex);
>  >  	put_online_cpus();
>  >  
>  >  	if (err) {
>  > -
>  >  		if (flags & SLAB_PANIC)
>  >  			panic("kmem_cache_create: Failed to create slab '%s'. Error %d\n",
>  >  				name, err);
>  > @@ -236,11 +230,14 @@ out_locked:
>  >  				name, err);
>  >  			dump_stack();
>  >  		}
>  > -
>  >  		return NULL;
>  >  	}
>  > -
>  >  	return s;
>  > +
>  > +out_free_cache:
>  > +	kfree(s->name);
>  > +	kmem_cache_free(kmem_cache, s);
>  > +	goto out_unlock;
>  >  }
>
> This is now returning a freed pointer as 's' if an error occurs.

If we go to out_free_cache, we set err, and since under out_unlock we have:

> if (err) {
...
>     return NULL
>}

we will return NULL, which is right.

However this behavior was broken by another my 'fix' :-(

commit    f717eb3abb5ea38f60e671dbfdbf512c2c93d22e
slab: do not panic if we fail to create memcg cache
> -    if (err) {
> +    /*
> +     * There is no point in flooding logs with warnings or especially
> +     * crashing the system if we fail to create a cache for a memcg. In
> +     * this case we will be accounting the memcg allocation to the root
> +     * cgroup until we succeed to create its own cache, but it isn't that
> +     * critical.
> +     */
> +    if (err && !memcg) {
>          if (flags & SLAB_PANIC)
>              panic("kmem_cache_create: Failed to create slab '%s'.
> Error %d\n",
>                  name, err);

In case memcg != NULL we can return crap on error. So you are right in
the end. Thank you for catching this!

> Perhaps the patch below ?
>
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 8e40321da091..2c62294cee23 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -257,6 +257,7 @@ out_free_cache:
>  	memcg_free_cache_params(s);
>  	kfree(s->name);
>  	kmem_cache_free(kmem_cache, s);
> +	s = NULL;
>  	goto out_unlock;
>  }

This one looks correct to me. I'll send it on behalf of you.

Thanks!

      reply	other threads:[~2014-01-24 21:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140124033341.3FD106611CC@gitolite.kernel.org>
2014-01-24 18:20 ` slab: clean up kmem_cache_create_memcg() error handling Dave Jones
2014-01-24 21:14   ` Vladimir Davydov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52E2D7BB.7080801@parallels.com \
    --to=vdavydov@parallels.com \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox