Messages in this thread | | | Subject | Re: [PATCH 2/2] kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed | From | Andy Walls <> | Date | Tue, 24 Jul 2012 07:17:45 -0400 |
| |
On Mon, 2012-07-23 at 10:12 -0700, Tejun Heo wrote: > Hello, > > On Sun, Jul 22, 2012 at 04:46:54PM -0400, Andy Walls wrote: > > Hmmm, I didn't know about the constraint about 'known to be alive' in > > the other email I just sent. > > > > That might make calling flush_kthread_work() hard for a user to use, if > > the user lets the work get freed by another thread executing the work. > > Umm... flushing a freed work item doesn't make any sense at all. The > pointer itself loses the ability to identify anything. What if it > gets recycled to another work item which happens to depend on the > flusher to make forward progress? You now have a circular dependency > through a recycled memory area. Good luck hunting that down. > > For pretty much any API, allowing dangling pointers as argument is > insane. If you want to flush self-freeing work items, flush the > kthread_worker. That's how it is with workqueue and how it should be > with kthread_worker too.
Hi,
Ah. My problem was that I mentally assigned the wrong rationale for why you reworked flush_kthread_work().
Thank you for your patience and explanations. Sorry for the noise.
For patch 2/2:
Reviewed-by: Andy Walls <awalls@md.metrocast.net>
Regards, Andy
| |