Here's the second version of TASK_KILLABLE. A few changes since version 1:
- Don't split up TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE.
TASK_WAKESIGNAL and TASK_LOADAVG were pretty much equivalent, and since
we had to keep __TASK_{UN,}INTERRUPTIBLE anyway, splitting them made
little sense.
- Instead, I've added some is_task_*() predicates. I think they
achieve what Linus wanted without consuming flag bits and without
checking a metric tonne of code to see whether it wanted
TASK_UNINTERRUPTIBLE or __TASK_UNINTERRUPTIBLE.
- Renamed try_lock_page() to lock_page_killable() and change the sense.
I had envisioned uses being like spin_trylock(), but that turned out
not to make sense.
- Fix the bug Trond noticed in wait_on_retry_sync_kiocb() by having the
callers handle it returning -EINTR
- Fix the bug I noticed in sync_pages_killable() by adding the new
function fatal_signal_pending()
- Audit a lot of uses of TASK_*. A few seemed dubious and were fixed.
I'd like to see this spend a bit of time in the -mm tree. I've wasted
a couple of days trying to track down why my machine no longer does
much after starting init, so clearly I'm tampering with stuff I don't
quite understand.
Having said that, I ditched that version of the code and started again
with a much more minimalist approach. I've also split the patch into
five independent pieces, each of which accomplishes a logical step,
for ease of bisection.
I think patch 1/5 is clearly Right and should be merged ASAP. Patch 2/5
and 3/5 carry some risk. 4/5 and 5/5 seem less risky to me (and are
independent of each other; both rely on 1-3 being applied first)
I obviously haven't covered every place that can result in a process
sleeping uninterruptibly while attempting an operation. But sync_page
(patch 4/5) covers about 90% of the times I've attempted to kill cat,
and I hope that by providing the two examples, I can help other people
to fix the cases that they find interesting.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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]
