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

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

[qiang.zhang]

From: Zhang Qiang <qiang.zhang@windriver.com>

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 <qiang.zhang@windriver.com>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
---
 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

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

[Petr Mladek]

On Mon 2020-07-06 13:46:47, qiang.zhang@windriver.com wrote:
> From: Zhang Qiang <qiang.zhang@windriver.com>
> 
> 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 <qiang.zhang@windriver.com>
> Suggested-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Petr Mladek <pmladek@suse.com>

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 <pmladek@suse.com>

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

回复: [PATCH v4] kthread: Work could not be queued when worker being destroyed

[Zhang, Qiang]

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

________________________________________
发件人: linux-kernel-owner@vger.kernel.org <linux-kernel-owner@vger.kernel.org> 代表 Petr Mladek <pmladek@suse.com>
发送时间: 2020年7月7日 17:06
收件人: Zhang, Qiang
抄送: ben.dooks@codethink.co.uk; bfields@redhat.com; cl@rock-chips.com; peterz@infradead.org; tj@kernel.org; akpm@linux-foundation.org; naresh.kamboju@linaro.org; mm-commits@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: [PATCH v4] kthread: Work could not be queued when worker being destroyed

On Mon 2020-07-06 13:46:47, qiang.zhang@windriver.com wrote:
> From: Zhang Qiang <qiang.zhang@windriver.com>
>
> 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 <qiang.zhang@windriver.com>
> Suggested-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Petr Mladek <pmladek@suse.com>

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 <pmladek@suse.com>

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