[lkml]   [2012]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed
    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.


    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 <>


     \ /
      Last update: 2012-07-24 14:01    [W:0.076 / U:38.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site