introduce __cancel_delayed_work()
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 patch 3 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/1 | introduce __cancel_delayed_work()include/ | +15 | 3 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/1] introduce __cancel_delayed_work()
Quoted 11 lines · Roland Dreier
Quoted 11 lines
OK, in this case I think we have a simple solution,
// like cancel_delayed_work, but uses del_timer(). // this means, if it returns 0 the timer function may be // running and the queueing is in progress. The caller // can't rely on flush_workqueue/etc static inline int __cancel_delayed_work(struct delayed_work *work) { int ret;
Quoted 8 lines
Quoted 5 lines
ret = del_timer(&work->timer); if (ret) work_clear_pending(&work->work); return ret; }This looks like it would work well. If we can get this into 2.6.32 then I will drop my patch and switch to this approach instead.
I am not sure how can I push this patch into 2.6.32, so I am just sending it to Andrew.
Or. Please feel free to embed this change in mad.c fixes and send the patch yourself (if it is not too late, I have to apologize for delay again).
As for requeue, perhaps we should add two helpers. The first is simple,
if (!mod_timer_pending(dwork->timer, new_delay)) queue_delayed_work(dwork, new_delay);
and I think this is what we need for mad.c. Another one is not "atomic" but also cancells dwork. But this we we can't decide what exactly these helpers should do, it is "safer" to add the trivial __cancel_delayed_work() which hopefully can have other users.
Oleg.