Received: by 10.213.65.68 with SMTP id h4csp519793imn; Tue, 13 Mar 2018 11:38:08 -0700 (PDT) X-Google-Smtp-Source: AG47ELthN7MpBWY5m/x36oSAUJT4LrA/wFPwjghUdUs71j5YxN9nguTPnshgZ+Bl0qshfwdRPu2O X-Received: by 10.99.95.84 with SMTP id t81mr1234694pgb.400.1520966288211; Tue, 13 Mar 2018 11:38:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520966288; cv=none; d=google.com; s=arc-20160816; b=WBd0uBaL15YVfR9xAUI9wT6yo8VFsHVS5nXQlWb4XQmXkLw55QqKqTpYPggldDzWgl WzPE3zaJjY1M3oUz2vGUV/ZC4VdY0ESm/T/l1TB4zghph37VOOsG4Kji5/2onTPDJCgj rXhb2KpyvlyM7w41j+LqpI02HxiPjICCsGfiIBH16MDgr+C7RWb3I+jja7B52ZybFyER v3dW/sWOq87QziiXZvxRkxirhSoCW68FXCCXJjrizuHq0PC7a0u0wyCzzar+KPMIa1LZ RjnBhkTwJe3A1+hYTxDkr6sLXUz/RUYRS1KMM6/yJymZMJjl5LzvNAHNChJ9sCiHkP1A 0Hsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=DWWMlZYO5QLmnXX+gDp56seHKi28oyjj1YBM3lD1/7M=; b=svfC0Xxbwe5Id2U8oK7SbCMSER8sxhD3E5P2me7bJ7XS5hhUyVwL0lxp+k6Jcf3G90 4qPiHO7Cb+50kYzLplOhIvv2ExtbIZsN1irs8OW2C9mKjbp56jXkRNM/wsZ2KMqmkc5/ DKhym7EOhlDd95g9m9h/esYMGB5vINEWio0tgE91+PyiClWMviAnhMQVqW/9k4jiCrGz w5ZlBI56fm8fdMLJwWFsSn14FEC7RBtVA7KPdgM5UD5FJo3dbWwLc4k3tizqqfSZNfzg QX24REmKqbnqhoXm5V3SmduGE1BjxX9bmaR+doZOB4BamS6qLUKKJSozyz60pbGWpIWH +/1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si483020pge.694.2018.03.13.11.37.53; Tue, 13 Mar 2018 11:38:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752882AbeCMSgY (ORCPT + 99 others); Tue, 13 Mar 2018 14:36:24 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:3936 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbeCMSft (ORCPT ); Tue, 13 Mar 2018 14:35:49 -0400 X-IronPort-AV: E=Sophos;i="5.47,466,1515452400"; d="scan'208";a="258186036" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 19:35:47 +0100 Date: Tue, 13 Mar 2018 19:35:44 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Matthew Wilcox cc: Kees Cook , Andrew Morton , Matthew Wilcox , Linux-MM , LKML , Kernel Hardening , cocci@systeme.lip6.fr, Himanshu Jha Subject: Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct In-Reply-To: <20180313183220.GA21538@bombadil.infradead.org> Message-ID: References: <20180214182618.14627-1-willy@infradead.org> <20180214182618.14627-3-willy@infradead.org> <20180308025812.GA9082@bombadil.infradead.org> <20180308230512.GD29073@bombadil.infradead.org> <20180313183220.GA21538@bombadil.infradead.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Mar 2018, Matthew Wilcox wrote: > On Tue, Mar 13, 2018 at 06:19:51PM +0100, Julia Lawall wrote: > > On Thu, 8 Mar 2018, Matthew Wilcox wrote: > > > On Thu, Mar 08, 2018 at 07:24:47AM +0100, Julia Lawall wrote: > > > > Thanks. So it's OK to replace kmalloc and kzalloc, even though they > > > > didn't previously consider vmalloc and even though kmalloc doesn't zero? > > > > > > We'll also need to replace the corresponding places where those structs > > > are freed with kvfree(). Can coccinelle handle that too? > > > > Is the use of vmalloc a necessary part of the design? Or could there be a > > non vmalloc versions for call sites that are already ok with that? > > We can also add kmalloc_struct() along with kmalloc_ab_c that won't fall > back to vmalloc but just return NULL. It could be safer than being sure to find all of the relevant kfrees. julia