From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) by kanga.kvack.org (Postfix) with ESMTP id CE5986B0038 for ; Tue, 16 Jan 2018 10:21:34 -0500 (EST) Received: by mail-it0-f71.google.com with SMTP id b11so3986142itj.0 for ; Tue, 16 Jan 2018 07:21:34 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net. [2001:558:fe21:29:69:252:207:33]) by mx.google.com with ESMTPS id u4si2374352iti.93.2018.01.16.07.21.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 07:21:33 -0800 (PST) Date: Tue, 16 Jan 2018 09:21:30 -0600 (CST) From: Christopher Lameter Subject: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting) In-Reply-To: <20180114230719.GB32027@bombadil.infradead.org> Message-ID: References: <1515531365-37423-1-git-send-email-keescook@chromium.org> <1515531365-37423-5-git-send-email-keescook@chromium.org> <20180114230719.GB32027@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Kees Cook , linux-kernel@vger.kernel.org, David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-mm@kvack.org, linux-xfs@vger.kernel.org, Linus Torvalds , Alexander Viro , Andy Lutomirski , Christoph Hellwig , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" , Paolo Bonzini , Christian Borntraeger , Christoffer Dall , Dave Kleikamp , Jan Kara , Luis de Bethencourt , Marc Zyngier , Rik van Riel , Matthew Garrett , linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, netdev@vger.kernel.org, kernel-hardening@lists.openwall.com On Sun, 14 Jan 2018, Matthew Wilcox wrote: > > Hmmm... At some point we should switch kmem_cache_create to pass a struct > > containing all the parameters. Otherwise the API will blow up with > > additional functions. > > Obviously I agree with you. I'm inclined to not let that delay Kees' > patches; we can fix the few places that use this API later. At this > point, my proposal for the ultimate form would be: Right. Thats why I said "at some point".... > > struct kmem_cache_attr { > const char name[32]; Want to avoid the string reference mess that occurred in the past? Is that really necessary? But it would limit the size of the name. > void (*ctor)(void *); > unsigned int useroffset; > unsigned int user_size; > }; > > kmem_create_cache_attr(const struct kmem_cache_attr *attr, unsigned int size, > unsigned int align, slab_flags_t flags) > > (my rationale is that everything in attr should be const, but size, align > and flags all get modified by the slab code). Thought about putting all the parameters into the kmem_cache_attr struct. So struct kmem_cache_attr { char *name; size_t size; size_t align; slab_flags_t flags; unsigned int useroffset; unsinged int usersize; void (*ctor)(void *); kmem_isolate_func *isolate; kmem_migrate_func *migrate; ... } -- 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