On Tue, 22 Jan 2008 23:27:27 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> /proc/sys part of sysctl code runs without BKL held, so BKL during > sysctl(2) is useless. Remove misleading comment and "protection" around > coredumping code -- kernel.core_pattern can be written without BKL. > > do_sysctl() and lookup in /proc/sys use identical iterators, so any locking > bug BKL supposedly fixed in sysctl(2) code we should have in /proc/sys > code anyway. > > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> NAK The core dump locking is now totally unprotected rather than slightly dubious. This patch needs to go in together with a parallel patch to actually lock properly. You've made a bug worse not fixed it. There are cases that updating the corepath name and dumping a core at the same moment can result in the wrong thing being exec()'d or a file being opened which is a mix of the old and new name and could go anywhere. I see two variants on your patch that work #1 Replace the lock_kernel with a sysctl_update mutex and fix both paths #2 Add locking specifically to the corename path Alan -- 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/
