From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92656C63777 for ; Fri, 20 Nov 2020 18:01:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1FD1522D0A for ; Fri, 20 Nov 2020 18:01:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FD1522D0A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 51ECB6B0072; Fri, 20 Nov 2020 13:01:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CC966B0073; Fri, 20 Nov 2020 13:01:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36D1F6B0074; Fri, 20 Nov 2020 13:01:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0280E6B0072 for ; Fri, 20 Nov 2020 13:01:26 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A29982479 for ; Fri, 20 Nov 2020 18:01:26 +0000 (UTC) X-FDA: 77505563772.04.road74_29046f22734d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 75E66800843F for ; Fri, 20 Nov 2020 18:01:26 +0000 (UTC) X-HE-Tag: road74_29046f22734d X-Filterd-Recvd-Size: 4457 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 18:01:25 +0000 (UTC) Received: from gaia (unknown [2.26.170.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E163F2240B; Fri, 20 Nov 2020 18:01:22 +0000 (UTC) Date: Fri, 20 Nov 2020 18:01:20 +0000 From: Catalin Marinas To: Khalid Aziz Cc: jannh@google.com, hch@infradead.org, davem@davemloft.net, akpm@linux-foundation.org, anthony.yznaga@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org Subject: Re: [PATCH] sparc64: Use arch_validate_flags() to validate ADI flag Message-ID: <20201120180119.GM24344@gaia> References: <20201023175611.12819-1-khalid.aziz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201023175611.12819-1-khalid.aziz@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Khalid, On Fri, Oct 23, 2020 at 11:56:11AM -0600, Khalid Aziz wrote: > diff --git a/arch/sparc/include/asm/mman.h b/arch/sparc/include/asm/mman.h > index f94532f25db1..274217e7ed70 100644 > --- a/arch/sparc/include/asm/mman.h > +++ b/arch/sparc/include/asm/mman.h > @@ -57,35 +57,39 @@ static inline int sparc_validate_prot(unsigned long prot, unsigned long addr) > { > if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_ADI)) > return 0; > - if (prot & PROT_ADI) { > - if (!adi_capable()) > - return 0; > + return 1; > +} We kept the equivalent of !adi_capable() check in the arm64 arch_validate_prot() and left arch_validate_flags() more relaxed. I.e. you can pass PROT_MTE to mmap() even if the hardware doesn't support MTE. This is in line with the pre-MTE ABI where unknown mmap() flags would be ignored while mprotect() would reject them. This discrepancy isn't nice but we decided to preserve the pre-MTE mmap ABI behaviour. Anyway, it's up to you if you want to change the sparc behaviour, I don't think it matters in practice. I think with this patch, arch_validate_prot() no longer needs the 'addr' argument. Maybe you can submit an additional patch to remove them (not urgent, the compiler should get rid of them). > > - if (addr) { > - struct vm_area_struct *vma; > +#define arch_validate_flags(vm_flags) arch_validate_flags(vm_flags) > +/* arch_validate_flags() - Ensure combination of flags is valid for a > + * VMA. > + */ > +static inline bool arch_validate_flags(unsigned long vm_flags) > +{ > + /* If ADI is being enabled on this VMA, check for ADI > + * capability on the platform and ensure VMA is suitable > + * for ADI > + */ > + if (vm_flags & VM_SPARC_ADI) { > + if (!adi_capable()) > + return false; > > - vma = find_vma(current->mm, addr); > - if (vma) { > - /* ADI can not be enabled on PFN > - * mapped pages > - */ > - if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) > - return 0; > + /* ADI can not be enabled on PFN mapped pages */ > + if (vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) > + return false; > > - /* Mergeable pages can become unmergeable > - * if ADI is enabled on them even if they > - * have identical data on them. This can be > - * because ADI enabled pages with identical > - * data may still not have identical ADI > - * tags on them. Disallow ADI on mergeable > - * pages. > - */ > - if (vma->vm_flags & VM_MERGEABLE) > - return 0; > - } > - } > + /* Mergeable pages can become unmergeable > + * if ADI is enabled on them even if they > + * have identical data on them. This can be > + * because ADI enabled pages with identical > + * data may still not have identical ADI > + * tags on them. Disallow ADI on mergeable > + * pages. > + */ > + if (vm_flags & VM_MERGEABLE) > + return false; Ah, you added a check to the madvise(MADV_MERGEABLE) path to ignore the flag if VM_SPARC_ADI. On arm64 we intercept memcmp_pages() but we have a PG_arch_2 flag to mark a page as containing tags. Either way should work. FWIW, if you are happy with the mmap() rejecting PROT_ADI on !adi_capable() hardware: Reviewed-by: Catalin Marinas