Actually, it will usually be executed with no lock held at all, as most
page faults by far happen from user mode..
It so happens that wrt the kernel lock we're safe, because a process that
sleeps automatically relinquishes the lock. So even if we have the kernel
lock before getting the mmap semaphore, if we end up waiting for the mmap
semaphore we will release the kernel lock during that wait.
So the more I think about it, I can't actually see any way to deadlock
with a sleep-lock and the kernel lock, regardless of ordering. So in this
particular case ordering probably doesn't matter.
However, I still very much want to see the mmap semaphore be one of the
most "outermost" locks. It's one with the least contention (none, in fact,
unless you use threads that try to change the memory map at the same
time), and as such it is best to consider that one the "first" one.
My personal prioritization is currently something like this:
inode write semaphore
mmap semaphore
spinlocks
where the spinlocks have their own internal priorities too. The kernel
lock is special, in that due to the way it works it is fairly unordered
wrt any sleeping locks.
So yes, you're right, it doesn't matter.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu