Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp8007693ybn; Tue, 1 Oct 2019 01:30:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqweEA1ZfK66LWgL4M1iy0JlscPt2EYdR5eRH09XgWt5RgC1Rtlgte3mLMvYpkzbUs5NQI3L X-Received: by 2002:a17:906:c82d:: with SMTP id dd13mr12079367ejb.169.1569918649232; Tue, 01 Oct 2019 01:30:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569918649; cv=none; d=google.com; s=arc-20160816; b=RvicRPRuBxdJy/wdK2tpdRpFjbHlylkneQF0DeJ34pEkpHMuf/YoJmZCjs1nkTHKac Qtvhke22QoZswwAA/PBenqD/aXI/doy2jtq6GYBAggW65DgQSsgoLLshw6W9pHmzYidu fGQk06A/dStumSEMw1wfw61n+P/O7nkEhOugxwVlwONL4GbzSEKgdDNuMuafbHtqHFT8 cb8JqB6iAnFV5zuMNOAIq0zErQ76HWe1e69pN36IfFhZ3p/UNQ5AlxghL7hAINrbs8xE 3MU2Nd7QtEgrZ4WMlQ3eF2AvTZgEkl/6MMqm17EcPfca0xc8B6wN2NqJkYjDmyu21IMP f1Ig== 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=js7jLpstY+bD7D39QxN+sPmHytiad2GlmiLmccMGu30=; b=ENtgOOYjby64cpL6zr9EFFU/YFN19IlJJxz6xkDQh8M993e0wkWKB2hU8GQY/ap7NI 1ImK6JnGHzcPtm8aGMtJC691T67MvfyIgeuJpU+jRsVFrCo3pfOnoZCOAKdk3CmIvdQc mf5taQqmrbbqLgQFXx2Qdnc+2E/NF9FkBteDgtROBqFn4fbIOkgYJEvvjA9EXHvnVA6l 14rWf2CA+ftJTCcbs0TU7t1EZgzKiTauTmunpzaDhnxJZBnhT0BaGf4gIiRowW8hrhL/ he7ondfcBZL1JRKA+Cnt7o9Qqs3FBTz0dpYybAj1MJf0mhyuN5Yai1FQw+w4o9gBzdY5 V49g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=cK0920T8; 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 n8si8142040ejh.169.2019.10.01.01.30.23; Tue, 01 Oct 2019 01:30:49 -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=cK0920T8; 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 S1729016AbfJAI3h (ORCPT + 99 others); Tue, 1 Oct 2019 04:29:37 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:50112 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726148AbfJAI3g (ORCPT ); Tue, 1 Oct 2019 04:29:36 -0400 Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (authenticated) by conssluserg-04.nifty.com with ESMTP id x918TUBZ026576 for ; Tue, 1 Oct 2019 17:29:31 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com x918TUBZ026576 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1569918571; bh=js7jLpstY+bD7D39QxN+sPmHytiad2GlmiLmccMGu30=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cK0920T8vARsG3qEuhifZYpBjDGp97raapPMW4j1gzTD77IUFm3Nijw5ZuSSW62JJ ahY4//UPyASJwbwHn4x1XsBLuJQYQPdysT9NWOvG8sJJkrb31ag6jbkUw0394M69pG 0JASsJCBrxjTED9uj/5OPj8gBpdURJp4qubIw7MSJuv2WGkJP8BtmtqfiVgnQj4/XJ Ormfsj/u7Uc82nTGhNxpgRHc6Ygkzd/G4IGVndjD06N52Ato2tTorinlMkbl2aWash D1XTGl+IokGWWtb52FJjaPWm+Upl27/Zz/39YdPD5iwjVNCOyjCVhnXKSj7Tp9+6Iw V5iBUy7B5IgXQ== X-Nifty-SrcIP: [209.85.217.46] Received: by mail-vs1-f46.google.com with SMTP id z14so8720062vsz.13 for ; Tue, 01 Oct 2019 01:29:31 -0700 (PDT) X-Gm-Message-State: APjAAAX8vx+zGgsn+aKYyTC9VIuXw4W8uJA5AlmCH2YNL1RJJ5E7mgqp rmDjsnC8v2+Q3rDojPdc+PXIHhaqLlllgpMkbWo= X-Received: by 2002:a67:88c9:: with SMTP id k192mr12215131vsd.181.1569918569917; Tue, 01 Oct 2019 01:29:29 -0700 (PDT) MIME-Version: 1.0 References: <20190930055925.25842-1-yamada.masahiro@socionext.com> In-Reply-To: From: Masahiro Yamada Date: Tue, 1 Oct 2019 17:28:53 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] ARM: fix __get_user_check() in case uaccess_* calls are not inlined To: Nick Desaulniers Cc: Linux ARM , Russell King , Linus Torvalds , Olof Johansson , Arnd Bergmann , Nicolas Saenz Julienne , Julien Thierry , Russell King , Stefan Agner , Thomas Gleixner , Vincent Whitchurch , LKML 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 Nick, On Tue, Oct 1, 2019 at 7:19 AM Nick Desaulniers wrote: > > On Sun, Sep 29, 2019 at 11:00 PM 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. > > Yep, that part is obvious, but... > > > So, uaccess_save_and_enable() and uaccess_restore() must be inlined > > in order to avoid those registers being overwritten in the callees. > > Right, r0, r1, r2 are caller saved, meaning that __get_user_check must > save/restore them when making function calls. So > uaccess_save_and_enable() and uaccess_restore() should either be made > into macros (macros and typecheck (see include/linux/typecheck.h) are > peanut butter and chocolate), or occur at different points in the > function when those register variables are no longer in use. > > > > > 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(); \ > > register typeof(*(p)) __user *__p asm("r0") = (p); \ > > register __inttype(x) __r2 asm("r2"); \ > > register unsigned long __l asm("r1") = __limit; \ > > register int __e asm("r0"); \ > > What does it mean for there to be two different local variables pinned > to the same register? Ie. it looks like __e and __p are defined to > exist in r0. Would having one variable and an explicit cast result in > differing storage? In my understanding, __p is input (a pointer to the user-space) __e is output (return value) Maybe, does it use two variables for clarification? > > > - unsigned int __ua_flags = uaccess_save_and_enable(); \ > > + unsigned int __err; \ > > switch (sizeof(*(__p))) { \ > > case 1: \ > > if (sizeof((x)) >= 8) \ > > @@ -223,9 +224,10 @@ extern int __get_user_64t_4(void *); > > break; \ > > default: __e = __get_user_bad(); break; \ > > ^ I think this assignment to __e should be replaced with an assignment > to __err? We no longer need the register at this point and could skip > the assignment of x. Right, but '__err = __e' is necessary for non-default cases. -- Best Regards Masahiro Yamada