On Mon, Nov 21, 2011 at 10:43:16AM -0800, Tejun Heo wrote: > Commit 981ed70d8e (dmatest: make dmatest threads freezable) made > dmatest kthread use set_freezable_with_signal(); however, the > interface is scheduled to be removed in the next merge window. > > The problem is that unlike userland tasks there's no default place > which handles signal pending state and it isn't clear who owns and/or > is responsible for clearing TIF_SIGPENDING. For example, in the > current code, try_to_freeze() clears TIF_SIGPENDING but it isn't sure > whether it actually owns the TIF_SIGPENDING nor is it race-free - > ie. the task may continue to run with TIF_SIGPENDING set after the > freezable section. > > Unfortunately, we don't have wait_for_completion_freezable_timeout(). > This patch open codes it and uses wait_event_freezable_timeout() > instead and removes timeout reloading - wait_event_freezable_timeout() > won't return across freezing events (currently racy but fix scheduled) > and timer doesn't decrement while the task is in freezer. Although > this does lose timer-reset-over-freezing, given that timeout is > supposed to be long enough and failure to finish inside is considered > irrecoverable, I don't think this is worth the complexity. > > While at it, move completion to outer scope and explain that we're > ignoring dangling pointer problem after timeout. This should give > slightly better chance at avoiding oops after timeout. > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> > Cc: Guennadi Liakhovetski <g.liakhovetski@xxxxxx> > Cc: Dan Williams <dan.j.williams@xxxxxxxxx> > Cc: Nicolas Ferre <nicolas.ferre@xxxxxxxxx> > --- > Guennadi, Dan, how does this look? If it's okay, do you guys mind > routing this through pm tree? I have some patches stacked on top > removal of freezable_with_signal and it would be much easier to route > these together. Ooh, forgot to mention that it's only compile tested. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
