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: <CAJhGHyDEAM4opmhqqkv4Fyqdop3_E0y2hBEdRnCv7xiP6V6Uvg@mail.gmail.com>
Date: Fri, 14 Nov 2025 00:52:06 +0800
From: Lai Jiangshan <jiangshanlai@...il.com>
To: linux-kernel@...r.kernel.org
Cc: Lai Jiangshan <jiangshan.ljs@...group.com>, ying chen <yc1082463@...il.com>, 
	Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] workqueue: Process rescuer work items one-by-one using a
 positional marker

Hello

Some extra stuff.

On Fri, Nov 14, 2025 at 12:30 AM Lai Jiangshan <jiangshanlai@...il.com> wrote:

> @@ -286,6 +286,7 @@ struct pool_workqueue {
>         struct list_head        pending_node;   /* LN: node on wq_node_nr_active->pending_pwqs */
>         struct list_head        pwqs_node;      /* WR: node on wq->pwqs */
>         struct list_head        mayday_node;    /* MD: node on wq->maydays */
> +       struct work_struct      mayday_pos_work;/* L: position on pool->worklist */

pwq->mayday_pos_work, pwq->release_work and pwq->rcu can be made to share
the same memory.  It will be done in a later cleanup patch.

> +static void insert_mayday_pos(struct pool_workqueue *pwq, struct work_struct *next)
> +{
> +       unsigned int work_flags;
> +       unsigned int work_color;
> +
> +       __set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(&pwq->mayday_pos_work));
> +
> +       /* The mayday positional work item does not participate in nr_active. */
> +       work_flags = WORK_STRUCT_INACTIVE;
> +       work_color = pwq->work_color;

I thought quite a while about the color for INACTIVE, I think the color doesn't
make sense as long as the color is "eligible", so pwq->work_color is used here
rather than inheriting from an associated one even though I can easily get the
associated one for this special positional work item.

And I think struct wq_barrier can also use pwq->work_color, and the common
code in multiple places can be moved into insert_work() which results in
much simpler code.

It will be done in a later cleanup patch.

> +       work_flags |= work_color_to_flags(work_color);
> +       pwq->nr_in_flight[work_color]++;
> +       insert_work(pwq, &pwq->mayday_pos_work, &next->entry, work_flags);
> +}
> +

Thanks
Lai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ