2020-07-07 07:34:45

by Zhang, Qiang

[permalink] [raw]
Subject: [PATCH v4] kthread: Work could not be queued when worker being destroyed

From: Zhang Qiang <[email protected]>

Before the work is put into the queue of the worker thread,
the state of the worker thread needs to be detected,because
the worker thread may be in the destruction state at this time.

Signed-off-by: Zhang Qiang <[email protected]>
Suggested-by: Petr Mladek <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
---
v1->v2:
Add warning information for condition "!worker->task".
v2->v3:
Modify submission information and add "Reviewed-by" tags.
v3->v4:
Fix spi controller register trigger Warning.
when a spi controller register, a "kthread_worker_fn" worker is created
through "kthread_run" instead of "kthread_create_worker" which in this
func the "worker->task" will be initialized. and then the "spi_start_queue"
func queue a work to worker queue, at this time, if the worker has not
begin to running, the "!worker->task" will be true, so a warning is triggered.

kernel/kthread.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index bfbfa481be3a..825bd4dcdb95 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -791,6 +791,11 @@ static inline bool queuing_blocked(struct kthread_worker *worker,
{
lockdep_assert_held(&worker->lock);

+ if (kthread_should_stop()) {
+ WARN_ON(1);
+ return true;
+ }
+
return !list_empty(&work->node) || work->canceling;
}

--
2.24.1


2020-07-07 09:09:43

by Petr Mladek

[permalink] [raw]
Subject: Re: [PATCH v4] kthread: Work could not be queued when worker being destroyed

On Mon 2020-07-06 13:46:47, [email protected] wrote:
> From: Zhang Qiang <[email protected]>
>
> Before the work is put into the queue of the worker thread,
> the state of the worker thread needs to be detected,because
> the worker thread may be in the destruction state at this time.
>
> Signed-off-by: Zhang Qiang <[email protected]>
> Suggested-by: Petr Mladek <[email protected]>
> Reviewed-by: Petr Mladek <[email protected]>

This patch is completely different from the one that I suggested
or acked. Please, never keep acks when doing major rework and
people did not agree with it.

For this patch:

Nacked-by: Petr Mladek <[email protected]>

See below why.


> ---
> v1->v2:
> Add warning information for condition "!worker->task".
> v2->v3:
> Modify submission information and add "Reviewed-by" tags.
> v3->v4:
> Fix spi controller register trigger Warning.
> when a spi controller register, a "kthread_worker_fn" worker is created
> through "kthread_run" instead of "kthread_create_worker" which in this
> func the "worker->task" will be initialized. and then the "spi_start_queue"
> func queue a work to worker queue, at this time, if the worker has not
> begin to running, the "!worker->task" will be true, so a warning is triggered.
>
> kernel/kthread.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index bfbfa481be3a..825bd4dcdb95 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -791,6 +791,11 @@ static inline bool queuing_blocked(struct kthread_worker *worker,
> {
> lockdep_assert_held(&worker->lock);
>
> + if (kthread_should_stop()) {

This does not make much sense.

kthread_should_stop() checks a flag set for the "current" process.
It works only when called from inside the kthread worker thread.

queuing_blocked() is called from kthread_queue_work()
or kthread_queue_delayed_work(). These are typically
called from another process. The only exception is when
they get re-queued from inside the work.

Best Regards,
Petr


> + WARN_ON(1);
> + return true;
> + }
> +
> return !list_empty(&work->node) || work->canceling;
> }
>
> --
> 2.24.1

2020-07-07 09:33:57

by Zhang, Qiang

[permalink] [raw]
Subject: 回复: [PATCH v4] kthread: Work could not be q ueued when worker being destroyed

Sorry, Pter Mladek, this is my mistake please ignore this change.

________________________________________
??????: [email protected] <[email protected]> ???? Petr Mladek <[email protected]>
????ʱ??: 2020??7??7?? 17:06
?ռ???: Zhang, Qiang
????: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
????: Re: [PATCH v4] kthread: Work could not be queued when worker being destroyed

On Mon 2020-07-06 13:46:47, [email protected] wrote:
> From: Zhang Qiang <[email protected]>
>
> Before the work is put into the queue of the worker thread,
> the state of the worker thread needs to be detected,because
> the worker thread may be in the destruction state at this time.
>
> Signed-off-by: Zhang Qiang <[email protected]>
> Suggested-by: Petr Mladek <[email protected]>
> Reviewed-by: Petr Mladek <[email protected]>

This patch is completely different from the one that I suggested
or acked. Please, never keep acks when doing major rework and
people did not agree with it.

For this patch:

Nacked-by: Petr Mladek <[email protected]>

See below why.


> ---
> v1->v2:
> Add warning information for condition "!worker->task".
> v2->v3:
> Modify submission information and add "Reviewed-by" tags.
> v3->v4:
> Fix spi controller register trigger Warning.
> when a spi controller register, a "kthread_worker_fn" worker is created
> through "kthread_run" instead of "kthread_create_worker" which in this
> func the "worker->task" will be initialized. and then the "spi_start_queue"
> func queue a work to worker queue, at this time, if the worker has not
> begin to running, the "!worker->task" will be true, so a warning is triggered.
>
> kernel/kthread.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index bfbfa481be3a..825bd4dcdb95 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -791,6 +791,11 @@ static inline bool queuing_blocked(struct kthread_worker *worker,
> {
> lockdep_assert_held(&worker->lock);
>
> + if (kthread_should_stop()) {

This does not make much sense.

kthread_should_stop() checks a flag set for the "current" process.
It works only when called from inside the kthread worker thread.

queuing_blocked() is called from kthread_queue_work()
or kthread_queue_delayed_work(). These are typically
called from another process. The only exception is when
they get re-queued from inside the work.

Best Regards,
Petr


> + WARN_ON(1);
> + return true;
> + }
> +
> return !list_empty(&work->node) || work->canceling;
> }
>
> --
> 2.24.1