Hi, On Tuesday, 5 December 2006 15:12, Pavel Machek wrote: > Hi! > > > > > Actually, what do you think about this patch? It removes special > > > > handling of TASK_TRACED, and should do the trick, too... > > > > > > I was surprised, but the patch seems to work okay. Can you replace > > > your 1/2 with this one, and see what breaks? > > > > I don't think anything will _visibly_ break, because (1) even if the traced > > task has TIF_SIGPENDING set unnecessarily, it will just notice there is no > > real signal to handle and continue and > > We are generating spurious wakeups, but as you noticed, that should be > okay. So we can move the check to freezeable(). Fine. > >(2) the race between the delivery of > > the continuation signal and the freezer is damn hard to trigger (still I think > > I can wirte some artificial code that would trigger this, although it would > > involve a kernel thread sending SIGCONT to a user space process - provided > > it's permissible ;-)). > > It is not really permissible, but I do not see how it would hurt... > > With that patch, we put TASK_STOPPED tasks into refrigerator, along > with everyone else. SIGCONT is *not* going to help them out of > refrigerator. > > We also ignore TASK_STOPPED now, so we'll not proceed until all > stopped tasks are in refrigerator. > > Now... I'm not 100% sure I got the ptrace() cases right (and did not > test that)... but TASK_STOPPED cases look pretty trivial to me now. Please note that currently (and with your patch) freezeable() returns 0 for TASK_STOPPED, so we don't set PF_FREEZE for them and my patch changes _exactly_ that and adds some minor (optional) modifications to the error paths. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King
