On Thu, 4 May 2000, Andrea Arcangeli wrote:
> I think that's not the correct fix though because there's probably still a
> window for a race if you happen to increase the mmap_sem when it was just
> zero (too late). I had a very fast look so I may be missing something but
> what do you think about this other below untested approch? It seems the
> task_lock() is there exactly to make sure the task won't go away from
> under us but it wasn't protecting the mm reference by mistake.
Yes. But there is a problem - ->close() may block for _long_
(several minutes). Think of ps blocking every time it happens, usual
reaction to that, fuser blocking too, etc. As the result you are getting
system seriously wedged. Most likely you'll get the blind panic (wetware
one) and attempt to reboot. Which will fail spectaculary, since most of
the shutdown rc scripts I've seen are trying to use killall. And it also
blocks.
Possible solutions:
a) think what we really need to see for zombies. E.g. if we consider
PF_EXITING as "dead" for maps, mem, fd/*, stat*, cmdline and environ -
fine, we can get out with that. Then we'll have to protect with
task_lock() setting of PF_EXITING and have the dentry/vfsmnt of binary
stored somewhere at the same moment. Then a simple change of
proc_exe_link() would go - check PF_EXITING and if it's set we must pick
the saved dentry instead of searching through the vma list.
b) think whether we can get rid of long blocking on ->close().
I had the same first reaction as you - put the task_lock() back ;-/
Unfortunately, it is not a solution...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:16 EST