All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Guenter Roeck <groeck@google.com>,
	Kees Cook <keescook@chromium.org>, kernelci <kernelci@groups.io>,
	Guillaume Tucker <guillaume.tucker@collabora.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>, Mark Brown <broonie@kernel.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Matt Hart <matthew.hart@linaro.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Kevin Hilman <khilman@baylibre.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	linux <linux@dominikbrodowski.net>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Adrian Reber <adrian@lisas.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm <linux-mm@kvack.org>,
	Richard Guy Briggs <rgb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>, info <info@kernelci.org>,
	rostedt <rostedt@goodmis.org>, Jason Baron <jbaron@redhat.com>,
	Rabin Vincent <rabin@rab.in>,
	Russell King <rmk+kernel@arm.linux.org.uk>
Subject: Re: next/master boot bisection: next-20190215 on beaglebone-black
Date: Tue, 16 Apr 2019 15:25:11 -0400 (EDT)	[thread overview]
Message-ID: <2030770457.2767.1555442711654.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1444448267.2739.1555442221738.JavaMail.zimbra@efficios.com>

----- 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 <groeck@google.com> 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

  reply	other threads:[~2019-04-16 19:25 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 18:20 next/master boot bisection: next-20190215 on beaglebone-black kernelci.org bot
2019-02-15 18:43 ` Andrew Morton
2019-02-15 18:51   ` Mark Brown
2019-02-15 19:00     ` Andrew Morton
2019-02-16  6:21       ` Stephen Rothwell
2019-02-26 23:59     ` Andrew Morton
2019-02-27  0:04       ` Dan Williams
2019-02-27  0:04         ` Dan Williams
2019-02-28 23:14         ` Andrew Morton
2019-02-28 23:55           ` Dan Williams
2019-02-28 23:55             ` Dan Williams
2019-03-01  8:25             ` Guillaume Tucker
2019-03-01  8:25               ` Guillaume Tucker
2019-03-01 10:40               ` Mike Rapoport
2019-03-01 11:49                 ` Mark Brown
2019-03-01 20:41               ` Andrew Morton
2019-03-01 21:04                 ` Guillaume Tucker
2019-03-01 21:04                   ` Guillaume Tucker
2019-03-01 23:23                   ` Dan Williams
2019-03-01 23:23                     ` Dan Williams
2019-03-06 10:14                     ` Guillaume Tucker
2019-03-06 10:14                       ` Guillaume Tucker
2019-03-06 14:05                       ` Mike Rapoport
2019-03-07  9:16                         ` Guillaume Tucker
2019-03-07  9:16                           ` Guillaume Tucker
2019-03-07 15:43                           ` Dan Williams
2019-03-07 15:43                             ` Dan Williams
2019-04-10 22:52                             ` Kees Cook
2019-04-10 22:52                               ` Kees Cook
2019-04-11 16:42                               ` Guenter Roeck
2019-04-11 16:42                                 ` Guenter Roeck
2019-04-11 16:42                                 ` Guenter Roeck
2019-04-11 17:35                                 ` Kees Cook
2019-04-11 17:35                                   ` Kees Cook
2019-04-11 20:08                                   ` Guenter Roeck
2019-04-11 20:08                                     ` Guenter Roeck
2019-04-11 20:22                                     ` Dan Williams
2019-04-11 20:22                                       ` Dan Williams
2019-04-11 20:53                                       ` Guenter Roeck
2019-04-11 20:53                                         ` Guenter Roeck
2019-04-16 18:54                                         ` Dan Williams
2019-04-16 18:54                                           ` Dan Williams
2019-04-16 19:17                                           ` Mathieu Desnoyers
2019-04-16 19:17                                             ` Mathieu Desnoyers
2019-04-16 19:25                                             ` Mathieu Desnoyers [this message]
2019-04-16 19:25                                               ` Mathieu Desnoyers
2019-04-16 19:45                                               ` Mathieu Desnoyers
2019-04-16 19:45                                                 ` Mathieu Desnoyers
2019-04-16 19:33                                           ` Guenter Roeck
2019-04-16 19:33                                             ` Guenter Roeck
2019-04-16 20:37                                             ` Dan Williams
2019-04-16 20:37                                               ` Dan Williams
2019-04-16 21:04                                               ` Guenter Roeck
2019-04-16 21:04                                                 ` Guenter Roeck
2019-04-17  3:30                                                 ` Kees Cook
2019-04-17  3:30                                                   ` Kees Cook
2019-04-16 20:05                                           ` Mathieu Desnoyers
2019-04-16 20:05                                             ` Mathieu Desnoyers
2019-04-11 20:49                                     ` Mike Rapoport
2019-03-01 11:45           ` Mark Brown
2019-03-01  9:02         ` Vlastimil Babka
2019-02-18  9:44 ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2030770457.2767.1555442711654.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=adrian@lisas.de \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@google.com \
    --cc=guillaume.tucker@collabora.com \
    --cc=hannes@cmpxchg.org \
    --cc=info@kernelci.org \
    --cc=jbaron@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernelci@groups.io \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@dominikbrodowski.net \
    --cc=matthew.hart@linaro.org \
    --cc=mhocko@suse.com \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rabin@rab.in \
    --cc=rgb@redhat.com \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=rostedt@goodmis.org \
    --cc=rppt@linux.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tomeu.vizoso@collabora.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.