On Thu, 2 May 2013, Tejun Heo wrote: > Combined with the locking problems, I was planning to update the > freezer such that the frozen state is implemented as a form of jobctl > stop, so that things like ptrace / kill -9 could work on them and we > also have the clear definition of the frozen state rather than the > current "it may get stuck somewhere in the kernel". > > But that conflicts with what you're doing here which seems pretty > useful, so, to satisfy both goals, when somebody needs to put a > pseudo-frozen task into the actual frozen jobctl stop, those spots > which are currently using try_to_stop() would have to return an error, > most likely -EINTR with TIF_SIGPENDING set, and the control should > return towards userland so that signal handling path can be invoked. > ie. It should be possible to steer the tasks which are considered > frozen but not in the frozen jobctl stop into the jobctl stop without > any side effect. To do that, those spots basically have to be pretty > close to the userland boundary where it can easily leave the kernel > with -EINTR and AFAICS all the spots that you converted are like that > (which I think is natural). While not holding any locks doesn't > guarantee that, I think there'd be a fairly high correlation at least > and it'd be able to drive people towards finding out what's going on.
Don't forget about freezable kernel threads. They never cross the kernel/user boundary. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
