[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subjecttask_lock allows denial of service [+PATCH]


I had lots of problems with 2.3.5x/99x arbitarily blocking all /proc
accesses. It turns out that task_lock is to blame. I had a mgetty
hanging around which exited regularly and hung for a long time in the
serial driver's filp close function. While that all ps
ran into the locked exit_sem of the mgetty and blocked.

[Al, this seems to explain the loopback bugs I complained about
earlier. Heavy loopback usage just makes it more likely to run
into this]

It seems to be mostly an issue with the serial driver, most other
closers that could block (e.g TCP) check for PF_EXITING and do not wait
that long in process close. I'm not sure why it doesn't block asynchronously
like TCP.

My easy fix was to just move most of exit's work outside task_lock.
As far as I can see the files accesses are safe (proc seems to check
task->files again after sleeping), and the MM has its own semaphore.
What it only needs to protect against is against the process completely
disappearing, which can be done by just doing the remove from the proc
tree inside the semaphore. All the other __exit_* do not block.

This all assumes that do_exit and proc are running in the big kernel
lock, which is fine for 2.4. 2.5 probably needs a different solution.

I appended the patch.

Linus, could you apply it?



--- linux/kernel/exit.c-o Wed Mar 15 20:27:17 2000
+++ linux/kernel/exit.c Tue Mar 21 22:51:12 2000
@@ -414,12 +414,12 @@
- task_lock(tsk);
+ task_lock(tsk);
tsk->state = TASK_ZOMBIE;
tsk->exit_code = code;

This is like TV. I don't like TV.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.028 / U:0.524 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site