lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL1PR11MB54783384845A2BCFEE305DA1FF089@BL1PR11MB5478.namprd11.prod.outlook.com>
Date:   Wed, 23 Jun 2021 05:34:15 +0000
From:   "Zhang, Qiang" <Qiang.Zhang@...driver.com>
To:     Lai Jiangshan <jiangshanlai@...il.com>
CC:     Tejun Heo <tj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] workqueue: set the rescuer worker that belong to
 freezable wq is freezable



________________________________________
From: Lai Jiangshan <jiangshanlai@...il.com>
Sent: Wednesday, 23 June 2021 11:16
To: Zhang, Qiang
Cc: Tejun Heo; Andrew Morton; LKML
Subject: Re: [PATCH v2] workqueue: set the rescuer worker that belong to freezable wq is freezable

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Tue, Jun 22, 2021 at 8:42 PM <qiang.zhang@...driver.com> wrote:
>
> From: Zqiang <qiang.zhang@...driver.com>
>
> If the rescuer worker belong to freezable wq, when this wq is
> frozen, the rescuer worker also need to be frozen.

>Hello,
>
>>From my understanding, the wq subsystem doesn't use >set_freezable(),
>try_to_freeze() families.  For example, the worker_thread() >doesn't
>use set_freezable(), neither do in your patch. If kthreads
>in the wq subsystem need these functions, please let us know.
>
>The way the wq subsystem to freeze tasks is by >freeze_workqueues_begin()
>and thaw_workqueues().  When WQs is requested for freezing,
>they will stop activating work items.  All the workers including
>*rescuers* will be scheduled as TASK_IDLE when all the >activated work
>items are processed and the whole wq subsystem is frozen >unless
>there is any semantic change about TASK_IDLE V.S. "frozen".
>(rescuers can also only process activated work items.)

Hello Lai
My understanding is this:
when the freeze_workqueues_begin() be called, this only set pwq->max_active is zero,   it's just to prevent, after that when we queue the work again, we will put it in the pwq->delayed_works,
but if  there are still some work in the pool->worklist,  the workers in pool are still handle work items, and the rescuer work may be also handle work items,  until the work items is processed, the workers enters TASK_IDLE status.   the rescuer worker is independent of workerpools , when the system freezing,   freeze the rescuer worker directly without waiting for all workitems to be processed.

Thanks
Qiang







>
>Thanks
>Lai

>
> Signed-off-by: Zqiang <qiang.zhang@...driver.com>
> ---
>  v1->v2:
>  use kthread_freezable_should_stop() replaces try_to_freeze().
>
>  kernel/workqueue.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 104e3ef04e33..dd7b78bdb7f1 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -2476,6 +2476,9 @@ static int rescuer_thread(void *__rescuer)
>          * doesn't participate in concurrency management.
>          */
>         set_pf_worker(true);
> +
> +       if (wq->flags & WQ_FREEZABLE)
> +               set_freezable();
>  repeat:
>         set_current_state(TASK_IDLE);
>
> @@ -2487,7 +2490,7 @@ static int rescuer_thread(void *__rescuer)
>          * @wq->maydays processing before acting on should_stop so that the
>          * list is always empty on exit.
>          */
> -       should_stop = kthread_should_stop();
> +       should_stop = kthread_freezable_should_stop(NULL);
>
>         /* see whether any pwq is asking for help */
>         raw_spin_lock_irq(&wq_mayday_lock);
> --
> 2.25.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ