Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On Fri, Nov 10, 2017 at 04:32:45PM -0500, Jason Baron wrote:
>
> On 11/09/2017 03:56 PM, Paul E. McKenney wrote:
> > On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
> >> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> >>> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>
>
> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> > Hello,
> >
> > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
> >
>
> Hi,
>
> So this looks like the branches aren't getting updated because the
> WARN_ON()s are all from the second half of the test loop (where we
> actually change the branch direction).
>
> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
> was not able to trigger the WARN_ON(). Do you know if it happens on
> every boot or if there is some boot timing involved?
>
> You could try the patch below, to start to narrow down if this is a
> problem with jump table setup or with the update process.
> >>>
> >>> The problem disappears after this patch.
> >>>
> >>
> >> Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
> >> something like the following to the command-line: "rcuperf.shutdown=1
> >> rcuperf.holdoff=2".
> >
> > Just to be clear, this combination of parameters says to start the test
> > -after- shutting down the system, which should not be expected to do
> > anything useful.
> >
> >> The issue is that the core jump label code uses kernel_text_address() to
> >> ensure that it does not update branches in '__init' text after it has
> >> been freed. The check uses 'system_state' variable from
> >> core_kernel_text() to make the determination:
> >>
> >> if (system_state < SYSTEM_RUNNING &&
> >>
> >> init_kernel_text(addr))
> >>
> >> return 1;
> >>
> >> return 0;
> >>
> >> So the general idea is that system_state is set to SYSTEM_RUNNING after
> >> the __init text sections are freed, and thus we avoid updating jump
> >> label branches.
> >>
> >> However, in the case that rcuperf is enabled, it will call
> >> kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
> >> (which is > SYSTEM_RUNNING), potentially before the the initcalls have
> >> even been run. In this case, the jump label selftests called from __init
> >> via a late_initcall() can not update the branch direction, and thus we
> >> get the above warnings (due to the fact that the branches don't get
> >> udpated).
> >>
> >> So this is really not a new issue and really is only triggered in a
> >> debug setup, so I don't think this is 4.14 material in any way...
> >>
> >> One way to clean this up is to add a call into the jump label code
> >> similar to what ftrace does in ftrace_free_init_mem(). This gets called
> >> after the initcalls have run but before they are freed. Something like
> >> below.
> >
> > Alternatively, rcuperf (and rcutorture and locktorture) could refused
> > to power off the system until the system state reaches SYSTEM_RUNNING.
>
> Indeed, I think this may make more sense since there may be other code
> that depends on SYSTEM_POWER_OFF state coming after SYSTEM_RUNNING. So
> if you are ok with this, I can prepare that change instead.
Please feel free to send a patch. Ah, one alternative would be
to make kernel_power_off() do the check. Or maybe better yet,
kernel_shutdown_prepare().
Thanx, Paul
> Thanks,
>
> -Jason
>
>
> > That said, I am quite happy to have it fixed elsewhere. ;-)
> >
> > Thanx, Paul
> >
> >> Thanks,
> >>
> >> -Jason
> >>
> >> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> >> index 3b7675b..0202c58 100644
> >> --- a/include/linux/jump_label.h
> >> +++ b/include/linux/jump_label.h
> >> @@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
> >> jump_entry *entry,
> >> extern void arch_jump_label_transform_static(struct jump_entry *entry,
> >> enum jump_label_type type);
> >> extern int jump_label_text_reserved(void *start, void *end);
> >> +extern void jump_label_invalidate_init(struct module *mod);
> >> extern void static_key_slow_inc(struct static_key *key);
> >> extern void static_key_slow_dec(struct static_key *key);
> >> extern void jump_label_apply_nops(struct module *mod);
> >> @@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
> >> module *mod)
> >> return 0;
> >> }
> >>
> >> +static inline void jump_label_invalidate_init(struct module *mod) {}
> >> +
> >> static inline void static_key_enable(struct static_key *key)
> >> {
> >> STATIC_KEY_CHECK_USE();
> >> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> >> index 4b484ab..23e3cba 100644
> >> --- a/include/linux/kernel.h
> >> +++ b/include/linux/kernel.h
> >> @@ -471,6 +471,7 @@
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On Fri, Nov 10, 2017 at 04:32:45PM -0500, Jason Baron wrote:
>
> On 11/09/2017 03:56 PM, Paul E. McKenney wrote:
> > On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
> >> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> >>> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>
>
> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> > Hello,
> >
> > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
> >
>
> Hi,
>
> So this looks like the branches aren't getting updated because the
> WARN_ON()s are all from the second half of the test loop (where we
> actually change the branch direction).
>
> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
> was not able to trigger the WARN_ON(). Do you know if it happens on
> every boot or if there is some boot timing involved?
>
> You could try the patch below, to start to narrow down if this is a
> problem with jump table setup or with the update process.
> >>>
> >>> The problem disappears after this patch.
> >>>
> >>
> >> Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
> >> something like the following to the command-line: "rcuperf.shutdown=1
> >> rcuperf.holdoff=2".
> >
> > Just to be clear, this combination of parameters says to start the test
> > -after- shutting down the system, which should not be expected to do
> > anything useful.
> >
> >> The issue is that the core jump label code uses kernel_text_address() to
> >> ensure that it does not update branches in '__init' text after it has
> >> been freed. The check uses 'system_state' variable from
> >> core_kernel_text() to make the determination:
> >>
> >> if (system_state < SYSTEM_RUNNING &&
> >>
> >> init_kernel_text(addr))
> >>
> >> return 1;
> >>
> >> return 0;
> >>
> >> So the general idea is that system_state is set to SYSTEM_RUNNING after
> >> the __init text sections are freed, and thus we avoid updating jump
> >> label branches.
> >>
> >> However, in the case that rcuperf is enabled, it will call
> >> kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
> >> (which is > SYSTEM_RUNNING), potentially before the the initcalls have
> >> even been run. In this case, the jump label selftests called from __init
> >> via a late_initcall() can not update the branch direction, and thus we
> >> get the above warnings (due to the fact that the branches don't get
> >> udpated).
> >>
> >> So this is really not a new issue and really is only triggered in a
> >> debug setup, so I don't think this is 4.14 material in any way...
> >>
> >> One way to clean this up is to add a call into the jump label code
> >> similar to what ftrace does in ftrace_free_init_mem(). This gets called
> >> after the initcalls have run but before they are freed. Something like
> >> below.
> >
> > Alternatively, rcuperf (and rcutorture and locktorture) could refused
> > to power off the system until the system state reaches SYSTEM_RUNNING.
>
> Indeed, I think this may make more sense since there may be other code
> that depends on SYSTEM_POWER_OFF state coming after SYSTEM_RUNNING. So
> if you are ok with this, I can prepare that change instead.
Please feel free to send a patch. Ah, one alternative would be
to make kernel_power_off() do the check. Or maybe better yet,
kernel_shutdown_prepare().
Thanx, Paul
> Thanks,
>
> -Jason
>
>
> > That said, I am quite happy to have it fixed elsewhere. ;-)
> >
> > Thanx, Paul
> >
> >> Thanks,
> >>
> >> -Jason
> >>
> >> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> >> index 3b7675b..0202c58 100644
> >> --- a/include/linux/jump_label.h
> >> +++ b/include/linux/jump_label.h
> >> @@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
> >> jump_entry *entry,
> >> extern void arch_jump_label_transform_static(struct jump_entry *entry,
> >> enum jump_label_type type);
> >> extern int jump_label_text_reserved(void *start, void *end);
> >> +extern void jump_label_invalidate_init(struct module *mod);
> >> extern void static_key_slow_inc(struct static_key *key);
> >> extern void static_key_slow_dec(struct static_key *key);
> >> extern void jump_label_apply_nops(struct module *mod);
> >> @@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
> >> module *mod)
> >> return 0;
> >> }
> >>
> >> +static inline void jump_label_invalidate_init(struct module *mod) {}
> >> +
> >> static inline void static_key_enable(struct static_key *key)
> >> {
> >> STATIC_KEY_CHECK_USE();
> >> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> >> index 4b484ab..23e3cba 100644
> >> --- a/include/linux/kernel.h
> >> +++ b/include/linux/kernel.h
> >> @@ -471,6 +471,7 @@
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/09/2017 03:56 PM, Paul E. McKenney wrote:
> On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
>> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
>>> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>
Hi,
So this looks like the branches aren't getting updated because the
WARN_ON()s are all from the second half of the test loop (where we
actually change the branch direction).
I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
was not able to trigger the WARN_ON(). Do you know if it happens on
every boot or if there is some boot timing involved?
You could try the patch below, to start to narrow down if this is a
problem with jump table setup or with the update process.
>>>
>>> The problem disappears after this patch.
>>>
>>
>> Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
>> something like the following to the command-line: "rcuperf.shutdown=1
>> rcuperf.holdoff=2".
>
> Just to be clear, this combination of parameters says to start the test
> -after- shutting down the system, which should not be expected to do
> anything useful.
>
>> The issue is that the core jump label code uses kernel_text_address() to
>> ensure that it does not update branches in '__init' text after it has
>> been freed. The check uses 'system_state' variable from
>> core_kernel_text() to make the determination:
>>
>> if (system_state < SYSTEM_RUNNING &&
>>
>> init_kernel_text(addr))
>>
>> return 1;
>>
>> return 0;
>>
>> So the general idea is that system_state is set to SYSTEM_RUNNING after
>> the __init text sections are freed, and thus we avoid updating jump
>> label branches.
>>
>> However, in the case that rcuperf is enabled, it will call
>> kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
>> (which is > SYSTEM_RUNNING), potentially before the the initcalls have
>> even been run. In this case, the jump label selftests called from __init
>> via a late_initcall() can not update the branch direction, and thus we
>> get the above warnings (due to the fact that the branches don't get
>> udpated).
>>
>> So this is really not a new issue and really is only triggered in a
>> debug setup, so I don't think this is 4.14 material in any way...
>>
>> One way to clean this up is to add a call into the jump label code
>> similar to what ftrace does in ftrace_free_init_mem(). This gets called
>> after the initcalls have run but before they are freed. Something like
>> below.
>
> Alternatively, rcuperf (and rcutorture and locktorture) could refused
> to power off the system until the system state reaches SYSTEM_RUNNING.
>
Indeed, I think this may make more sense since there may be other code
that depends on SYSTEM_POWER_OFF state coming after SYSTEM_RUNNING. So
if you are ok with this, I can prepare that change instead.
Thanks,
-Jason
> That said, I am quite happy to have it fixed elsewhere. ;-)
>
> Thanx, Paul
>
>> Thanks,
>>
>> -Jason
>>
>> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
>> index 3b7675b..0202c58 100644
>> --- a/include/linux/jump_label.h
>> +++ b/include/linux/jump_label.h
>> @@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
>> jump_entry *entry,
>> extern void arch_jump_label_transform_static(struct jump_entry *entry,
>> enum jump_label_type type);
>> extern int jump_label_text_reserved(void *start, void *end);
>> +extern void jump_label_invalidate_init(struct module *mod);
>> extern void static_key_slow_inc(struct static_key *key);
>> extern void static_key_slow_dec(struct static_key *key);
>> extern void jump_label_apply_nops(struct module *mod);
>> @@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
>> module *mod)
>> return 0;
>> }
>>
>> +static inline void jump_label_invalidate_init(struct module *mod) {}
>> +
>> static inline void static_key_enable(struct static_key *key)
>> {
>> STATIC_KEY_CHECK_USE();
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> index 4b484ab..23e3cba 100644
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -471,6 +471,7 @@ extern unsigned long long memparse(const char *ptr,
>> char **retptr);
>> extern bool parse_option_str(const char *str, const char *option);
>> extern char *next_arg(char *args, char **param, char **val);
>>
>> +extern int init_kernel_text(unsigned long addr);
>> extern int core_kernel_text(unsigned long addr);
>> extern int core_kernel_data(unsigned long addr);
>> extern int __kernel_text_address(unsigned long addr);
>> diff --git a/init/main.c b/init/main.c
>> index 0ee9c686..f4e5ab5 100644
>> ---
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/09/2017 03:56 PM, Paul E. McKenney wrote:
> On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
>> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
>>> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>
Hi,
So this looks like the branches aren't getting updated because the
WARN_ON()s are all from the second half of the test loop (where we
actually change the branch direction).
I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
was not able to trigger the WARN_ON(). Do you know if it happens on
every boot or if there is some boot timing involved?
You could try the patch below, to start to narrow down if this is a
problem with jump table setup or with the update process.
>>>
>>> The problem disappears after this patch.
>>>
>>
>> Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
>> something like the following to the command-line: "rcuperf.shutdown=1
>> rcuperf.holdoff=2".
>
> Just to be clear, this combination of parameters says to start the test
> -after- shutting down the system, which should not be expected to do
> anything useful.
>
>> The issue is that the core jump label code uses kernel_text_address() to
>> ensure that it does not update branches in '__init' text after it has
>> been freed. The check uses 'system_state' variable from
>> core_kernel_text() to make the determination:
>>
>> if (system_state < SYSTEM_RUNNING &&
>>
>> init_kernel_text(addr))
>>
>> return 1;
>>
>> return 0;
>>
>> So the general idea is that system_state is set to SYSTEM_RUNNING after
>> the __init text sections are freed, and thus we avoid updating jump
>> label branches.
>>
>> However, in the case that rcuperf is enabled, it will call
>> kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
>> (which is > SYSTEM_RUNNING), potentially before the the initcalls have
>> even been run. In this case, the jump label selftests called from __init
>> via a late_initcall() can not update the branch direction, and thus we
>> get the above warnings (due to the fact that the branches don't get
>> udpated).
>>
>> So this is really not a new issue and really is only triggered in a
>> debug setup, so I don't think this is 4.14 material in any way...
>>
>> One way to clean this up is to add a call into the jump label code
>> similar to what ftrace does in ftrace_free_init_mem(). This gets called
>> after the initcalls have run but before they are freed. Something like
>> below.
>
> Alternatively, rcuperf (and rcutorture and locktorture) could refused
> to power off the system until the system state reaches SYSTEM_RUNNING.
>
Indeed, I think this may make more sense since there may be other code
that depends on SYSTEM_POWER_OFF state coming after SYSTEM_RUNNING. So
if you are ok with this, I can prepare that change instead.
Thanks,
-Jason
> That said, I am quite happy to have it fixed elsewhere. ;-)
>
> Thanx, Paul
>
>> Thanks,
>>
>> -Jason
>>
>> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
>> index 3b7675b..0202c58 100644
>> --- a/include/linux/jump_label.h
>> +++ b/include/linux/jump_label.h
>> @@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
>> jump_entry *entry,
>> extern void arch_jump_label_transform_static(struct jump_entry *entry,
>> enum jump_label_type type);
>> extern int jump_label_text_reserved(void *start, void *end);
>> +extern void jump_label_invalidate_init(struct module *mod);
>> extern void static_key_slow_inc(struct static_key *key);
>> extern void static_key_slow_dec(struct static_key *key);
>> extern void jump_label_apply_nops(struct module *mod);
>> @@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
>> module *mod)
>> return 0;
>> }
>>
>> +static inline void jump_label_invalidate_init(struct module *mod) {}
>> +
>> static inline void static_key_enable(struct static_key *key)
>> {
>> STATIC_KEY_CHECK_USE();
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> index 4b484ab..23e3cba 100644
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -471,6 +471,7 @@ extern unsigned long long memparse(const char *ptr,
>> char **retptr);
>> extern bool parse_option_str(const char *str, const char *option);
>> extern char *next_arg(char *args, char **param, char **val);
>>
>> +extern int init_kernel_text(unsigned long addr);
>> extern int core_kernel_text(unsigned long addr);
>> extern int core_kernel_data(unsigned long addr);
>> extern int __kernel_text_address(unsigned long addr);
>> diff --git a/init/main.c b/init/main.c
>> index 0ee9c686..f4e5ab5 100644
>> ---
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> > On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
> >>
> >>
> >> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> >>> Hello,
> >>>
> >>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
> >>>
> >>
> >> Hi,
> >>
> >> So this looks like the branches aren't getting updated because the
> >> WARN_ON()s are all from the second half of the test loop (where we
> >> actually change the branch direction).
> >>
> >> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
> >> was not able to trigger the WARN_ON(). Do you know if it happens on
> >> every boot or if there is some boot timing involved?
> >>
> >> You could try the patch below, to start to narrow down if this is a
> >> problem with jump table setup or with the update process.
> >
> > The problem disappears after this patch.
> >
>
> Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
> something like the following to the command-line: "rcuperf.shutdown=1
> rcuperf.holdoff=2".
Just to be clear, this combination of parameters says to start the test
-after- shutting down the system, which should not be expected to do
anything useful.
> The issue is that the core jump label code uses kernel_text_address() to
> ensure that it does not update branches in '__init' text after it has
> been freed. The check uses 'system_state' variable from
> core_kernel_text() to make the determination:
>
> if (system_state < SYSTEM_RUNNING &&
>
> init_kernel_text(addr))
>
> return 1;
>
> return 0;
>
> So the general idea is that system_state is set to SYSTEM_RUNNING after
> the __init text sections are freed, and thus we avoid updating jump
> label branches.
>
> However, in the case that rcuperf is enabled, it will call
> kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
> (which is > SYSTEM_RUNNING), potentially before the the initcalls have
> even been run. In this case, the jump label selftests called from __init
> via a late_initcall() can not update the branch direction, and thus we
> get the above warnings (due to the fact that the branches don't get
> udpated).
>
> So this is really not a new issue and really is only triggered in a
> debug setup, so I don't think this is 4.14 material in any way...
>
> One way to clean this up is to add a call into the jump label code
> similar to what ftrace does in ftrace_free_init_mem(). This gets called
> after the initcalls have run but before they are freed. Something like
> below.
Alternatively, rcuperf (and rcutorture and locktorture) could refused
to power off the system until the system state reaches SYSTEM_RUNNING.
That said, I am quite happy to have it fixed elsewhere. ;-)
Thanx, Paul
> Thanks,
>
> -Jason
>
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 3b7675b..0202c58 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
> jump_entry *entry,
> extern void arch_jump_label_transform_static(struct jump_entry *entry,
> enum jump_label_type type);
> extern int jump_label_text_reserved(void *start, void *end);
> +extern void jump_label_invalidate_init(struct module *mod);
> extern void static_key_slow_inc(struct static_key *key);
> extern void static_key_slow_dec(struct static_key *key);
> extern void jump_label_apply_nops(struct module *mod);
> @@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
> module *mod)
> return 0;
> }
>
> +static inline void jump_label_invalidate_init(struct module *mod) {}
> +
> static inline void static_key_enable(struct static_key *key)
> {
> STATIC_KEY_CHECK_USE();
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 4b484ab..23e3cba 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -471,6 +471,7 @@ extern unsigned long long memparse(const char *ptr,
> char **retptr);
> extern bool parse_option_str(const char *str, const char *option);
> extern char *next_arg(char *args, char **param, char **val);
>
> +extern int init_kernel_text(unsigned long addr);
> extern int core_kernel_text(unsigned long addr);
> extern int core_kernel_data(unsigned long addr);
> extern int __kernel_text_address(unsigned long addr);
> diff --git a/init/main.c b/init/main.c
> index 0ee9c686..f4e5ab5 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -994,6 +994,7 @@ static int __ref kernel_init(void *unused)
> /* need to finish all async __init code before freeing the memory */
> async_synchronize_full();
> ftrace_free_init_mem();
> + jump_label_invalidate_init(NULL);
> free_initmem();
> mark_readonly();
> system_state
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> > On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
> >>
> >>
> >> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> >>> Hello,
> >>>
> >>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
> >>>
> >>
> >> Hi,
> >>
> >> So this looks like the branches aren't getting updated because the
> >> WARN_ON()s are all from the second half of the test loop (where we
> >> actually change the branch direction).
> >>
> >> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
> >> was not able to trigger the WARN_ON(). Do you know if it happens on
> >> every boot or if there is some boot timing involved?
> >>
> >> You could try the patch below, to start to narrow down if this is a
> >> problem with jump table setup or with the update process.
> >
> > The problem disappears after this patch.
> >
>
> Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
> something like the following to the command-line: "rcuperf.shutdown=1
> rcuperf.holdoff=2".
Just to be clear, this combination of parameters says to start the test
-after- shutting down the system, which should not be expected to do
anything useful.
> The issue is that the core jump label code uses kernel_text_address() to
> ensure that it does not update branches in '__init' text after it has
> been freed. The check uses 'system_state' variable from
> core_kernel_text() to make the determination:
>
> if (system_state < SYSTEM_RUNNING &&
>
> init_kernel_text(addr))
>
> return 1;
>
> return 0;
>
> So the general idea is that system_state is set to SYSTEM_RUNNING after
> the __init text sections are freed, and thus we avoid updating jump
> label branches.
>
> However, in the case that rcuperf is enabled, it will call
> kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
> (which is > SYSTEM_RUNNING), potentially before the the initcalls have
> even been run. In this case, the jump label selftests called from __init
> via a late_initcall() can not update the branch direction, and thus we
> get the above warnings (due to the fact that the branches don't get
> udpated).
>
> So this is really not a new issue and really is only triggered in a
> debug setup, so I don't think this is 4.14 material in any way...
>
> One way to clean this up is to add a call into the jump label code
> similar to what ftrace does in ftrace_free_init_mem(). This gets called
> after the initcalls have run but before they are freed. Something like
> below.
Alternatively, rcuperf (and rcutorture and locktorture) could refused
to power off the system until the system state reaches SYSTEM_RUNNING.
That said, I am quite happy to have it fixed elsewhere. ;-)
Thanx, Paul
> Thanks,
>
> -Jason
>
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 3b7675b..0202c58 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
> jump_entry *entry,
> extern void arch_jump_label_transform_static(struct jump_entry *entry,
> enum jump_label_type type);
> extern int jump_label_text_reserved(void *start, void *end);
> +extern void jump_label_invalidate_init(struct module *mod);
> extern void static_key_slow_inc(struct static_key *key);
> extern void static_key_slow_dec(struct static_key *key);
> extern void jump_label_apply_nops(struct module *mod);
> @@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
> module *mod)
> return 0;
> }
>
> +static inline void jump_label_invalidate_init(struct module *mod) {}
> +
> static inline void static_key_enable(struct static_key *key)
> {
> STATIC_KEY_CHECK_USE();
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 4b484ab..23e3cba 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -471,6 +471,7 @@ extern unsigned long long memparse(const char *ptr,
> char **retptr);
> extern bool parse_option_str(const char *str, const char *option);
> extern char *next_arg(char *args, char **param, char **val);
>
> +extern int init_kernel_text(unsigned long addr);
> extern int core_kernel_text(unsigned long addr);
> extern int core_kernel_data(unsigned long addr);
> extern int __kernel_text_address(unsigned long addr);
> diff --git a/init/main.c b/init/main.c
> index 0ee9c686..f4e5ab5 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -994,6 +994,7 @@ static int __ref kernel_init(void *unused)
> /* need to finish all async __init code before freeing the memory */
> async_synchronize_full();
> ftrace_free_init_mem();
> + jump_label_invalidate_init(NULL);
> free_initmem();
> mark_readonly();
> system_state
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>>
>>
>> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
>>> Hello,
>>>
>>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>>>
>>
>> Hi,
>>
>> So this looks like the branches aren't getting updated because the
>> WARN_ON()s are all from the second half of the test loop (where we
>> actually change the branch direction).
>>
>> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
>> was not able to trigger the WARN_ON(). Do you know if it happens on
>> every boot or if there is some boot timing involved?
>>
>> You could try the patch below, to start to narrow down if this is a
>> problem with jump table setup or with the update process.
>
> The problem disappears after this patch.
>
Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
something like the following to the command-line: "rcuperf.shutdown=1
rcuperf.holdoff=2".
The issue is that the core jump label code uses kernel_text_address() to
ensure that it does not update branches in '__init' text after it has
been freed. The check uses 'system_state' variable from
core_kernel_text() to make the determination:
if (system_state < SYSTEM_RUNNING &&
init_kernel_text(addr))
return 1;
return 0;
So the general idea is that system_state is set to SYSTEM_RUNNING after
the __init text sections are freed, and thus we avoid updating jump
label branches.
However, in the case that rcuperf is enabled, it will call
kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
(which is > SYSTEM_RUNNING), potentially before the the initcalls have
even been run. In this case, the jump label selftests called from __init
via a late_initcall() can not update the branch direction, and thus we
get the above warnings (due to the fact that the branches don't get
udpated).
So this is really not a new issue and really is only triggered in a
debug setup, so I don't think this is 4.14 material in any way...
One way to clean this up is to add a call into the jump label code
similar to what ftrace does in ftrace_free_init_mem(). This gets called
after the initcalls have run but before they are freed. Something like
below.
Thanks,
-Jason
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 3b7675b..0202c58 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
jump_entry *entry,
extern void arch_jump_label_transform_static(struct jump_entry *entry,
enum jump_label_type type);
extern int jump_label_text_reserved(void *start, void *end);
+extern void jump_label_invalidate_init(struct module *mod);
extern void static_key_slow_inc(struct static_key *key);
extern void static_key_slow_dec(struct static_key *key);
extern void jump_label_apply_nops(struct module *mod);
@@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
module *mod)
return 0;
}
+static inline void jump_label_invalidate_init(struct module *mod) {}
+
static inline void static_key_enable(struct static_key *key)
{
STATIC_KEY_CHECK_USE();
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4b484ab..23e3cba 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -471,6 +471,7 @@ extern unsigned long long memparse(const char *ptr,
char **retptr);
extern bool parse_option_str(const char *str, const char *option);
extern char *next_arg(char *args, char **param, char **val);
+extern int init_kernel_text(unsigned long addr);
extern int core_kernel_text(unsigned long addr);
extern int core_kernel_data(unsigned long addr);
extern int __kernel_text_address(unsigned long addr);
diff --git a/init/main.c b/init/main.c
index 0ee9c686..f4e5ab5 100644
--- a/init/main.c
+++ b/init/main.c
@@ -994,6 +994,7 @@ static int __ref kernel_init(void *unused)
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
ftrace_free_init_mem();
+ jump_label_invalidate_init(NULL);
free_initmem();
mark_readonly();
system_state = SYSTEM_RUNNING;
diff --git a/kernel/extable.c b/kernel/extable.c
index 9aa1cc4..1d69178 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -62,7 +62,7 @@ const struct exception_table_entry
*search_exception_tables(unsigned long addr)
return e;
}
-static inline int init_kernel_text(unsigned long addr)
+int init_kernel_text(unsigned long addr)
{
if (addr >= (unsigned long)_sinittext &&
addr < (unsigned long)_einittext)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 0bf2e8f5..3f804f4 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -359,16 +359,44 @@ static void __jump_label_update(struct static_key
*key,
struct
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>>
>>
>> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
>>> Hello,
>>>
>>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>>>
>>
>> Hi,
>>
>> So this looks like the branches aren't getting updated because the
>> WARN_ON()s are all from the second half of the test loop (where we
>> actually change the branch direction).
>>
>> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
>> was not able to trigger the WARN_ON(). Do you know if it happens on
>> every boot or if there is some boot timing involved?
>>
>> You could try the patch below, to start to narrow down if this is a
>> problem with jump table setup or with the update process.
>
> The problem disappears after this patch.
>
Ok, I can reproduce the issue if I enable CONFIG_RCU_PERF_TEST and add
something like the following to the command-line: "rcuperf.shutdown=1
rcuperf.holdoff=2".
The issue is that the core jump label code uses kernel_text_address() to
ensure that it does not update branches in '__init' text after it has
been freed. The check uses 'system_state' variable from
core_kernel_text() to make the determination:
if (system_state < SYSTEM_RUNNING &&
init_kernel_text(addr))
return 1;
return 0;
So the general idea is that system_state is set to SYSTEM_RUNNING after
the __init text sections are freed, and thus we avoid updating jump
label branches.
However, in the case that rcuperf is enabled, it will call
kernel_power_off() which in turn sets system_state to SYSTEM_POWER_OFF
(which is > SYSTEM_RUNNING), potentially before the the initcalls have
even been run. In this case, the jump label selftests called from __init
via a late_initcall() can not update the branch direction, and thus we
get the above warnings (due to the fact that the branches don't get
udpated).
So this is really not a new issue and really is only triggered in a
debug setup, so I don't think this is 4.14 material in any way...
One way to clean this up is to add a call into the jump label code
similar to what ftrace does in ftrace_free_init_mem(). This gets called
after the initcalls have run but before they are freed. Something like
below.
Thanks,
-Jason
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 3b7675b..0202c58 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -158,6 +158,7 @@ extern void arch_jump_label_transform(struct
jump_entry *entry,
extern void arch_jump_label_transform_static(struct jump_entry *entry,
enum jump_label_type type);
extern int jump_label_text_reserved(void *start, void *end);
+extern void jump_label_invalidate_init(struct module *mod);
extern void static_key_slow_inc(struct static_key *key);
extern void static_key_slow_dec(struct static_key *key);
extern void jump_label_apply_nops(struct module *mod);
@@ -235,6 +236,8 @@ static inline int jump_label_apply_nops(struct
module *mod)
return 0;
}
+static inline void jump_label_invalidate_init(struct module *mod) {}
+
static inline void static_key_enable(struct static_key *key)
{
STATIC_KEY_CHECK_USE();
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4b484ab..23e3cba 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -471,6 +471,7 @@ extern unsigned long long memparse(const char *ptr,
char **retptr);
extern bool parse_option_str(const char *str, const char *option);
extern char *next_arg(char *args, char **param, char **val);
+extern int init_kernel_text(unsigned long addr);
extern int core_kernel_text(unsigned long addr);
extern int core_kernel_data(unsigned long addr);
extern int __kernel_text_address(unsigned long addr);
diff --git a/init/main.c b/init/main.c
index 0ee9c686..f4e5ab5 100644
--- a/init/main.c
+++ b/init/main.c
@@ -994,6 +994,7 @@ static int __ref kernel_init(void *unused)
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
ftrace_free_init_mem();
+ jump_label_invalidate_init(NULL);
free_initmem();
mark_readonly();
system_state = SYSTEM_RUNNING;
diff --git a/kernel/extable.c b/kernel/extable.c
index 9aa1cc4..1d69178 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -62,7 +62,7 @@ const struct exception_table_entry
*search_exception_tables(unsigned long addr)
return e;
}
-static inline int init_kernel_text(unsigned long addr)
+int init_kernel_text(unsigned long addr)
{
if (addr >= (unsigned long)_sinittext &&
addr < (unsigned long)_einittext)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 0bf2e8f5..3f804f4 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -359,16 +359,44 @@ static void __jump_label_update(struct static_key
*key,
struct
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/08/2017 02:01 AM, Fengguang Wu wrote: > On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote: >> >> >> On 11/07/2017 04:27 AM, Fengguang Wu wrote: >>> Hello, >>> >>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. >>> >> >> Hi, >> >> So this looks like the branches aren't getting updated because the >> WARN_ON()s are all from the second half of the test loop (where we >> actually change the branch direction). >> >> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and >> was not able to trigger the WARN_ON(). Do you know if it happens on >> every boot or if there is some boot timing involved? >> >> You could try the patch below, to start to narrow down if this is a >> problem with jump table setup or with the update process. > > The problem disappears after this patch. > Ok, fun :) With the original kernel that is problematic does the issue occur on every boot? It would be helpful, if you had a pointer to the original 'vmlinux' file that is problematic? Thanks, -Jason > The dmesg is now: > > [ 7.342618] IRQ10 -> 0:10 > [ 7.343025] IRQ11 -> 0:11 > [ 7.343450] IRQ12 -> 0:12 > [ 7.343770] IRQ13 -> 0:13 > [ 7.344079] IRQ14 -> 0:14 > [ 7.344379] IRQ15 -> 0:15 > [ 7.344690] done. > [ 7.345271] Using IPI Shortcut mode > [ 7.345682] sched_clock: Marking stable (7344687295, 0)->(7595176493, > -250489198) > [ 7.346516] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b30, > target: 0xcca65b40 > [ 7.347600] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65999, > target: 0xcca659b8 > [ 7.349195] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65c50, > target: 0xcca65c9a > [ 7.350075] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65bf0, > target: 0xcca65bf8 > [ 7.350963] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b90, > target: 0xcca65b98 > [ 7.351848] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b68, > target: 0xcca65b63 > [ 7.353000] jump_label: disable sk_true: cd2adc60 > [ 7.353668] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.354852] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.356021] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.357023] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, > target: 0xcd31ae8f > [ 7.357970] jump_label: enable sk_false: cda8ef5c > [ 7.358682] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, > target: 0xcd31ae4d > [ 7.359858] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, > target: 0xcd31ae96 > [ 7.361049] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, > target: 0xcd31aea1 > [ 7.362235] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, > target: 0xcd31ade5 > [ 7.363408] jump_label: enable sk_true: cd2adc60 > [ 7.364100] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.365282] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.366465] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.367639] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, > target: 0xcd31ae8f > [ 7.368818] jump_label: disable sk_false: cda8ef5c > [ 7.369538] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, > target: 0xcd31ae4d > [ 7.370716] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, > target: 0xcd31ae96 > [ 7.371900] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, > target: 0xcd31aea1 > [ 7.373087] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, > target: 0xcd31ade5 > [ 7.374275] jump_label: disable sk_true: cd2adc60 > [ 7.374991] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.376175] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.377368] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.378565] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, > target: 0xcd31ae8f > [ 7.379750] jump_label: enable sk_false: cda8ef5c > [ 7.380459] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, > target: 0xcd31ae4d > [ 7.381654] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, > target: 0xcd31ae96 > [ 7.382855] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, > target: 0xcd31aea1 > [ 7.384046] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, > target: 0xcd31ade5 > [ 7.385243] jump_label: enable sk_true: cd2adc60 > [ 7.385944] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.387109] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.388276] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.389449] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2,
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/08/2017 02:01 AM, Fengguang Wu wrote: > On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote: >> >> >> On 11/07/2017 04:27 AM, Fengguang Wu wrote: >>> Hello, >>> >>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. >>> >> >> Hi, >> >> So this looks like the branches aren't getting updated because the >> WARN_ON()s are all from the second half of the test loop (where we >> actually change the branch direction). >> >> I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and >> was not able to trigger the WARN_ON(). Do you know if it happens on >> every boot or if there is some boot timing involved? >> >> You could try the patch below, to start to narrow down if this is a >> problem with jump table setup or with the update process. > > The problem disappears after this patch. > Ok, fun :) With the original kernel that is problematic does the issue occur on every boot? It would be helpful, if you had a pointer to the original 'vmlinux' file that is problematic? Thanks, -Jason > The dmesg is now: > > [ 7.342618] IRQ10 -> 0:10 > [ 7.343025] IRQ11 -> 0:11 > [ 7.343450] IRQ12 -> 0:12 > [ 7.343770] IRQ13 -> 0:13 > [ 7.344079] IRQ14 -> 0:14 > [ 7.344379] IRQ15 -> 0:15 > [ 7.344690] done. > [ 7.345271] Using IPI Shortcut mode > [ 7.345682] sched_clock: Marking stable (7344687295, 0)->(7595176493, > -250489198) > [ 7.346516] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b30, > target: 0xcca65b40 > [ 7.347600] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65999, > target: 0xcca659b8 > [ 7.349195] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65c50, > target: 0xcca65c9a > [ 7.350075] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65bf0, > target: 0xcca65bf8 > [ 7.350963] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b90, > target: 0xcca65b98 > [ 7.351848] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b68, > target: 0xcca65b63 > [ 7.353000] jump_label: disable sk_true: cd2adc60 > [ 7.353668] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.354852] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.356021] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.357023] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, > target: 0xcd31ae8f > [ 7.357970] jump_label: enable sk_false: cda8ef5c > [ 7.358682] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, > target: 0xcd31ae4d > [ 7.359858] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, > target: 0xcd31ae96 > [ 7.361049] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, > target: 0xcd31aea1 > [ 7.362235] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, > target: 0xcd31ade5 > [ 7.363408] jump_label: enable sk_true: cd2adc60 > [ 7.364100] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.365282] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.366465] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.367639] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, > target: 0xcd31ae8f > [ 7.368818] jump_label: disable sk_false: cda8ef5c > [ 7.369538] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, > target: 0xcd31ae4d > [ 7.370716] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, > target: 0xcd31ae96 > [ 7.371900] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, > target: 0xcd31aea1 > [ 7.373087] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, > target: 0xcd31ade5 > [ 7.374275] jump_label: disable sk_true: cd2adc60 > [ 7.374991] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.376175] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.377368] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.378565] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, > target: 0xcd31ae8f > [ 7.379750] jump_label: enable sk_false: cda8ef5c > [ 7.380459] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, > target: 0xcd31ae4d > [ 7.381654] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, > target: 0xcd31ae96 > [ 7.382855] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, > target: 0xcd31aea1 > [ 7.384046] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, > target: 0xcd31ade5 > [ 7.385243] jump_label: enable sk_true: cd2adc60 > [ 7.385944] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, > target: 0xcd31ae9d > [ 7.387109] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, > target: 0xcd31adde > [ 7.388276] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, > target: 0xcd31ae3c > [ 7.389449] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2,
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote: On 11/07/2017 04:27 AM, Fengguang Wu wrote: Hello, FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. Hi, So this looks like the branches aren't getting updated because the WARN_ON()s are all from the second half of the test loop (where we actually change the branch direction). I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and was not able to trigger the WARN_ON(). Do you know if it happens on every boot or if there is some boot timing involved? You could try the patch below, to start to narrow down if this is a problem with jump table setup or with the update process. The problem disappears after this patch. The dmesg is now: [7.342618] IRQ10 -> 0:10 [7.343025] IRQ11 -> 0:11 [7.343450] IRQ12 -> 0:12 [7.343770] IRQ13 -> 0:13 [7.344079] IRQ14 -> 0:14 [7.344379] IRQ15 -> 0:15 [7.344690] done. [7.345271] Using IPI Shortcut mode [7.345682] sched_clock: Marking stable (7344687295, 0)->(7595176493, -250489198) [7.346516] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b30, target: 0xcca65b40 [7.347600] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65999, target: 0xcca659b8 [7.349195] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65c50, target: 0xcca65c9a [7.350075] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65bf0, target: 0xcca65bf8 [7.350963] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b90, target: 0xcca65b98 [7.351848] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b68, target: 0xcca65b63 [7.353000] jump_label: disable sk_true: cd2adc60 [7.353668] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.354852] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.356021] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.357023] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.357970] jump_label: enable sk_false: cda8ef5c [7.358682] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.359858] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.361049] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.362235] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [7.363408] jump_label: enable sk_true: cd2adc60 [7.364100] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.365282] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.366465] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.367639] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.368818] jump_label: disable sk_false: cda8ef5c [7.369538] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.370716] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.371900] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.373087] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [7.374275] jump_label: disable sk_true: cd2adc60 [7.374991] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.376175] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.377368] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.378565] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.379750] jump_label: enable sk_false: cda8ef5c [7.380459] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.381654] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.382855] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.384046] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [7.385243] jump_label: enable sk_true: cd2adc60 [7.385944] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.387109] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.388276] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.389449] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.390621] jump_label: disable sk_false: cda8ef5c [7.391337] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.392509] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.393973] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.395025] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote: On 11/07/2017 04:27 AM, Fengguang Wu wrote: Hello, FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. Hi, So this looks like the branches aren't getting updated because the WARN_ON()s are all from the second half of the test loop (where we actually change the branch direction). I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and was not able to trigger the WARN_ON(). Do you know if it happens on every boot or if there is some boot timing involved? You could try the patch below, to start to narrow down if this is a problem with jump table setup or with the update process. The problem disappears after this patch. The dmesg is now: [7.342618] IRQ10 -> 0:10 [7.343025] IRQ11 -> 0:11 [7.343450] IRQ12 -> 0:12 [7.343770] IRQ13 -> 0:13 [7.344079] IRQ14 -> 0:14 [7.344379] IRQ15 -> 0:15 [7.344690] done. [7.345271] Using IPI Shortcut mode [7.345682] sched_clock: Marking stable (7344687295, 0)->(7595176493, -250489198) [7.346516] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b30, target: 0xcca65b40 [7.347600] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65999, target: 0xcca659b8 [7.349195] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65c50, target: 0xcca65c9a [7.350075] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65bf0, target: 0xcca65bf8 [7.350963] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b90, target: 0xcca65b98 [7.351848] __jump_label_update: key: 0xcd3a0dec, code: 0xcca65b68, target: 0xcca65b63 [7.353000] jump_label: disable sk_true: cd2adc60 [7.353668] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.354852] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.356021] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.357023] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.357970] jump_label: enable sk_false: cda8ef5c [7.358682] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.359858] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.361049] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.362235] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [7.363408] jump_label: enable sk_true: cd2adc60 [7.364100] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.365282] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.366465] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.367639] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.368818] jump_label: disable sk_false: cda8ef5c [7.369538] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.370716] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.371900] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.373087] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [7.374275] jump_label: disable sk_true: cd2adc60 [7.374991] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.376175] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.377368] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.378565] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.379750] jump_label: enable sk_false: cda8ef5c [7.380459] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.381654] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.382855] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.384046] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [7.385243] jump_label: enable sk_true: cd2adc60 [7.385944] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae3c, target: 0xcd31ae9d [7.387109] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add7, target: 0xcd31adde [7.388276] __jump_label_update: key: 0xcd2adc60, code: 0xcd31ae35, target: 0xcd31ae3c [7.389449] __jump_label_update: key: 0xcd2adc60, code: 0xcd31add2, target: 0xcd31ae8f [7.390621] jump_label: disable sk_false: cda8ef5c [7.391337] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae46, target: 0xcd31ae4d [7.392509] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ade5, target: 0xcd31ae96 [7.393973] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31ae41, target: 0xcd31aea1 [7.395025] __jump_label_update: key: 0xcda8ef5c, code: 0xcd31adde, target: 0xcd31ade5 [
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>
Hi,
So this looks like the branches aren't getting updated because the
WARN_ON()s are all from the second half of the test loop (where we
actually change the branch direction).
I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
was not able to trigger the WARN_ON(). Do you know if it happens on
every boot or if there is some boot timing involved?
You could try the patch below, to start to narrow down if this is a
problem with jump table setup or with the update process.
Thanks,
-Jason
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 0bf2e8f5..433cc94 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -364,8 +364,13 @@ static void __jump_label_update(struct static_key *key,
* kernel_text_address() verifies we are not in core kernel
* init code, see jump_label_invalidate_module_init().
*/
- if (entry->code && kernel_text_address(entry->code))
+ if (entry->code && kernel_text_address(entry->code)) {
+ printk("%s: key: 0x%lx, code: 0x%lx, target:
0x%lx\n",
+ __func__, (unsigned
long)jump_entry_key(entry),
+ (unsigned long)entry->code,
+ (unsigned long)entry->target);
arch_jump_label_transform(entry,
jump_label_type(entry));
+ }
}
}
@@ -752,7 +757,9 @@ static __init int jump_label_test(void)
WARN_ON(static_branch_likely(_false));
WARN_ON(static_branch_unlikely(_false));
+ printk("jump_label: disable sk_true: %p\n", _true);
static_branch_disable(_true);
+ printk("jump_label: enable sk_false: %p\n", _false);
static_branch_enable(_false);
WARN_ON(static_key_enabled(_true.key) == true);
@@ -763,7 +770,9 @@ static __init int jump_label_test(void)
WARN_ON(!static_branch_likely(_false));
WARN_ON(!static_branch_unlikely(_false));
+ printk("jump_label: enable sk_true: %p\n", _true);
static_branch_enable(_true);
+ printk("jump_label: disable sk_false: %p\n", _false);
static_branch_disable(_false);
}
> [ 15.214834] IRQ15 -> 0:15
> [ 15.214834] done.
> [ 15.214834] Using IPI Shortcut mode
> [ 15.214834] sched_clock: Marking stable (15210834346, 0)->(15797181340,
> -586346994)
> [ 17.667168] [ cut here ]
> [ 17.668895] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761
> jump_label_test+0x63/0xab
> [ 17.672346] Modules linked in:
> [ 17.673475] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.0-rc8 #29
> [ 17.675724] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 17.678755] task: c0020d00 task.stack: c0022000
> [ 17.680423] EIP: jump_label_test+0x63/0xab
> [ 17.681912] EFLAGS: 00210202 CPU: 0
> [ 17.683206] EAX: 0001 EBX: 0002 ECX: 0004 EDX:
> [ 17.685501] ESI: c9918db6 EDI: EBP: ESP: c0023f40
> [ 17.687787] DS: 007b ES: 007b FS: GS: SS: 0068
> [ 17.689748] CR0: 80050033 CR2: CR3: 09991000 CR4: 06b0
> [ 17.692019] Call Trace:
> [ 17.692938] ? do_one_initcall+0x2c/0x13a
> [ 17.694398] ? parse_args+0x1af/0x300
> [ 17.695740] ? kernel_init_freeable+0xce/0x161
> [ 17.697370] ? kernel_init_freeable+0xee/0x161
> [ 17.698986] ? rest_init+0xb0/0xb0
> [ 17.700236] ? kernel_init+0x5/0xe0
> [ 17.701513] ? ret_from_fork+0x19/0x30
> [ 17.702876] Code: c9 e8 3c 59 7b ff b8 5c cf 08 ca e8 a2 58 7b ff a1 60 bc
> 8a c9 85 c0 74 02 0f ff a1 5c cf 08 ca 85 c0 75 02 0f ff 3e 8d 74 26 00 <0f>
> ff e9 35 00 00 00 e9 34 00 00 00 3e 8d 74 26 00 0f ff b8 60
> [ 17.709721] ---[ end trace f18711bfa2b1114e ]---
> [ 17.711418] [ cut here ]
> [ 17.711418] [ cut here ]
> [ 17.713092] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:762
> jump_label_test+0x9f/0xab
> [ 17.716534] Modules linked in:
> [ 17.717665] CPU: 0 PID: 1 Comm: swapper Tainted: GW
> 4.14.0-rc8 #29
> [ 17.720349] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 17.723362] task: c0020d00 task.stack: c0022000
> [ 17.725004] EIP: jump_label_test+0x9f/0xab
> [ 17.726516] EFLAGS: 00210202 CPU: 0
> [ 17.727785] EAX: 0001 EBX: 0002 ECX: 0004 EDX:
> [ 17.730058] ESI: c9918db6 EDI: EBP: ESP: c0023f40
> [ 17.732341] DS: 007b ES: 007b FS: GS: SS: 0068
> [ 17.734300] CR0: 80050033 CR2: CR3: 09991000 CR4: 06b0
> [ 17.736560] Call Trace:
> [ 17.737476] ?
Re: [jump_label_test] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761 jump_label_test+0x63/0xab
On 11/07/2017 04:27 AM, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>
Hi,
So this looks like the branches aren't getting updated because the
WARN_ON()s are all from the second half of the test loop (where we
actually change the branch direction).
I ran a kernel with a very similar .config on qemu-kvm/i386 as well, and
was not able to trigger the WARN_ON(). Do you know if it happens on
every boot or if there is some boot timing involved?
You could try the patch below, to start to narrow down if this is a
problem with jump table setup or with the update process.
Thanks,
-Jason
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 0bf2e8f5..433cc94 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -364,8 +364,13 @@ static void __jump_label_update(struct static_key *key,
* kernel_text_address() verifies we are not in core kernel
* init code, see jump_label_invalidate_module_init().
*/
- if (entry->code && kernel_text_address(entry->code))
+ if (entry->code && kernel_text_address(entry->code)) {
+ printk("%s: key: 0x%lx, code: 0x%lx, target:
0x%lx\n",
+ __func__, (unsigned
long)jump_entry_key(entry),
+ (unsigned long)entry->code,
+ (unsigned long)entry->target);
arch_jump_label_transform(entry,
jump_label_type(entry));
+ }
}
}
@@ -752,7 +757,9 @@ static __init int jump_label_test(void)
WARN_ON(static_branch_likely(_false));
WARN_ON(static_branch_unlikely(_false));
+ printk("jump_label: disable sk_true: %p\n", _true);
static_branch_disable(_true);
+ printk("jump_label: enable sk_false: %p\n", _false);
static_branch_enable(_false);
WARN_ON(static_key_enabled(_true.key) == true);
@@ -763,7 +770,9 @@ static __init int jump_label_test(void)
WARN_ON(!static_branch_likely(_false));
WARN_ON(!static_branch_unlikely(_false));
+ printk("jump_label: enable sk_true: %p\n", _true);
static_branch_enable(_true);
+ printk("jump_label: disable sk_false: %p\n", _false);
static_branch_disable(_false);
}
> [ 15.214834] IRQ15 -> 0:15
> [ 15.214834] done.
> [ 15.214834] Using IPI Shortcut mode
> [ 15.214834] sched_clock: Marking stable (15210834346, 0)->(15797181340,
> -586346994)
> [ 17.667168] [ cut here ]
> [ 17.668895] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:761
> jump_label_test+0x63/0xab
> [ 17.672346] Modules linked in:
> [ 17.673475] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.0-rc8 #29
> [ 17.675724] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 17.678755] task: c0020d00 task.stack: c0022000
> [ 17.680423] EIP: jump_label_test+0x63/0xab
> [ 17.681912] EFLAGS: 00210202 CPU: 0
> [ 17.683206] EAX: 0001 EBX: 0002 ECX: 0004 EDX:
> [ 17.685501] ESI: c9918db6 EDI: EBP: ESP: c0023f40
> [ 17.687787] DS: 007b ES: 007b FS: GS: SS: 0068
> [ 17.689748] CR0: 80050033 CR2: CR3: 09991000 CR4: 06b0
> [ 17.692019] Call Trace:
> [ 17.692938] ? do_one_initcall+0x2c/0x13a
> [ 17.694398] ? parse_args+0x1af/0x300
> [ 17.695740] ? kernel_init_freeable+0xce/0x161
> [ 17.697370] ? kernel_init_freeable+0xee/0x161
> [ 17.698986] ? rest_init+0xb0/0xb0
> [ 17.700236] ? kernel_init+0x5/0xe0
> [ 17.701513] ? ret_from_fork+0x19/0x30
> [ 17.702876] Code: c9 e8 3c 59 7b ff b8 5c cf 08 ca e8 a2 58 7b ff a1 60 bc
> 8a c9 85 c0 74 02 0f ff a1 5c cf 08 ca 85 c0 75 02 0f ff 3e 8d 74 26 00 <0f>
> ff e9 35 00 00 00 e9 34 00 00 00 3e 8d 74 26 00 0f ff b8 60
> [ 17.709721] ---[ end trace f18711bfa2b1114e ]---
> [ 17.711418] [ cut here ]
> [ 17.711418] [ cut here ]
> [ 17.713092] WARNING: CPU: 0 PID: 1 at kernel/jump_label.c:762
> jump_label_test+0x9f/0xab
> [ 17.716534] Modules linked in:
> [ 17.717665] CPU: 0 PID: 1 Comm: swapper Tainted: GW
> 4.14.0-rc8 #29
> [ 17.720349] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 17.723362] task: c0020d00 task.stack: c0022000
> [ 17.725004] EIP: jump_label_test+0x9f/0xab
> [ 17.726516] EFLAGS: 00210202 CPU: 0
> [ 17.727785] EAX: 0001 EBX: 0002 ECX: 0004 EDX:
> [ 17.730058] ESI: c9918db6 EDI: EBP: ESP: c0023f40
> [ 17.732341] DS: 007b ES: 007b FS: GS: SS: 0068
> [ 17.734300] CR0: 80050033 CR2: CR3: 09991000 CR4: 06b0
> [ 17.736560] Call Trace:
> [ 17.737476] ?
