* Roland McGrath <[email protected]> wrote:
> > the amount of potentially affected code (assuming all the locking is
> > done in a single .[ch] file)
>
> I'm not sure what that means. I'm not confident that all relevant
> locking code is always in one file. If you mean that you did as I
> said, checked every use of siglock and confirmed that tasklist_lock is
> held before examining ->sighand, then we are good.
no, i didnt check all of that. I only checked the obvious places where
all 3 methods are used in a single module.
> > this reminds me about the patch below: it gets rid of tasklist_lock use
> > in the POSIX timer signal delivery critical path.
>
> I don't see how that works at all. The thought that it would seems to
> contradict what we've just been discussing. Holding tasklist_lock is
> what protects against ->sighand and ->signal changing and the old
> pointers becoming stale, not task_lock. What am I missing here?
yeah, it's a bad patch. Offtopic, but it's a real problem: the signal
code is inevitably holding the tasklist_lock for long times when sending
group signals, which is interfering with the signal-sending ability of
upcoming features like high-resolution timers (which uses
send_sigqueue()).
Could we get rid of tasklist_lock and do a careful lock-step walking of
the thread hierarchy (locking the next thread, unlocking the previous
thread in every step), or are there signal semantics reasons for doing
it all in one atomic step?
Ingo
-
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]
