I don't quite see how it is prone to race conditions. In before we call
copy_mount_options we have a kernel_lock. The only way I can see that we
might cause a race is if we block somewhere in that function. But,
nothing in there can block. Besides, do we really want to be generating
an exception for even successful calls? When we go to the exception
handling code, we add a bunch of stuff to the kernel stack before we start
peeling the frame off. This increases the likelyhood of running off the
end of the stack and causing some pretty nasty corruption. In addition,
the fixup code for the __copy_user function is itself protected by
exception frames. We might start causing exceptions inside exception, and
by my understanding, that is BadThing(tm).
> Which is fine. Turn off the Execption: messages -- leaving them on means
> that user programs can perform a DoS attack on your kernel message logs
> anyways. It was a debugging thing that was turned off ages ago on x86.
Ahh... oops, yeah. I'll do that right away :)
Rich
-
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/