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.
>(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.
Pavel
--
Thanks for all the (sleeping) penguins.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
