Messages in this thread | | | Date | Sun, 14 Feb 1999 15:23:42 -0500 (EST) | From | Alexander Viro <> | Subject | Re: fsync on large files |
| |
On Sun, 14 Feb 1999 Ralf.Sieger@gmx.net wrote:
> > 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/
| |