linux-kernel - [PATCH] TASK_KILLABLE version 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070902024348.GJ14130@parisc-linux.org>
Date:	Sat, 1 Sep 2007 20:43:49 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] TASK_KILLABLE version 2

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/