linux-kernel - Re: [RFC PATCH] workqueue: introduce WORK_STRUCT_TIMER_PENDING

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] [day] [month] [year] [list]

Message-ID: <61b68035-4f8d-431b-9561-96716ef9ac79@oracle.com>
Date: Mon, 6 Jan 2025 13:07:25 +1100
From: imran.f.khan@...cle.com
To: Tejun Heo <tj@...nel.org>
Cc: jiangshanlai@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] workqueue: introduce WORK_STRUCT_TIMER_PENDING_BIT.

Hello Tejun,
Thanks a lot for looking into this.
On 4/1/2025 9:18 am, Tejun Heo wrote:
> Hello,
> 
> On Mon, Dec 30, 2024 at 05:45:00PM +1100, Imran Khan wrote:
>> Currently WORK_STRUCT_PENDING_BIT can indicate a work_struct that is
>> already made it to work list of a worker_pool or a work_struct that has
>> not yet made it there because it comes from a delayed_work whose timer
>> has not expired yet.
>>
>> Use WORK_STRUCT_TIMER_PENDING_BIT to distinguish between these two
>> states of work_struct.
>>
>> Signed-off-by: Imran Khan <imran.f.khan@...cle.com>
>> ---
>> I have kept the patch as RFC, because this change is not fixing a bug.
>> It makes WORK_STRUCT_PENDING_BIT less ambiguous and helps in debugging,
>> by indicating where one should look for this pending work.
> 
> But can't you already tell this by looking at the work struct? 

Yes this can also be inferred by looking at pwq information set by insert_work.
If there is some other way, could you please let me know.

But this path (__queue_work->insert_work)is taken for normal works as well and
I thought that having a dedicated bit in the work_struct to indicate that this
work comes from a dwork, whose timer has not yet expired, would make debugging
easier.
Further in cases where dwork is part of another object and there is a possibilty
that some data corruption issue might be messing up the dwork or dwork.work,
we would have an extra piece of information to check against.

I'm not sure
> about adding more atomic ops for redundant information.
> 

I understand your concern if this extra piece of information is not
worth the overhead.

Thanks,
Imran

> Thanks.
>