Messages in this thread | | | Date | Fri, 3 May 2013 10:18:17 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [PATCH v2 03/10] freezer: add new freezable helpers using freezer_do_not_count() |
| |
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
| |