> On a 2.6.11 x86 system, I am SIGSTOP'ing processes which have started
> several threads before.
>
> As expected, all threads are suspended.
>
> But surprisingly, it can happen that some threads are still scheduled
> after the SIGSTOP has been issued.
>
> Typically, they get scheduled 2 times within the next 5ms, before being
> really stopped.
>
> Sadly, I could not reproduce that in a smaller example yet.
>
> As this behaviour is IMA against the SIGSTOP concept, I tried to analyze
> the kernel code responsible for that. I could not really find the exact
> lines.
>
> So here are my questions:
>
> 1. do you know any reason for which the SIGSTOP would not stop
> immediatly all threads of a process?
The following scenario is possible:
program1 with a thread thread1
1) you send SIGSTOP to program1
2) thread1 is now scheduled and run.
3) program1 is now run and before it is scheduled off it notices it has
a signal set, makes sure all threads in the group gets SIGSTOP set.
4) thread1 is now scheduled and run again. now before it is scheduled
off it will find a signal pending and set itself in SIGSTOP.
There are absolutely no guarantees when a signal will be delivered.
Signals are delivered asynchronously.
> 2. where do the threads get suspended exactly in the kernel? I think it
> is in signal.c but I am not sure exactly were.
do_notify_resume()
do_signal()
get_signal_to_deliver()
do_signal_stop()
finish_stop()
> 3. can you confirm that the bug MUST be in my code? :)
You'll have to use reliable mechanisms to achieve what you're looking
for.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
