From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752047AbcKGTwt (ORCPT ); Mon, 7 Nov 2016 14:52:49 -0500 Received: from mail-yb0-f170.google.com ([209.85.213.170]:33001 "EHLO mail-yb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751573AbcKGTwr (ORCPT ); Mon, 7 Nov 2016 14:52:47 -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 11:52:46 -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 On Mon, Nov 7, 2016 at 11:28 AM, Christoph Lameter wrote: > 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. > I assume there might be cases where the parent cache and the new memcg cache are compatible for merge (same flags and size). We can bypass that by adding SLAB_NEVER_MERGE but I am not sure what is the consequence of that. >> 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. > Great, I will send both patches. >> > 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. > Okay, I will. -- Thomas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.161.199]) by kanga.kvack.org (Postfix) with ESMTP id 14DDC6B0038 for ; Mon, 7 Nov 2016 14:52:48 -0500 (EST) Received: by mail-yw0-f199.google.com with SMTP id b66so52980420ywh.2 for ; Mon, 07 Nov 2016 11:52:48 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com. [2607:f8b0:4002:c09::234]) by mx.google.com with ESMTPS id q2si2529636ywb.270.2016.11.07.11.52.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 11:52:47 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id d59so22926902ybi.1 for ; Mon, 07 Nov 2016 11:52:46 -0800 (PST) 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 11:52:46 -0800 Message-ID: Subject: Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: David Rientjes , Pekka Enberg , Joonsoo Kim , Andrew Morton , Linux-MM , LKML , Greg Thelen , Vladimir Davydov , Michal Hocko On Mon, Nov 7, 2016 at 11:28 AM, Christoph Lameter wrote: > 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. > I assume there might be cases where the parent cache and the new memcg cache are compatible for merge (same flags and size). We can bypass that by adding SLAB_NEVER_MERGE but I am not sure what is the consequence of that. >> 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. > Great, I will send both patches. >> > 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. > Okay, I will. -- Thomas -- 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: email@kvack.org