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 <[EMAIL PROTECTED]> > > To: linux-kernel@vger.kernel.org > > Cc: Ingo Molnar <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/