From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Martin Date: Wed, 16 Oct 2019 17:35:29 +0100 Subject: [LTP] ? FAIL: Test report for kernel 5.4.0-rc2-d6c2c23.cki (stable-next) In-Reply-To: <20191016145238.GL49619@arrakis.emea.arm.com> References: <805988176.6044584.1571038139105.JavaMail.zimbra@redhat.com> <20191014162651.GF19200@arrakis.emea.arm.com> <20191014213332.mmq7narumxtkqumt@willie-the-truck> <20191015152651.GG13874@arrakis.emea.arm.com> <20191015161453.lllrp2gfwa5evd46@willie-the-truck> <20191016042933.bemrrurjbghuiw73@willie-the-truck> <20191016144422.GZ27757@arm.com> <20191016145238.GL49619@arrakis.emea.arm.com> Message-ID: <20191016163528.GA27757@arm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it On Wed, Oct 16, 2019 at 03:52:38PM +0100, Catalin Marinas wrote: > On Wed, Oct 16, 2019 at 03:44:25PM +0100, Dave P Martin wrote: > > On Wed, Oct 16, 2019 at 05:29:33AM +0100, Will Deacon wrote: > > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > > > index b61b50bf68b1..c23c47360664 100644 > > > --- a/arch/arm64/include/asm/memory.h > > > +++ b/arch/arm64/include/asm/memory.h > > > @@ -215,12 +215,18 @@ static inline unsigned long kaslr_offset(void) > > > * up with a tagged userland pointer. Clear the tag to get a sane pointer to > > > * pass on to access_ok(), for instance. > > > */ > > > -#define untagged_addr(addr) \ > > > +#define __untagged_addr(addr) \ > > > ((__force __typeof__(addr))sign_extend64((__force u64)(addr), 55)) > > > > > > +#define untagged_addr(addr) ({ \ > > > > Having the same informal name ("untagged") for two different address > > representations seems like a recipe for confusion. Can we rename one of > > them? (Say, untagged_address_if_user()?) > > I agree it's confusing. We can rename the __* one but the other is > spread around the kernel (it can be done, though as a subsequent > exercise; untagged_uaddr?). > > > > + __addr &= __untagged_addr(__addr); \ > > > + (__force __typeof__(addr))__addr; \ > > > +}) > > > > Is there any reason why we can't just have > > > > #define untagged_addr ((__force __typeof__(addr))( \ > > (__force u64)(addr) & GENMASK_ULL(63, 56))) > > I guess you meant ~GENMASK_ULL(63,56) or GENMASK_ULL(55,0). > > This changes the overflow case for mlock() which would return -ENOMEM > instead of -EINVAL (not sure we have a test for it though). Does it > matter? It looks like SUSv7 has m{,un}local() and mprotect() aligned with one another regarding ENOMEM versus EINVAL: https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/mlock.html So whatever we do, it should probably have the same effect on both calls. There's another wrinkle that occurrs to me though. Rounding "kernel" addresses up can spuriously change ENOMEM to EINVAL -- but the fix for userspace addresses (i.e., rounding down) can likewise spuriously change EINVAL to ENOMEM. Maybe this is OK -- the SUSv7 wording doesn't seem to call out address wraparound as a special case, and therefore supposedly doesn't require EINVAL to be returned for it. The asymmetry is concerning though, and a bit ugly. Cheers ---Dave 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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 40C46FA372A for ; Wed, 16 Oct 2019 16:35:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 20A562067D for ; Wed, 16 Oct 2019 16:35:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404753AbfJPQfd (ORCPT ); Wed, 16 Oct 2019 12:35:33 -0400 Received: from foss.arm.com ([217.140.110.172]:45170 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404689AbfJPQfd (ORCPT ); Wed, 16 Oct 2019 12:35:33 -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 BE0051570; Wed, 16 Oct 2019 09:35:32 -0700 (PDT) Received: from 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 453613F68E; Wed, 16 Oct 2019 09:35:31 -0700 (PDT) Date: Wed, 16 Oct 2019 17:35:29 +0100 From: Dave Martin To: Catalin Marinas Cc: Will Deacon , Andrey Konovalov , Jan Stancek , Vincenzo Frascino , CKI Project , LTP List , Linux Stable maillist , Memory Management , Szabolcs Nagy Subject: Re: ? FAIL: Test report for kernel 5.4.0-rc2-d6c2c23.cki (stable-next) Message-ID: <20191016163528.GA27757@arm.com> References: <805988176.6044584.1571038139105.JavaMail.zimbra@redhat.com> <20191014162651.GF19200@arrakis.emea.arm.com> <20191014213332.mmq7narumxtkqumt@willie-the-truck> <20191015152651.GG13874@arrakis.emea.arm.com> <20191015161453.lllrp2gfwa5evd46@willie-the-truck> <20191016042933.bemrrurjbghuiw73@willie-the-truck> <20191016144422.GZ27757@arm.com> <20191016145238.GL49619@arrakis.emea.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191016145238.GL49619@arrakis.emea.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, Oct 16, 2019 at 03:52:38PM +0100, Catalin Marinas wrote: > On Wed, Oct 16, 2019 at 03:44:25PM +0100, Dave P Martin wrote: > > On Wed, Oct 16, 2019 at 05:29:33AM +0100, Will Deacon wrote: > > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > > > index b61b50bf68b1..c23c47360664 100644 > > > --- a/arch/arm64/include/asm/memory.h > > > +++ b/arch/arm64/include/asm/memory.h > > > @@ -215,12 +215,18 @@ static inline unsigned long kaslr_offset(void) > > > * up with a tagged userland pointer. Clear the tag to get a sane pointer to > > > * pass on to access_ok(), for instance. > > > */ > > > -#define untagged_addr(addr) \ > > > +#define __untagged_addr(addr) \ > > > ((__force __typeof__(addr))sign_extend64((__force u64)(addr), 55)) > > > > > > +#define untagged_addr(addr) ({ \ > > > > Having the same informal name ("untagged") for two different address > > representations seems like a recipe for confusion. Can we rename one of > > them? (Say, untagged_address_if_user()?) > > I agree it's confusing. We can rename the __* one but the other is > spread around the kernel (it can be done, though as a subsequent > exercise; untagged_uaddr?). > > > > + __addr &= __untagged_addr(__addr); \ > > > + (__force __typeof__(addr))__addr; \ > > > +}) > > > > Is there any reason why we can't just have > > > > #define untagged_addr ((__force __typeof__(addr))( \ > > (__force u64)(addr) & GENMASK_ULL(63, 56))) > > I guess you meant ~GENMASK_ULL(63,56) or GENMASK_ULL(55,0). > > This changes the overflow case for mlock() which would return -ENOMEM > instead of -EINVAL (not sure we have a test for it though). Does it > matter? It looks like SUSv7 has m{,un}local() and mprotect() aligned with one another regarding ENOMEM versus EINVAL: https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/mlock.html So whatever we do, it should probably have the same effect on both calls. There's another wrinkle that occurrs to me though. Rounding "kernel" addresses up can spuriously change ENOMEM to EINVAL -- but the fix for userspace addresses (i.e., rounding down) can likewise spuriously change EINVAL to ENOMEM. Maybe this is OK -- the SUSv7 wording doesn't seem to call out address wraparound as a special case, and therefore supposedly doesn't require EINVAL to be returned for it. The asymmetry is concerning though, and a bit ugly. Cheers ---Dave