Re: [RFC PATCH] workqueue: introduce WORK_STRUCT_TIMER_PENDING_BIT.

[imran . f . khan]

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@xxxxxxxxxx>
>> ---
>> 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.
>