Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp718007ybh; Thu, 12 Mar 2020 09:50:11 -0700 (PDT) X-Google-Smtp-Source: ADFU+vucUEji5ds21XoOETkEHdgsOECmWQkENlMUjlgL2UGpJRrUGIH/opZcERrm9qsc9t2LS24K X-Received: by 2002:aca:be09:: with SMTP id o9mr3391205oif.177.1584031811064; Thu, 12 Mar 2020 09:50:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584031811; cv=none; d=google.com; s=arc-20160816; b=essQtIuPmlfNe629Cr8L5/EuIQrqmTzbzRvHptxqncHv43qPP4yg3mAmgbSoHg6dh9 vAVjaJARd1Y8c7jjbndOK18Lzbbnj+3iCbhendG3yCAlHVfDgmSzYgMfVMfMLzKB0hgz SzmUWq7P5pZPSSArey/zxKFJCgJBdbUDQKn+9JXpTu1SY+7wcn6i7ussxtVn6Up7fwLT koDfC9zc5oDocd1sQhKnSDHB+WRXNXdV5tbcDUnsRMYmJvRoOoa8cDOAW8lr84G4ATcJ D0du4je80d6abpJgAsBWgssvxvKkSbsNFWwzjk6kU+i4LK6exbiAqnuADnbcw/EDdkYj VF8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9QsgDbtdOreOJT0Qb/v+9XbilbFjkpyo09ghLQGL4LY=; b=KSRkV4hDRMXljpR3JMqmled7prYx5bzu0hIBwznnFPiIV3RwWQS3mFHZFbfeYBcz0y mFMkUq45K/9qRpyN/5BCWVqVsGMp8fOGlFnKYzHIEIyqAHf5eJ6VfrU6mMCTZLwWR+eT ns7y2kMU5H7LHEvwbshO86ykc6PXtBraAknO1m4Ppx6Xl0LpLwUVs8mtDyvmTmn7Sx7K Oy4Y1y4J6Kld2iV6Q7DEAfdLTI2o/iQOWqEQBvidOOQjPbfv9F6Q8AtCCaHI7Pa1/DKi DcO9P2Rgme7qP6lW3oBEOoH6UTp651jw2LtifOBSc9n6Npnv/Qff6iIi3nfbAohBoqWH 98cA== 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 v8si2798914oiv.143.2020.03.12.09.49.57; Thu, 12 Mar 2020 09:50:11 -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 S1726514AbgCLQt2 (ORCPT + 99 others); Thu, 12 Mar 2020 12:49:28 -0400 Received: from foss.arm.com ([217.140.110.172]:37976 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726423AbgCLQt2 (ORCPT ); Thu, 12 Mar 2020 12:49:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 923F930E; Thu, 12 Mar 2020 09:49:25 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 913623F6CF; Thu, 12 Mar 2020 09:49:24 -0700 (PDT) Date: Thu, 12 Mar 2020 16:49:22 +0000 From: Mark Rutland To: glider@google.com Cc: catalin.marinas@arm.com, will.deacon@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, keescook@chromium.org, akpm@linux-foundation.org Subject: Re: [PATCH] arm64: define __alloc_zeroed_user_highpage Message-ID: <20200312164922.GC21120@lakrids.cambridge.arm.com> References: <20200312155920.50067-1-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200312155920.50067-1-glider@google.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 12, 2020 at 04:59:20PM +0100, glider@google.com wrote: > When running the kernel with init_on_alloc=1, calling the default > implementation of __alloc_zeroed_user_highpage() from include/linux/highmem.h > leads to double-initialization of the allocated page (first by the page > allocator, then by clear_user_page(). > Calling alloc_page_vma() with __GFP_ZERO, similarly to e.g. x86, seems > to be enough to ensure the user page is zeroed only once. Just to check, is there a functional ussue beyond the redundant zeroing, or is this jsut a performance issue? On architectures with real highmem, does GFP_HIGHUSER prevent the allocator from zeroing the page in this case, or is the architecture prevented from allocating from highmem? This feels like something we should be able to fix in the generic implementation of __alloc_zeroed_user_highpage(), with an additional check to see if init_on_alloc is in use. Thanks, Mark. > > Signed-off-by: Alexander Potapenko > --- > arch/arm64/include/asm/page.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h > index d39ddb258a049..75d6cd23a6790 100644 > --- a/arch/arm64/include/asm/page.h > +++ b/arch/arm64/include/asm/page.h > @@ -21,6 +21,10 @@ extern void __cpu_copy_user_page(void *to, const void *from, > extern void copy_page(void *to, const void *from); > extern void clear_page(void *to); > > +#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > + alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr) > +#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE > + > #define clear_user_page(addr,vaddr,pg) __cpu_clear_user_page(addr, vaddr) > #define copy_user_page(to,from,vaddr,pg) __cpu_copy_user_page(to, from, vaddr) > > -- > 2.25.1.481.gfbce0eb801-goog >