Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3530072imm; Mon, 4 Jun 2018 05:15:27 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI0mU5UUafvQoTho1GR41rqQ9688Mv4iQBOGuNmlKRLYRLNGyv798rJvobAtG/6kRw9O2vu X-Received: by 2002:a17:902:6105:: with SMTP id t5-v6mr21536160plj.138.1528114526981; Mon, 04 Jun 2018 05:15:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528114526; cv=none; d=google.com; s=arc-20160816; b=0EoaFvgHTtMCYRl+JXbU6q8SJc3ccA1LFmWnGlNDPIJlfxBafhIl31HjXxIvaMG7G+ j4xlUfzjVXSl5FkeMvM16dAsabJWUtAg3UKNl4CEJubkVvfm19X/n0ZIsvFDSH35baoT /MhL+YkkyyL1IpN1Ci6lwJMACFUJxaPTYu27bwmbJqQ+d1wF9Mtk+PemAI4faFIEZS+I OjKp2/eBadyTD96BodkfidcFeEnYcHLWdd4KxVGdFb37O5O6/owRWwLl3k/JmtW5v2GW KEPZ/CerzriW0FNCdfcLBmDVR7Waxdt3dP/nCp8X2NMqoiuiY84WxxGWuRRIsWAUeMzU PpQw== 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:arc-authentication-results; bh=51o64Y6ZJ9yGPJ9Ebnh0SdaTNCpbamVn89B7SJY0LDM=; b=l6KrvDHV1ZBVd/yKSJvCSt3XE9ZIVklwvgwpjqP5kCyJ0G5FW8dliAwekjkYQChg0j kVocsD3XQGVB9mLuzaiUf9l5by0xTfgCMUm8klsQ7+lf/3zWHSAZ8xJh3YFfHSdBaOFs q/HdJVLRGYuCzUOGj4GEa1wksf/kH9GutNHqCi2W64hldztR2ert3+O+a8orkAiijh5E RUONE/NAw8cxQJxd62rHbJ8BxsYf6LJDpjVrlO6W9aGk6bdON7pDC3XK4MlOjalm8s/6 hioEDTGyZW5E0lERozBz7CPoHcHyojOKd/RRRJRWM7apxhiXTcnxc0iOM8Ct48Pxlgwy TwAA== 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 z12-v6si8495096plk.48.2018.06.04.05.15.12; Mon, 04 Jun 2018 05:15:26 -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 S1753016AbeFDMOX (ORCPT + 99 others); Mon, 4 Jun 2018 08:14:23 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42440 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751992AbeFDMOW (ORCPT ); Mon, 4 Jun 2018 08:14:22 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CA5AB1435; Mon, 4 Jun 2018 05:14:21 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 9C5213F25D; Mon, 4 Jun 2018 05:14:21 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 073051AE1003; Mon, 4 Jun 2018 13:14:52 +0100 (BST) Date: Mon, 4 Jun 2018 13:14:52 +0100 From: Will Deacon To: Chintan Pandya Cc: catalin.marinas@arm.com, mark.rutland@arm.com, akpm@linux-foundation.org, toshi.kani@hpe.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v12 5/5] arm64: Allow huge io mappings again Message-ID: <20180604121452.GK9482@arm.com> References: <1527856758-27169-1-git-send-email-cpandya@codeaurora.org> <1527856758-27169-6-git-send-email-cpandya@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1527856758-27169-6-git-send-email-cpandya@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 01, 2018 at 06:09:18PM +0530, Chintan Pandya wrote: > Huge mappings have had stability issues due to stale > TLB entry and memory leak issues. Since, those are > addressed in this series of patches, it is now safe > to allow huge mappings. > > Signed-off-by: Chintan Pandya > --- > arch/arm64/mm/mmu.c | 18 ++---------------- > 1 file changed, 2 insertions(+), 16 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index 6e7e16c..c65abc4 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -934,15 +934,8 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot) > { > pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT | > pgprot_val(mk_sect_prot(prot))); > - pud_t new_pud = pfn_pud(__phys_to_pfn(phys), sect_prot); > - > - /* Only allow permission changes for now */ > - if (!pgattr_change_is_safe(READ_ONCE(pud_val(*pudp)), > - pud_val(new_pud))) > - return 0; Do you actually need to remove these checks? If we're doing break-before-make properly, then the check won't fire but it would be good to keep it there so we can catch misuse of these in future. In other words, can we drop this patch? Will