2020-08-12 05:18:12

by qianli zhao

[permalink] [raw]
Subject: [RFC V2] kthread: add object debug support

From: Qianli Zhao <[email protected]>

Add debugobject support to track the life time of kthread_work
which is used to detect reinitialization/free active object problems
Add kthread_init_work_onstack/kthread_init_delayed_work_onstack for
kthread onstack support

Signed-off-by: Qianli Zhao <[email protected]>
---
I got an crash issue since kthread_delayed_work reinitialization,crash log show us that is a timer NULL pointer exception
[16238.089921] Unable to handle kernel paging request at virtual address dead000000000208
[16238.090298] Call trace:
[16238.090307] run_timer_softirq+0x2d0/0xa30
[16238.090318] __do_softirq+0x1dc/0x384
[16238.090328] irq_exit+0xb4/0xb8
[16238.090338] __handle_domain_irq+0x84/0xc0
[16238.090345] gic_handle_irq+0x138/0x1bc
[16238.090353] el1_irq+0xb0/0x128
[16238.090362] queue_work_on+0x54/0x60
[16238.090374] _process_event_group+0x190/0x230
[16238.090382] kgsl_process_event_groups+0x44/0x70
[16238.090391] adreno_dispatcher_work+0x1e4/0xae8
[16238.090400] kthread_worker_fn+0xec/0x180
[16238.090407] kthread+0x118/0x128
[16238.090415] ret_from_fork+0x10/0x18

It turns out that the problem is caused by the timer reinitialization,after enable CONFIG_DEBUG_OBJECTS_TIMERS,the reason for the problem is obvious.

This timer belongs to kthread_delayed_work,from kernel log we also see list corruption WARNING:
[30858.395766] list_del corruption. next->prev should be ffffffe388ebbf88, but was ffffffe388ebb588
[30858.395788] WARNING: CPU: 2 PID: 387 at /home/work/data/miui_codes/build_home/kernel/msm-4.19/lib/list_debug.c:56 __list_del_entry_valid+0xc8/0xd0
...
[30858.405951] list_add corruption. next->prev should be prev (ffffffe389392620), but was ffffffe388ebbf88. (next=ffffffe388ebbf88).
[30858.405977] WARNING: CPU: 0 PID: 7721 at /home/work/data/miui_codes/build_home/kernel/msm-4.19/lib/list_debug.c:25 __list_add_valid+0x7c/0xc8

crash> struct kthread_worker.delayed_work_list 0xffffffe3893925f0
[ffffffe389392620] delayed_work_list = {
next = 0xffffffe388ebbf88,
prev = 0xffffffe388ebb588
}
crash> list 0xffffffe388ebbf88
ffffffe388ebbf88

delayed_work_list is corruption,this work is reinitialized.if kthread_work reinitialized after move to work_list,this work will be carried out forever in kthread_worker_fn.

Timer and workqueue both provide debugobject support,kthread_work similar with workqueue,so i think it is necessary to support objectdebug in kthread_work.

---
include/linux/kthread.h | 29 ++++++++++++++-
include/linux/poison.h | 3 ++
kernel/kthread.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++-
lib/Kconfig.debug | 10 ++++++
4 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 65b81e0..1530953 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -108,6 +108,16 @@ struct kthread_delayed_work {
struct timer_list timer;
};

+#ifdef CONFIG_DEBUG_OBJECTS_KTHREAD
+extern void __init_kwork(struct kthread_work *kwork, int onstack);
+extern void destroy_kwork_on_stack(struct kthread_work *kwork);
+extern void destroy_delayed_kwork_on_stack(struct kthread_delayed_work *kdwork);
+#else
+static inline void __init_kwork(struct kthread_work *kwork, int onstack) { }
+static inline void destroy_kwork_on_stack(struct kthread_work *kwork) { }
+static inline void destroy_delayed_kwork_on_stack(struct kthread_delayed_work *kdwork) { }
+#endif
+
#define KTHREAD_WORKER_INIT(worker) { \
.lock = __RAW_SPIN_LOCK_UNLOCKED((worker).lock), \
.work_list = LIST_HEAD_INIT((worker).work_list), \
@@ -115,7 +125,7 @@ struct kthread_delayed_work {
}

#define KTHREAD_WORK_INIT(work, fn) { \
- .node = LIST_HEAD_INIT((work).node), \
+ .node = { .next = KWORK_ENTRY_STATIC }, \
.func = (fn), \
}

@@ -160,6 +170,15 @@ extern void __kthread_init_worker(struct kthread_worker *worker,
#define kthread_init_work(work, fn) \
do { \
memset((work), 0, sizeof(struct kthread_work)); \
+ __init_kwork(work, 0); \
+ INIT_LIST_HEAD(&(work)->node); \
+ (work)->func = (fn); \
+ } while (0)
+
+#define kthread_init_work_onstack(work, fn) \
+ do { \
+ memset((work), 0, sizeof(struct kthread_work)); \
+ __init_kwork(work, 1); \
INIT_LIST_HEAD(&(work)->node); \
(work)->func = (fn); \
} while (0)
@@ -172,6 +191,14 @@ extern void __kthread_init_worker(struct kthread_worker *worker,
TIMER_IRQSAFE); \
} while (0)

+#define kthread_init_delayed_work_onstack(dwork, fn) \
+ do { \
+ kthread_init_work_onstack(&(dwork)->work, (fn)); \
+ __init_timer_on_stack(&(dwork)->timer, \
+ kthread_delayed_work_timer_fn, \
+ TIMER_IRQSAFE); \
+ } while (0)
+
int kthread_worker_fn(void *worker_ptr);

__printf(2, 3)
diff --git a/include/linux/poison.h b/include/linux/poison.h
index df34330..2e6a370 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -86,4 +86,7 @@
/********** security/ **********/
#define KEY_DESTROY 0xbd

+/********** kernel/kthread **********/
+#define KWORK_ENTRY_STATIC ((void *) 0x600 + POISON_POINTER_DELTA)
+
#endif
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 132f84a..ca00bd2 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -67,6 +67,94 @@ enum KTHREAD_BITS {
KTHREAD_SHOULD_PARK,
};

+#ifdef CONFIG_DEBUG_OBJECTS_KTHREAD
+static struct debug_obj_descr kwork_debug_descr;
+
+static void *kwork_debug_hint(void *addr)
+{
+ return ((struct kthread_work *) addr)->func;
+}
+
+static bool kwork_is_static_object(void *addr)
+{
+ struct kthread_work *kwork = addr;
+
+ return (kwork->node.prev == NULL &&
+ kwork->node.next == KWORK_ENTRY_STATIC);
+}
+
+static bool kwork_fixup_init(void *addr, enum debug_obj_state state)
+{
+ struct kthread_work *kwork = addr;
+
+ switch (state) {
+ case ODEBUG_STATE_ACTIVE:
+ kthread_cancel_work_sync(kwork);
+ debug_object_init(kwork, &kwork_debug_descr);
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool kwork_fixup_free(void *addr, enum debug_obj_state state)
+{
+ struct kthread_work *kwork = addr;
+
+ switch (state) {
+ case ODEBUG_STATE_ACTIVE:
+ kthread_cancel_work_sync(kwork);
+ debug_object_free(kwork, &kwork_debug_descr);
+ return true;
+ default:
+ return false;
+ }
+}
+
+static struct debug_obj_descr kwork_debug_descr = {
+ .name = "kthread_work",
+ .debug_hint = kwork_debug_hint,
+ .is_static_object = kwork_is_static_object,
+ .fixup_init = kwork_fixup_init,
+ .fixup_free = kwork_fixup_free,
+};
+
+static inline void debug_kwork_activate(struct kthread_work *kwork)
+{
+ debug_object_activate(kwork, &kwork_debug_descr);
+}
+
+static inline void debug_kwork_deactivate(struct kthread_work *kwork)
+{
+ debug_object_deactivate(kwork, &kwork_debug_descr);
+}
+
+void __init_kwork(struct kthread_work *kwork, int onstack)
+{
+ if (onstack)
+ debug_object_init_on_stack(kwork, &kwork_debug_descr);
+ else
+ debug_object_init(kwork, &kwork_debug_descr);
+}
+EXPORT_SYMBOL_GPL(__init_kwork);
+
+void destroy_kwork_on_stack(struct kthread_work *kwork)
+{
+ debug_object_free(kwork, &kwork_debug_descr);
+}
+EXPORT_SYMBOL_GPL(destroy_kwork_on_stack);
+
+void destroy_delayed_kwork_on_stack(struct kthread_delayed_work *kdwork)
+{
+ destroy_timer_on_stack(&kdwork->timer);
+ debug_object_free(&kdwork->work, &kwork_debug_descr);
+}
+EXPORT_SYMBOL_GPL(destroy_delayed_kwork_on_stack);
+#else
+static inline void debug_kwork_activate(struct kthread_work *kwork) { }
+static inline void debug_kwork_deactivate(struct kthread_work *kwork) { }
+#endif
+
static inline void set_kthread_struct(void *kthread)
{
/*
@@ -698,6 +786,7 @@ int kthread_worker_fn(void *worker_ptr)
work = list_first_entry(&worker->work_list,
struct kthread_work, node);
list_del_init(&work->node);
+ debug_kwork_deactivate(work);
}
worker->current_work = work;
raw_spin_unlock_irq(&worker->lock);
@@ -835,8 +924,11 @@ static void kthread_insert_work(struct kthread_worker *worker,

list_add_tail(&work->node, pos);
work->worker = worker;
- if (!worker->current_work && likely(worker->task))
+
+ if (!worker->current_work && likely(worker->task)) {
+ debug_kwork_activate(work);
wake_up_process(worker->task);
+ }
}

/**
@@ -1054,6 +1146,7 @@ static bool __kthread_cancel_work(struct kthread_work *work, bool is_dwork,
*/
if (!list_empty(&work->node)) {
list_del_init(&work->node);
+ debug_kwork_deactivate(work);
return true;
}

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210..8355984 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -540,6 +540,16 @@ config DEBUG_OBJECTS_WORK
work queue routines to track the life time of work objects and
validate the work operations.

+config DEBUG_OBJECTS_KTHREAD
+ bool "Debug kthread work objects"
+ depends on DEBUG_OBJECTS
+ help
+ If you say Y here, additional code will be inserted into the
+ kthread routines to track the life time of kthread objects and
+ validate the kthread operations.
+
+ If unsure, say N.
+
config DEBUG_OBJECTS_RCU_HEAD
bool "Debug RCU callbacks objects"
depends on DEBUG_OBJECTS
--
2.7.4


2020-08-12 08:35:14

by Stephen Boyd

[permalink] [raw]
Subject: Re: [RFC V2] kthread: add object debug support

Quoting Qianli Zhao (2020-08-11 22:14:14)
> @@ -115,7 +125,7 @@ struct kthread_delayed_work {
> }
>
> #define KTHREAD_WORK_INIT(work, fn) { \
> - .node = LIST_HEAD_INIT((work).node), \
> + .node = { .next = KWORK_ENTRY_STATIC }, \
> .func = (fn), \
> }
>
> diff --git a/include/linux/poison.h b/include/linux/poison.h
> index df34330..2e6a370 100644
> --- a/include/linux/poison.h
> +++ b/include/linux/poison.h
> @@ -86,4 +86,7 @@
> /********** security/ **********/
> #define KEY_DESTROY 0xbd
>
> +/********** kernel/kthread **********/
> +#define KWORK_ENTRY_STATIC ((void *) 0x600 + POISON_POINTER_DELTA)

Is this related to the debugobjects change here? It looks like another
version of list poison.

> +
> #endif
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 132f84a..ca00bd2 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -698,6 +786,7 @@ int kthread_worker_fn(void *worker_ptr)
> work = list_first_entry(&worker->work_list,
> struct kthread_work, node);
> list_del_init(&work->node);
> + debug_kwork_deactivate(work);

Shouldn't this come before the list operation so that any sort of fix
can be made before possibly corrupting a list?

> }
> worker->current_work = work;
> raw_spin_unlock_irq(&worker->lock);
> @@ -835,8 +924,11 @@ static void kthread_insert_work(struct kthread_worker *worker,
>
> list_add_tail(&work->node, pos);
> work->worker = worker;
> - if (!worker->current_work && likely(worker->task))
> +
> + if (!worker->current_work && likely(worker->task)) {
> + debug_kwork_activate(work);
> wake_up_process(worker->task);
> + }
> }
>
> /**
> @@ -1054,6 +1146,7 @@ static bool __kthread_cancel_work(struct kthread_work *work, bool is_dwork,
> */
> if (!list_empty(&work->node)) {
> list_del_init(&work->node);
> + debug_kwork_deactivate(work);

Same comment.

> return true;
> }

2020-08-12 10:12:07

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [RFC V2] kthread: add object debug support

Qianli,

Qianli Zhao <[email protected]> writes:

> Add debugobject support to track the life time of kthread_work
> which is used to detect reinitialization/free active object problems
> Add kthread_init_work_onstack/kthread_init_delayed_work_onstack for
> kthread onstack support

s/kthread/kthread_work/ ?

It would also be nice to have an example output in the changelog.

> +static struct debug_obj_descr kwork_debug_descr = {
> + .name = "kthread_work",
> + .debug_hint = kwork_debug_hint,
> + .is_static_object = kwork_is_static_object,

Nitpick. You nicely aligned all the initializers except of this
one. Just add another TAB to all of them and this becomes a perfect
table.

> + .fixup_init = kwork_fixup_init,
> + .fixup_free = kwork_fixup_free,

This lacks:

.fixup_assert_init = ....

which catches cases where a non static object is used uninitialized.

> @@ -698,6 +786,7 @@ int kthread_worker_fn(void *worker_ptr)
> work = list_first_entry(&worker->work_list,
> struct kthread_work, node);
> list_del_init(&work->node);
> + debug_kwork_deactivate(work);

Please move that before the list del. Deactivate debug cannot do much
about the wreckage as there is no fixup function, but at least you get
the message printed _before_ the list delete can cause havoc and crashes
something else on a different CPU which makes the whole point of being
able to debug this kind of problems moot.

> @@ -835,8 +924,11 @@ static void kthread_insert_work(struct kthread_worker *worker,
>
> list_add_tail(&work->node, pos);
> work->worker = worker;
> - if (!worker->current_work && likely(worker->task))
> +
> + if (!worker->current_work && likely(worker->task)) {
> + debug_kwork_activate(work);

That's misplaced as well. The work is activated with list_add_tail() and
you really want to call debug_kwork_activate() unconditionally before
doing the list operation:

1) If the object is active or not initialized then the list operation
will cause memory corruption and the fixup function will operate on
already wreckaged state. Debug objects is about preventing the
wreckaged state and keeping the system alive so the debug info goes
out.

2) If the worker is busy (worker->current_worker != NULL) then the
newly queued work is not activated in the debug object tracker and
the deactivation will complain or a consequent free of the object
will fail to detect that it's still active.

> /**
> @@ -1054,6 +1146,7 @@ static bool __kthread_cancel_work(struct kthread_work *work, bool is_dwork,
> */
> if (!list_empty(&work->node)) {
> list_del_init(&work->node);
> + debug_kwork_deactivate(work);

See above.

> return true;
> }
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 9ad9210..8355984 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -540,6 +540,16 @@ config DEBUG_OBJECTS_WORK
> work queue routines to track the life time of work objects and
> validate the work operations.
>
> +config DEBUG_OBJECTS_KTHREAD
> + bool "Debug kthread work objects"

This is about debugging kthread_work, so can you please name the
config option accordingly? It's not about debugging KTHREAD itself.

Thanks,

tglx

2020-08-12 10:30:36

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [RFC V2] kthread: add object debug support

Stephen,

Stephen Boyd <[email protected]> writes:
> Quoting Qianli Zhao (2020-08-11 22:14:14)
>> +/********** kernel/kthread **********/
>> +#define KWORK_ENTRY_STATIC ((void *) 0x600 + POISON_POINTER_DELTA)
>
> Is this related to the debugobjects change here? It looks like another
> version of list poison.

Yes, it is. We use these poison entries to mark statically allocated
objects. debug objects does not know about statically initialized
objects up to the point where they are used (activated).

That means the object state lookup will fail which causes debugobjects
to complain about using an uninitialized object. But in case of static
initialized ones that's a false positive. So we mark these objects in
their list head (or some other appropriate place) with a poison value
and in case of a failed lookup debug object does:

if (descr->is_static_object && descr->is_static_object(addr)) {
/* track this static object */
debug_object_init(addr, descr);
debug_object_activate(addr, descr);
}

The object specific is_static_object() callback will then check for the
magic list poison value being present:

> +static bool kwork_is_static_object(void *addr)
> +{
> + struct kthread_work *kwork = addr;
> +
> + return (kwork->node.prev == NULL &&
> + kwork->node.next == KWORK_ENTRY_STATIC);
> +}

and if so the debug object core fixes its internal state by creating a
tracking object and then activating it.

It's not a perfect "yes this is statically initialized" check but good
enough. If you go and do:

work = kzalloc(sizeof(*work);
work->node.next = KWORK_ENTRY_STATIC;

kthread_insert_work(worker, work);

or any other variant of insanity which makes the check claim that this
is statically initialized then you rightfully can keep the pieces :)

>> diff --git a/kernel/kthread.c b/kernel/kthread.c
>> index 132f84a..ca00bd2 100644
>> --- a/kernel/kthread.c
>> +++ b/kernel/kthread.c
>> @@ -698,6 +786,7 @@ int kthread_worker_fn(void *worker_ptr)
>> work = list_first_entry(&worker->work_list,
>> struct kthread_work, node);
>> list_del_init(&work->node);
>> + debug_kwork_deactivate(work);
>
> Shouldn't this come before the list operation so that any sort of fix
> can be made before possibly corrupting a list?

Yes.

>> }
>> worker->current_work = work;
>> raw_spin_unlock_irq(&worker->lock);
>> @@ -835,8 +924,11 @@ static void kthread_insert_work(struct kthread_worker *worker,
>>
>> list_add_tail(&work->node, pos);
>> work->worker = worker;
>> - if (!worker->current_work && likely(worker->task))
>> +
>> + if (!worker->current_work && likely(worker->task)) {
>> + debug_kwork_activate(work);

You missed this one as I explained to Qianli already. It's way worse
than the other two.

Thanks,

tglx

2020-08-15 22:14:30

by Stephen Boyd

[permalink] [raw]
Subject: Re: [RFC V2] kthread: add object debug support

Quoting Thomas Gleixner (2020-08-12 03:27:03)
> Stephen,
>
> Stephen Boyd <[email protected]> writes:
> > Quoting Qianli Zhao (2020-08-11 22:14:14)
> >> +/********** kernel/kthread **********/
> >> +#define KWORK_ENTRY_STATIC ((void *) 0x600 + POISON_POINTER_DELTA)
> >
> > Is this related to the debugobjects change here? It looks like another
> > version of list poison.
>
> Yes, it is. We use these poison entries to mark statically allocated
> objects. debug objects does not know about statically initialized
> objects up to the point where they are used (activated).
>
> That means the object state lookup will fail which causes debugobjects
> to complain about using an uninitialized object. But in case of static
> initialized ones that's a false positive. So we mark these objects in
> their list head (or some other appropriate place) with a poison value
> and in case of a failed lookup debug object does:
>
> if (descr->is_static_object && descr->is_static_object(addr)) {
> /* track this static object */
> debug_object_init(addr, descr);
> debug_object_activate(addr, descr);
> }
>
> The object specific is_static_object() callback will then check for the
> magic list poison value being present:

Thanks! I missed this function below.

>
> > +static bool kwork_is_static_object(void *addr)
> > +{
> > + struct kthread_work *kwork = addr;
> > +
> > + return (kwork->node.prev == NULL &&
> > + kwork->node.next == KWORK_ENTRY_STATIC);
> > +}
>
> and if so the debug object core fixes its internal state by creating a
> tracking object and then activating it.
>
> It's not a perfect "yes this is statically initialized" check but good
> enough. If you go and do:
>
> work = kzalloc(sizeof(*work);
> work->node.next = KWORK_ENTRY_STATIC;
>
> kthread_insert_work(worker, work);
>
> or any other variant of insanity which makes the check claim that this
> is statically initialized then you rightfully can keep the pieces :)

Makes sense. Maybe this "technique" should be documented in
Documentation/core-api/debug-objects.rst? I can cook up a patch to add
is_static_object() to the Fixup functions section.

2020-08-16 19:39:33

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [RFC V2] kthread: add object debug support

On Sat, Aug 15 2020 at 01:37, Stephen Boyd wrote:
> Quoting Thomas Gleixner (2020-08-12 03:27:03)
>> or any other variant of insanity which makes the check claim that this
>> is statically initialized then you rightfully can keep the pieces :)
>
> Makes sense. Maybe this "technique" should be documented in
> Documentation/core-api/debug-objects.rst? I can cook up a patch to add
> is_static_object() to the Fixup functions section.

Sure. Better documentation is always a good thing.

Thanks,

tglx

2020-08-20 08:12:35

by Chen, Rong A

[permalink] [raw]
Subject: [kthread] 2e7d8748eb: last_state.is_incomplete_run

Greeting,

FYI, we noticed the following commit (built with gcc-9):

commit: 2e7d8748eba7e32150cbd4f57129ea77d1255892 ("[RFC V2] kthread: add object debug support")
url: https://github.com/0day-ci/linux/commits/Qianli-Zhao/kthread-add-object-debug-support/20200812-131719
base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git fb893de323e2d39f7a1f6df425703a2edbdf56ea

in testcase: boot

on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G memory

caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):



kernel boot failed by kexec:

user :notice: [ +0.371313] LKP: kexec loading...
user :notice: [ +0.007118] kexec --noefi -l /opt/rootfs/tmp/pkg/linux/x86_64-rhel-8.3/gcc-9/2e7d8748eba7e32150cbd4f57129ea77d1255892/vmlinuz-5.8.0-12610-g2e7d8748eba7e --initrd=/opt/rootfs/tmp/initrd-concatenated




Thanks,
Rong Chen


Attachments:
(No filename) (949.00 B)
config-5.8.0-12610-g2e7d8748eba7e (161.41 kB)
job-script (5.44 kB)
pre-dmesg.gz (24.23 kB)
Download all attachments

2020-08-27 03:52:04

by qianli zhao

[permalink] [raw]
Subject: Re: [kthread] 2e7d8748eb: last_state.is_incomplete_run

I did not see any exceptions related to my changes,the corresponding
macro CONFIG_DEBUG_OBJECTS_KTHREAD is not enabled,so i think the issue
has nothing to do with my changes

Thanks

On Thu, 20 Aug 2020 at 14:26, kernel test robot <[email protected]> wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 2e7d8748eba7e32150cbd4f57129ea77d1255892 ("[RFC V2] kthread: add object debug support")
> url: https://github.com/0day-ci/linux/commits/Qianli-Zhao/kthread-add-object-debug-support/20200812-131719
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git fb893de323e2d39f7a1f6df425703a2edbdf56ea
>
> in testcase: boot
>
> on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
>
> kernel boot failed by kexec:
>
> user :notice: [32m[ +0.371313] [0m [33mLKP [0m: kexec loading...
> user :notice: [32m[ +0.007118] [0mkexec --noefi -l /opt/rootfs/tmp/pkg/linux/x86_64-rhel-8.3/gcc-9/2e7d8748eba7e32150cbd4f57129ea77d1255892/vmlinuz-5.8.0-12610-g2e7d8748eba7e --initrd=/opt/rootfs/tmp/initrd-concatenated
>
>
>
>
> Thanks,
> Rong Chen
>

2020-09-02 07:54:52

by Chen, Rong A

[permalink] [raw]
Subject: Re: [kthread] 2e7d8748eb: last_state.is_incomplete_run

Thanks for the input, we do detect this on this commit but not its parent.
It may be merged into a wrong base branch or something else that
we are not aware of. And it's kind difficulty now for us to provide a
reproduction step for kexec issue, we will consider this further.

Best Regards,
Rong Chen


On 8/27/2020 11:49 AM, qianli zhao wrote:
> I did not see any exceptions related to my changes,the corresponding
> macro CONFIG_DEBUG_OBJECTS_KTHREAD is not enabled,so i think the issue
> has nothing to do with my changes
>
> Thanks
>
> On Thu, 20 Aug 2020 at 14:26, kernel test robot <[email protected]> wrote:
>> Greeting,
>>
>> FYI, we noticed the following commit (built with gcc-9):
>>
>> commit: 2e7d8748eba7e32150cbd4f57129ea77d1255892 ("[RFC V2] kthread: add object debug support")
>> url: https://github.com/0day-ci/linux/commits/Qianli-Zhao/kthread-add-object-debug-support/20200812-131719
>> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git fb893de323e2d39f7a1f6df425703a2edbdf56ea
>>
>> in testcase: boot
>>
>> on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G memory
>>
>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>>
>>
>>
>> kernel boot failed by kexec:
>>
>> user :notice: [32m[ +0.371313] [0m [33mLKP [0m: kexec loading...
>> user :notice: [32m[ +0.007118] [0mkexec --noefi -l /opt/rootfs/tmp/pkg/linux/x86_64-rhel-8.3/gcc-9/2e7d8748eba7e32150cbd4f57129ea77d1255892/vmlinuz-5.8.0-12610-g2e7d8748eba7e --initrd=/opt/rootfs/tmp/initrd-concatenated
>>
>>
>>
>>
>> Thanks,
>> Rong Chen
>>