Hello, Oleg. Sorry about the delay. On Mon, Feb 25, 2019 at 04:57:25PM +0100, Oleg Nesterov wrote: > > As long as the task is > > guaranteed to be trapped by signal stop afterwards (and they are), we > > likely can use them the same way. The only thing to be careful about > > would be ensuring that we don't end up flipping group level frozen > > state inbetween. Would something like that work? > > I have no idea because I do not understand what exactly do you mean ;) Heh, sorry about that. What I meant was that we can consider a task which is blocked in vfork wait as already frozen and that if we do so we need to be careful so that frozen state doesn't do a flip between vfork wait ending and the task getting parked again in a jobctl stop. > However. Thinking more about this, I am not sure my concerns were valid. > Yes, cg freezer can "hang" if it races with vfork(). But probably we should > blame vfork(), not freezer. I think we'd need to cover that ground regardless of where blame lies. It's weird if freezing doesn't complete cuz one of the tasks messed up while vforking. > The problem is, even ^Z can "hang" if the foreground process does vfork() > and the new child stops before exit/exec. Now I recall that I even tried > to make a patch to fix this using ERESTART_RESTARTBLOCK, but had some nasty > problems with blocked signals... Ugh... yeah, these wait non-interruptible wait sites which can be exposed to userspace are nasty. They end up adding a unique wait state visible to userspace which comes with a bunch of corner cases. > de_thread() should use freezable_schedule() in TASK_KILLABLE too. Currently > it doesn't, but only because we have other (much more serious) problems with > cred_guard_mutex/exec. However, this is is fine wrt cg freezer, other threads > can't be frozen exactly because it is killable. > > Anything else does freezer_do_not_count() in TASK_KILLABLE and waits for > another freezable process? Can't find any. Hopefully, that was it? > So it seems I have to take my words back, perhaps we can forget about > freezable_schedule/etc. I think it'd be great to be able to handle these if at all possible. Thanks. -- tejun
