Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp8007662ybn; Tue, 1 Oct 2019 01:30:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqyMwY+FSIBSW0PrQM0AQBlGkxEQ5iynjFkgE7AZero6ji6p613vXIAJKnliWDpGoDcVlY8M X-Received: by 2002:a17:906:4b15:: with SMTP id y21mr16170701eju.112.1569918646910; Tue, 01 Oct 2019 01:30:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569918646; cv=none; d=google.com; s=arc-20160816; b=05/DrBQSPW2LdcLYpNGICUmufjXSabyxGujJveRnopi8EmdDvhJpPrW8itBQxDDEdv P+tbGdLXynOoreanxWeHzFIwfLg+NKaBNoAOS2UT+RGihXAK/RyJlyGdxpisfXiVQ6ad /EPPDM5LQczjlXkbX5rtw51IQH+hcuIK3sfVtRTe03UD/tXGDgxYSFqxmAFncBZGx9bD 0950N7RfCiNo/cbpWdNPeawk+0t6r78ptl29drR1gexeZ4F5rvK/YGmS9a5+2joghR4o bIlDe/t4SMx4EShHw8zFy0pMC9UV4sz1G4AGiK5IOGY9VGy4oBBYAwP53px46f5IUZ2L Vsmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=NTKx0xB9QLkRSTJJgxF9CkFFxM/Hw6/XWymFcoefPgo=; b=IDforgS15FLvRSoIIs82O0if9O/CXCUQSZJgk+XptCjK4faqqPOL1//o3TH4g3uRMP /eHtUzrWv3s/CaVXsRyrRPebmtGEDmLgpcQQY0LlSPMixm9+72IHAO83FhTn6JZrthc0 TtIyv1O7BAY2j7QN10vxfN6vXhWyV+rvjEePTlH6F0WKLG/D0XKRpGER53G/1rI+sd6Z jeYSxkEooGnYq1mcTY7KNX90xaJ9q8C81eNbmzfbFnlQ9SA+GaXsLX0oPs5YvPB6fKDq ++BD9LA0hLHXc9WvvAdnDIUFXJxp0pJVOHhgkz0uKOGbd/OZDzVwuz1veSzlwtxMpzTb VtHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=xHIO6PTo; 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 e1si8464493ede.268.2019.10.01.01.30.21; Tue, 01 Oct 2019 01:30:46 -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; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=xHIO6PTo; 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 S1733007AbfJAI1T (ORCPT + 99 others); Tue, 1 Oct 2019 04:27:19 -0400 Received: from conssluserg-01.nifty.com ([210.131.2.80]:59334 "EHLO conssluserg-01.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726148AbfJAI1T (ORCPT ); Tue, 1 Oct 2019 04:27:19 -0400 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) (authenticated) by conssluserg-01.nifty.com with ESMTP id x918REXh004109 for ; Tue, 1 Oct 2019 17:27:15 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com x918REXh004109 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1569918435; bh=NTKx0xB9QLkRSTJJgxF9CkFFxM/Hw6/XWymFcoefPgo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=xHIO6PToKh8HStqdGTKKiwVU5/yWuKLzrG5Vjt7XN4dEueUCPLVedcPtxhjqBD0Wa 0afoxJyKitPb06woYCQugANA6BTIt4VU2yZOEaZKy5wjOgGfu3oaEGJQIU9ESnWGV8 Wa3QqWCzPDb0qe/CRPIacggdClsRXponVJD7HNsveec65KSk5uTHdlHyjeUDqCfILI eiJwsME65DxsyVboxd1/w94iMYr2h1QyDQhz/AGfYxWWr1aDjBFstCAJ2JU9/IKWB0 h1BFXLOO6uTq3riXaqrXo33tlwDK+7+KvJZH1YO2/wYwTQXfcd3JMpue5PMIHuM3Cj gxycpTjXDEV5g== X-Nifty-SrcIP: [209.85.221.178] Received: by mail-vk1-f178.google.com with SMTP id w3so3303991vkm.3 for ; Tue, 01 Oct 2019 01:27:15 -0700 (PDT) X-Gm-Message-State: APjAAAXcFXZPmO6HUszrotYbVoYH8l/nn6RJEgPSMHikzACN3ojTDg2s jx3hLqiz5s4y90rytFxaN6KV7DbrDeHFHZyQioY= X-Received: by 2002:a1f:2343:: with SMTP id j64mr6852228vkj.84.1569918433967; Tue, 01 Oct 2019 01:27:13 -0700 (PDT) MIME-Version: 1.0 References: <20190930055925.25842-1-yamada.masahiro@socionext.com> <20190930175009.GH25745@shell.armlinux.org.uk> In-Reply-To: <20190930175009.GH25745@shell.armlinux.org.uk> From: Masahiro Yamada Date: Tue, 1 Oct 2019 17:26:37 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] ARM: fix __get_user_check() in case uaccess_* calls are not inlined To: Russell King - ARM Linux admin Cc: Arnd Bergmann , Vincent Whitchurch , Nick Desaulniers , Linux Kernel Mailing List , Stefan Agner , Nicolas Saenz Julienne , Julien Thierry , Olof Johansson , Thomas Gleixner , Linus Torvalds , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Russell, On Tue, Oct 1, 2019 at 2:50 AM Russell King - ARM Linux admin wrote: > > On Mon, Sep 30, 2019 at 02:59:25PM +0900, Masahiro Yamada wrote: > > KernelCI reports that bcm2835_defconfig is no longer booting since > > commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING > > forcibly"): > > > > https://lkml.org/lkml/2019/9/26/825 > > > > I also received a regression report from Nicolas Saenz Julienne: > > > > https://lkml.org/lkml/2019/9/27/263 > > > > This problem has cropped up on arch/arm/config/bcm2835_defconfig > > because it enables CONFIG_CC_OPTIMIZE_FOR_SIZE. The compiler tends > > to prefer not inlining functions with -Os. I was able to reproduce > > it with other boards and defconfig files by manually enabling > > CONFIG_CC_OPTIMIZE_FOR_SIZE. > > > > The __get_user_check() specifically uses r0, r1, r2 registers. > > So, uaccess_save_and_enable() and uaccess_restore() must be inlined > > in order to avoid those registers being overwritten in the callees. > > > > Prior to commit 9012d011660e ("compiler: allow all arches to enable > > CONFIG_OPTIMIZE_INLINING"), the 'inline' marker was always enough for > > inlining functions, except on x86. > > > > Since that commit, all architectures can enable CONFIG_OPTIMIZE_INLINING. > > So, __always_inline is now the only guaranteed way of forcible inlining. > > > > I want to keep as much compiler's freedom as possible about the inlining > > decision. So, I changed the function call order instead of adding > > __always_inline around. > > > > Call uaccess_save_and_enable() before assigning the __p ("r0"), and > > uaccess_restore() after evacuating the __e ("r0"). > > > > Fixes: 9012d011660e ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING") > > Reported-by: "kernelci.org bot" > > Reported-by: Nicolas Saenz Julienne > > Signed-off-by: Masahiro Yamada > > --- > > > > arch/arm/include/asm/uaccess.h | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h > > index 303248e5b990..559f252d7e3c 100644 > > --- a/arch/arm/include/asm/uaccess.h > > +++ b/arch/arm/include/asm/uaccess.h > > @@ -191,11 +191,12 @@ extern int __get_user_64t_4(void *); > > #define __get_user_check(x, p) \ > > ({ \ > > unsigned long __limit = current_thread_info()->addr_limit - 1; \ > > + unsigned int __ua_flags = uaccess_save_and_enable(); \ > > If the compiler is moving uaccess_save_and_enable(), that's something > we really don't want Hmm, based on my poor knowledge about compilers, I do not know if this re-arrangement happens... > - the idea is to _minimise_ the number of kernel > memory accesses between enabling userspace access and performing the > actual access. > > Fixing it in this way widens the window for the kernel to be doing > something it shoulding in userspace. > > So, the right solution is to ensure that the compiler always inlines > the uaccess_*() helpers - which should be nothing more than four > instructions for uaccess_save_and_enable() and two for the > restore. > OK, I will use __always_inline to avoid any potential behavior change. Thanks. -- Best Regards Masahiro Yamada