All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Thomas Garnier <thgarnie@google.com>
Cc: David Rientjes <rientjes@google.com>,
	Pekka Enberg <penberg@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Thelen <gthelen@google.com>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
Date: Mon, 7 Nov 2016 13:28:09 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1611071324380.19249@east.gentwo.org> (raw)
In-Reply-To: <CAJcbSZHaN8zVf4_MdpmofNCY719YfRsRq+PjLR-a+M4QGyCnGw@mail.gmail.com>

On Mon, 7 Nov 2016, Thomas Garnier wrote:

> I am not sure that is possible. kmem_cache_create currently check for
> possible alias, I assume that it goes against what memcg tries to do.

What does aliasing have to do with this? The aliases must have the same
flags otherwise the caches would not have been merged.

> Separate the changes in two patches might make sense:
>
>  1) Fix the original bug by masking the flags passed to create_cache
>  2) Add flags check in kmem_cache_create.
>
> Does it make sense?

Sure.

> > I also want to make sure that there are no other callers that specify
> > extraneou flags while we are at it.
> I will review as many as I can but we might run into surprises (quick
> boot on defconfig didn't show anything). That's why having two
> different patches might be useful.

These surprises can be caught later ... Just make sure that the core works
fine with this. You cannot audit all drivers.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com>
To: Thomas Garnier <thgarnie@google.com>
Cc: David Rientjes <rientjes@google.com>,
	Pekka Enberg <penberg@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Thelen <gthelen@google.com>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
Date: Mon, 7 Nov 2016 13:28:09 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1611071324380.19249@east.gentwo.org> (raw)
In-Reply-To: <CAJcbSZHaN8zVf4_MdpmofNCY719YfRsRq+PjLR-a+M4QGyCnGw@mail.gmail.com>

On Mon, 7 Nov 2016, Thomas Garnier wrote:

> I am not sure that is possible. kmem_cache_create currently check for
> possible alias, I assume that it goes against what memcg tries to do.

What does aliasing have to do with this? The aliases must have the same
flags otherwise the caches would not have been merged.

> Separate the changes in two patches might make sense:
>
>  1) Fix the original bug by masking the flags passed to create_cache
>  2) Add flags check in kmem_cache_create.
>
> Does it make sense?

Sure.

> > I also want to make sure that there are no other callers that specify
> > extraneou flags while we are at it.
> I will review as many as I can but we might run into surprises (quick
> boot on defconfig didn't show anything). That's why having two
> different patches might be useful.

These surprises can be caught later ... Just make sure that the core works
fine with this. You cannot audit all drivers.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-11-07 19:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-31 18:36 [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB Thomas Garnier
2016-10-31 18:36 ` Thomas Garnier
2016-10-31 23:38 ` David Rientjes
2016-10-31 23:38   ` David Rientjes
2016-11-02 15:59   ` Thomas Garnier
2016-11-02 15:59     ` Thomas Garnier
2016-11-03  0:46     ` David Rientjes
2016-11-03  0:46       ` David Rientjes
2016-11-03 20:33       ` Christoph Lameter
2016-11-03 20:33         ` Christoph Lameter
2016-11-07 18:52         ` Thomas Garnier
2016-11-07 18:52           ` Thomas Garnier
2016-11-07 19:28           ` Christoph Lameter [this message]
2016-11-07 19:28             ` Christoph Lameter
2016-11-07 19:52             ` Thomas Garnier
2016-11-07 19:52               ` Thomas Garnier

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=alpine.DEB.2.20.1611071324380.19249@east.gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=gthelen@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=thgarnie@google.com \
    --cc=vdavydov.dev@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.