>
> I took a look at fs/buffer.c in 2.0.36 and compared it with 2.2.1.
> What I found was
> 1. We do a lock_kernel() on each sys_fsync().
> So all other processes using this lock_have to wait... Why?
No, they haven't. kernel_lock affects nothing if the process
doesn't run at this moment. It protects processes on *different* CPUs from
simultaneous running in the kernel. It's an attribute of task and if the
task decides to sleep it is removed (and restored as soon as it wakes up).
> 2. Plus we ensure we get the semaphore
>
> /* We need to protect against concurrent writers.. */
> down(&inode->i_sem);
>
> So I have problems to get it. Since we called lock_kernel() we are the ony
> on in this pice of code.
>
> So AFAIK wheter the kernel lock is unneccessary or the semaphore or both?
Neither. Imagine the following situation: process A calls fsync()
and sleeps on IO. In the meanwhile process B wakes up and starts messing
with the file. After a while it sleeps on IO too. Process A wakes up and
finds some interesting changes ;-/ And struct file (and to less extent
dcache) management still isn't SMP-safe, so we need kernel_lock hold.
-
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/