From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.web.de (mout.web.de [217.72.192.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yHD3k3Nx4zDrG0 for ; Thu, 19 Oct 2017 00:50:56 +1100 (AEDT) Subject: Re: Adjusting further size determinations? To: Julia Lawall , "linux-integrity@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Cc: David Laight , Joe Perches , Jason Gunthorpe , "kernel-janitors@vger.kernel.org" , Stefan Berger , Alexander Steffen , Nayna Jain , Jerry Snitselaar , "linux-kernel@vger.kernel.org" , Jarkko Sakkinen , James Bottomley , Corentin Labbe , Kenneth Goldman , Paul Mackerras , =?UTF-8?Q?Peter_H=c3=bcwe?= , Andy Shevchenko , Dan Carpenter References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <20171016183139.otyh3m5c5yurtmow@linux.intel.com> <20171016183512.3bz6x4b6lbhpbkje@linux.intel.com> <20171017085124.pkrjzghcf5wmcydc@mwanda> <1508255833.3129.33.camel@HansenPartnership.com> <1508280210.6530.32.camel@perches.com> <1508318326.6806.1.camel@perches.com> <026d582729b849b780fbaa06fb8bc79e@infineon.com> <1508322510.6806.3.camel@perches.com> <1508327383.6806.7.camel@perches.com> <0fc1f522-8772-d859-a9b0-cb3b6931c862@users.sourceforge.net> <063D6719AE5E284EB5DD2968C1650D6DD009ACE3@AcuExch.aculab.com> From: SF Markus Elfring Message-ID: Date: Wed, 18 Oct 2017 15:50:04 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >> If you want 'security' for kmalloc() then: >> >> #define KMALLOC_TYPE(flags) (type *)kmalloc(sizeof (type), flags) >> #define KMALLOC(ptr, flags) *(ptr) = KMALLOC_TYPE(typeof *(ptr), flags) Such an approach might help. >> and change: >> ptr = kmalloc(sizeof *ptr, flags); >> to: >> KMALLOC(&ptr, flags); >> >> But it is all churn for churn's sake. > > Please don't. Interesting … > Coccinelle won't find real problems with kmalloc any more if this is done. The corresponding source code analysis will become different (or more challenging) then. Are you still looking for related solutions? Regards, Markus