Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933395AbcKGSwL (ORCPT ); Mon, 7 Nov 2016 13:52:11 -0500 Received: from mail-yw0-f179.google.com ([209.85.161.179]:35147 "EHLO mail-yw0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932766AbcKGSwK (ORCPT ); Mon, 7 Nov 2016 13:52:10 -0500 MIME-Version: 1.0 In-Reply-To: References: <1477939010-111710-1-git-send-email-thgarnie@google.com> From: Thomas Garnier Date: Mon, 7 Nov 2016 10:52:08 -0800 Message-ID: Subject: Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB To: Christoph Lameter Cc: David Rientjes , Pekka Enberg , Joonsoo Kim , Andrew Morton , Linux-MM , LKML , Greg Thelen , Vladimir Davydov , Michal Hocko Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1453 Lines: 41 On Thu, Nov 3, 2016 at 1:33 PM, Christoph Lameter wrote: > On Wed, 2 Nov 2016, David Rientjes wrote: > >> > Christoph on the first version advised removing invalid flags on the >> > caller and checking they are correct in kmem_cache_create. The memcg >> > path putting the wrong flags is through create_cache but I still used >> > this approach. >> > >> >> I think this is a rather trivial point since it doesn't matter if we clear >> invalid flags on the caller or in the callee and obviously >> kmem_cache_create() does it in the callee. > > In order to be correct we need to do the following: > > kmem_cache_create should check for invalid flags (and that includes > internal alloocator flgs) being set and refuse to create the slab cache. > > memcg needs to call kmem_cache_create without any internal flags. > 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. 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? > 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. -- Thomas