>>>>> On Tue, 10 May 2005 17:59:46 -0700, Roland McGrath <[email protected]> said:
Roland> (This leads to threads in TASK_TRACED with a pending
Roland> SIGKILL, that cannot be killed with repeated kill -9s, and
Roland> live until the tracer uses PTRACE_CONT, detaches, or dies.)
Ah, yes, I see now that SIGKILL is a rather nasty special-case.
Roland> When I suggested this change for ia64 originally, I
Roland> overlooked the need to handle blocking in writing to user
Roland> memory. I'd like to give a little more thought to the
Roland> general case. As long as only uninterruptible waits are
Roland> provoked by an arch hook, then I think it is reasonably
Roland> solvable. I think that SIGKILL races are the only ones that
Roland> can arise, and those can be addressed with some signal
Roland> bookkeeping changes. I'd like to give it a little more
Roland> thought. I expect it will wind up being some core changes
Roland> that make it safe for an arch hook to drop and reacquire the
Roland> siglock if it's doing something that won't always complete
Roland> quickly, and then this will all happen before changing
Roland> state, unlocking, and deciding to block (which won't be done
Roland> if there was an intervening SIGKILL).
OK, that sounds good to me. Please keep me posted. It would be nice
to have this hook in place, since it does fix a bug on ia64 and makes
the code simpler.
Thanks,
--david
-
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]
