On Thu, Apr 19, 2007 at 01:07:11PM -0400, Chuck Ebbert wrote: > Jarek Poplawski wrote: > > Hi, > > > > IMHO cancel_rearming_delayed_work is dangerous place: > > > > - it assumes a work function always rearms (with no exception), > > which probably isn't explained enough now (but anyway should > > be checked in such loops); > > > > - probably possible (theoretical) scenario: a few work > > functions rearm themselves with very short, equal times; > > before flush_workqueue ends, their timers are already > > fired, so cancel_delayed_work has nothing to do. > > > > Maybe this patch could check, if I'm not dreaming... > > > > PS: of course the counter value below is a question of taste > > Okay, an easy test for it: insmod netconsole ; rmmod netconsole > > In 2.6.20.x it loops forever and cancel_rearming_delayed_work() > is part of the trace... Sure, but the dreaming test is more needed for the second point - I mean - if it's theoretical only? The first scenario is in my opinion assured logically - there was only a question, whether it could be detected by other means - and it seems not.
Cheers, Jarek P. - 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/