lkml.org 
[lkml]   [2007]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Fw: [PATCH -mm] workqueue: debug possible endless loop in cancel_rearming_delayed_work
    On Thu, Apr 19, 2007 at 02:21:22PM +0400, Oleg Nesterov wrote:
    > On 04/19, Andrew Morton wrote:
    > >
    > > Begin forwarded message:
    > >
    > > Date: Thu, 19 Apr 2007 08:54:04 +0200
    > > From: Jarek Poplawski <jarkao2@o2.pl>
    > > To: linux-kernel@vger.kernel.org
    > > Cc: Ingo Molnar <mingo@elte.hu>
    > > Subject: [PATCH -mm] workqueue: debug possible endless loop in cancel_rearming_delayed_work

    At first I didn't spotted your thread is "independent" and
    from your second message it seems you didn't receive all, you
    expected. I wonder, if there is a need and possibility to add
    somewhere (I would prefer Linus' tree git's http frontend)
    addresses of developers (but not maintainers), who are
    interested in CC-ing about some files' patches?.

    ...
    > Yes. It would be better to use cancel_work_sync() instead of flush_workqueue()
    > to make this less possible (because cancel_work_sync() doesn't need to wait for
    > the whole ->worklist), but we can't.
    >
    > > Maybe this patch could check, if I'm not dreaming...
    >
    > Also: cancel_rearming_delayed_work() will hang if it (or cancel_delayed_work())
    > was already called.
    >
    > I had some ideas how to make this interface reliable, but I can't see how to do
    > this without uglification of the current code.

    For some time I thought about using a flag (isn't there
    one available after NOAUTOREL?), e.g. WORK_STRUCT_CANCEL,
    as a sign:

    - for a workqueue code: that the work shouldn't be queued,
    nor executed, if possiblei, at first possible check.

    - for a work function: to stop execution as soon as possible,
    even without completing the usual job, at first possible check.

    There would be a question, whether the flag should be changed
    under a lock for exact synchronisation.

    Cheers,
    Jarek P.

    PS: I hope there is no reason against going with this to lkml
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-20 11:19    [W:0.022 / U:1.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site