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=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS 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 6C3D1C10F14 for ; Tue, 16 Apr 2019 19:25:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 34488206B6 for ; Tue, 16 Apr 2019 19:25:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="QUJABhXu" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728968AbfDPTZO (ORCPT ); Tue, 16 Apr 2019 15:25:14 -0400 Received: from mail.efficios.com ([167.114.142.138]:37380 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727136AbfDPTZO (ORCPT ); Tue, 16 Apr 2019 15:25:14 -0400 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 9D68A1D645E; Tue, 16 Apr 2019 15:25:12 -0400 (EDT) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id mx16-Xo3oWEX; Tue, 16 Apr 2019 15:25:12 -0400 (EDT) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 037CE1D6454; Tue, 16 Apr 2019 15:25:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 037CE1D6454 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1555442712; bh=dBAHxV+5AMeW0yIbrFxTc9ZyYkcIIhy/PrmkHPHr6wE=; h=Date:From:To:Message-ID:MIME-Version; b=QUJABhXu/WNVZ7zNbafJdZ7I78dLNA53TOuoh05mrHWGIFzEAxzioMOGQSGLnvUU8 VVz+4Y8GHSkXGAiG205Hp5mdM0OlQk0f4mkP4q1FdkWiD8bqED3ffXQ71Ueo9lbnVe Vfn3BxKwAsaNV5mEDCWli7PpI1lmZ+q71tVuJs24yAHrPrRr8/WyNw2Mls/AyWnIxT uS0dU9VFKZOag3fkYtRml29JIiQb2rs951nodm4mAEzHlXkL3CIWf0VPHaszf6GpQ9 wizmnVmiFXTYenblJJ1JCmn5gHzeBdwmuHIwKeO3KVrTNHbYL0J5gpmoZM1lFmFS1j oHqy41bvVmK+A== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id VWNPj0DABGiH; Tue, 16 Apr 2019 15:25:11 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id C6EBE1D644A; Tue, 16 Apr 2019 15:25:11 -0400 (EDT) Date: Tue, 16 Apr 2019 15:25:11 -0400 (EDT) From: Mathieu Desnoyers To: Dan Williams Cc: Guenter Roeck , Kees Cook , kernelci , Guillaume Tucker , Mike Rapoport , Andrew Morton , Michal Hocko , Mark Brown , Tomeu Vizoso , Matt Hart , Stephen Rothwell , Kevin Hilman , Enric Balletbo i Serra , Nicholas Piggin , linux , Masahiro Yamada , Adrian Reber , linux-kernel , Johannes Weiner , linux-mm , Richard Guy Briggs , Peter Zijlstra , info , rostedt , Jason Baron , Rabin Vincent , Russell King Message-ID: <2030770457.2767.1555442711654.JavaMail.zimbra@efficios.com> In-Reply-To: <1444448267.2739.1555442221738.JavaMail.zimbra@efficios.com> References: <20190215185151.GG7897@sirena.org.uk> <1444448267.2739.1555442221738.JavaMail.zimbra@efficios.com> Subject: Re: next/master boot bisection: next-20190215 on beaglebone-black MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.12_GA_3794 (ZimbraWebClient - FF66 (Linux)/8.8.12_GA_3794) Thread-Topic: next/master boot bisection: next-20190215 on beaglebone-black Thread-Index: o2XfqTzgA9kPUT1d7tzJPHm/yG+fqP8/3aj6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Apr 16, 2019, at 3:17 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > ----- On Apr 16, 2019, at 2:54 PM, Dan Williams dan.j.williams@intel.com wrote: > >> On Thu, Apr 11, 2019 at 1:54 PM Guenter Roeck wrote: >> [..] >>> > > Boot tests report >>> > > >>> > > Qemu test results: >>> > > total: 345 pass: 345 fail: 0 >>> > > >>> > > This is on top of next-20190410 with CONFIG_SHUFFLE_PAGE_ALLOCATOR=y >>> > > and the known crashes fixed. >>> > >>> > In addition to CONFIG_SHUFFLE_PAGE_ALLOCATOR=y you also need the >>> > kernel command line option "page_alloc.shuffle=1" >>> > >>> > ...so I doubt you are running with shuffling enabled. Another way to >>> > double check is: >>> > >>> > cat /sys/module/page_alloc/parameters/shuffle >>> >>> Yes, you are right. Because, with it enabled, I see: >>> >>> Kernel command line: rdinit=/sbin/init page_alloc.shuffle=1 panic=-1 >>> console=ttyAMA0,115200 page_alloc.shuffle=1 >>> ------------[ cut here ]------------ >>> WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:303 >>> page_alloc_shuffle+0x12c/0x1ac >>> static_key_enable(): static key 'page_alloc_shuffle_key+0x0/0x4' used >>> before call to jump_label_init() >> >> This looks to be specific to ARM never having had to deal with >> DEFINE_STATIC_KEY_TRUE in the past. >> >> I am able to avoid this warning by simply not enabling JUMP_LABEL >> support in my build. > > How large is your kernel image in memory ? Is it larger than 32MB > by any chance ? > > On arm, the arch_static_branch() uses a "nop" instruction, which seems > fine. However, I have a concern wrt arch_static_branch_jump(): > > arch/arm/include/asm/jump_label.h defines: > > static __always_inline bool arch_static_branch_jump(struct static_key *key, bool > branch) > { > asm_volatile_goto("1:\n\t" > WASM(b) " %l[l_yes]\n\t" > ".pushsection __jump_table, \"aw\"\n\t" > ".word 1b, %l[l_yes], %c0\n\t" > ".popsection\n\t" > : : "i" (&((char *)key)[branch]) : : l_yes); > > return false; > l_yes: > return true; > } > > Which should work fine as long as the branch target is within +/-32MB range of > the branch instruction. However, based on > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihfddaf.html > : > > "Extending branch ranges > > Machine-level B and BL instructions have restricted ranges from the address of > the current instruction. However, you can use these instructions even if label > is out of range. Often you do not know where the linker places label. When > necessary, the linker adds code to enable longer branches. The added code is > called a veneer." > > So if by an odd chance this branch is turned into a longer branch by the linker, > then > the code pattern would be completely unexpected by arch/arm/kernel/jump_label.c. > > Can you try with the following (untested) patch ? The logic in my previous patch was bogus. Here is an updated version (untested): diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h index e12d7d096fc0..7c35f57b72c5 100644 --- a/arch/arm/include/asm/jump_label.h +++ b/arch/arm/include/asm/jump_label.h @@ -23,12 +23,21 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran return true; } +/* + * The linker adds veneer code if target of the branch is beyond +/-32MB + * range, so ensure we never patch a branch instruction which target is + * outside of the inline asm. + */ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch) { asm_volatile_goto("1:\n\t" + WASM(nop) "\n\t" + WASM(b) "2f\n\t" + "3:\n\t" WASM(b) " %l[l_yes]\n\t" + "2:\n\t" ".pushsection __jump_table, \"aw\"\n\t" - ".word 1b, %l[l_yes], %c0\n\t" + ".word 1b, 3b, %c0\n\t" ".popsection\n\t" : : "i" (&((char *)key)[branch]) : : l_yes); Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com