Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp6661817ybn; Mon, 30 Sep 2019 01:30:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqxXH49/Mc3TRyBM/iS8CHwKUcNXnvOe4d4zR0YmCRfyp/nKuAhWJouF1eZRM377Y26zBZmU X-Received: by 2002:a17:906:960d:: with SMTP id s13mr18271320ejx.166.1569832243365; Mon, 30 Sep 2019 01:30:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569832243; cv=none; d=google.com; s=arc-20160816; b=Zf+JGPwwIFg2a0iIfZlWzbveW+h6RkatZdtRUvm2KckyWrnr3b3ijRD09SzRx9MScf vnYdk3VHI9Cc4SBW1WxooWEbmbx7ssSWYD2eGhnpor9BkZHLtXlCDEzhYcIIs0ipnyhk spYhEwUt6g1GmV+LFsMMxf/9wp7N8W8Dz50mjKRozI5N5aVkzI3O1ywti4ArKZzd1ois xv+Pn1NczyvG1YK0uDmYNsCbiHIfyr1v2XoayEABedeaq+vyyW3xWDEgb7ZuUudu/bi2 kSTokezMiejkgMllUtRIx64Z4Qk4Id7fZdI1g0Q8PIMgekxI/m6ofE9UeaYLS9QpsgtX mB9Q== 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=S3XJDoeipww5RQbEvSMupd7ozkKy8JwBydWHSl7iEd8=; b=CHGolHkI/YJDcUTRhvNDbn+oOHs0mPPlDkwUpb6VcmFlnHUlOHJRyFDHqwHSq+oRhF shnE1T/eO5yql6we5ZLZmCa1BoWXdrXRIoZswsou+iUK9le5VPaqMr1HJ22EvAHkAxBp JgAlLb5qP8YUTE1cLnKZP6NGZB+jTNPx0boAsWlm1al2TCeF3iDmF8E8ap7dG1qZo0FV heT6/UKWQGz+ghaycRTjEIqDEk5Dz5k3jt8YSv+JCSEFiNNCJzbPyT4zudnT/LUte9FF RbVcmmNXkgMU7i6kx+KeLhq1Z5pFPqL9mnfEabbq3izSN2DizphNEFOwOqMXU/jbPSvH rvbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=UMLkZkxe; 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 u11si6722174ejr.234.2019.09.30.01.30.18; Mon, 30 Sep 2019 01:30:43 -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=UMLkZkxe; 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 S1730050AbfI3I1f (ORCPT + 99 others); Mon, 30 Sep 2019 04:27:35 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:41038 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729254AbfI3I1f (ORCPT ); Mon, 30 Sep 2019 04:27:35 -0400 Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (authenticated) by conssluserg-04.nifty.com with ESMTP id x8U8R4vs026947 for ; Mon, 30 Sep 2019 17:27:04 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com x8U8R4vs026947 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1569832025; bh=S3XJDoeipww5RQbEvSMupd7ozkKy8JwBydWHSl7iEd8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UMLkZkxecf6GdVqFNZtK3I5UzfFgRPItb95ROKa80T/3sa/9Eiehes5+KNghNotEA EbgDc04gztLox5jrIiJb0xhh3XcQuNj2v2wueRxKc0vYzuEgwRO1fVwianL73Yc8mG mx17qPyFl4wPz8U0ssJUkboAE/+Z000MpXUOwO3yzN48jY3V/1UcmaxUoJZ9GCOSPV gocNk+Rs8IU5bi9t0clQ0Ac8DCi0W0UdN6kIaI+nci9GIbK+S2fsYZvaWzwABsnX6F fgWOaKo41QeSGMN9AdX2jaGBcZd9QCqmVEQNzDr/x1EJv+j7F4q7jZzN0OMiw5tawy wFP1flpOBSYxA== X-Nifty-SrcIP: [209.85.217.43] Received: by mail-vs1-f43.google.com with SMTP id d204so6143592vsc.12 for ; Mon, 30 Sep 2019 01:27:04 -0700 (PDT) X-Gm-Message-State: APjAAAU6RPI5e0awEHW2/0ivvBkxzcgv2PpJrvVKkLTITq1gFIlzBu1L YuZeKJe632pE5cgCWViDeq//7QE0vaXPvTemtOA= X-Received: by 2002:a67:1e87:: with SMTP id e129mr9358134vse.179.1569832023746; Mon, 30 Sep 2019 01:27:03 -0700 (PDT) MIME-Version: 1.0 References: <20190930055925.25842-1-yamada.masahiro@socionext.com> In-Reply-To: From: Masahiro Yamada Date: Mon, 30 Sep 2019 17:26:27 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] ARM: fix __get_user_check() in case uaccess_* calls are not inlined To: Arnd Bergmann Cc: Linux ARM , Russell King , Vincent Whitchurch , Nick Desaulniers , Russell King , Stefan Agner , "linux-kernel@vger.kernel.org" , Julien Thierry , Olof Johansson , Thomas Gleixner , Linus Torvalds , Nicolas Saenz Julienne 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 Arnd, On Mon, Sep 30, 2019 at 4:57 PM Arnd Bergmann wrote: > > On Mon, Sep 30, 2019 at 8:01 AM 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 > > Acked-by: Arnd Bergmann > > The patch looks reasonable to me, but I think we should also revert > commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING > forcibly") in mainline for now, as it caused this to happen all the time rather > than only for users that expliticly select CONFIG_OPTIMIZE_INLINING. > > We have had other bug reports starting with that commit that run into > similar issues, and I'm sure there are more of them. I don't mind having it > in linux-next for a while long, but I think it was premature to have it merged > into mainline. > > Arnd Hmm, I know you are testing randconfig build tests, but how many people are testing the kernel boot in linux-next? People and kernelci started to report the issue immediately after it landed in the mainline... -- Best Regards Masahiro Yamada