Messages in this thread | | | Date | Thu, 05 Aug 1999 07:49:23 +0200 | From | Manfred Spraul <> | Subject | Re: i_size still not SMP safe. |
| |
Alexander Viro wrote: > > Description (everything for ext2): > > sys_write() calls generic_file_write() without acquiring the big kernel > > lock, and generic_file_write() uses f_pos and i_size without any locks. > > Note that O_APPEND is broken as well, and this might be the larger problem. > > I'm moving the modification of f_pos and i_size inside of the per-page > lock in FAT patch. With FAT the things get addition trickyness, since we > don't have holes (arrgh...) It is not enough for complete solution, > though.
I thought about that, it could become ugly: e.g., sys_llseek() and truncate would have to lock a page in the page-cache.
And you should also check the thread "2.3 SMP overlapping writes and NFS". Basically, NFS v2-writes should be atomic. Even multi-page writes.
I think a list of all collisions will be the best option: * parallel writes and reads to different areas of the file will be possible. * parallel readdir()-calls should be possible, but I did not check this. * it's not that complicated: e.g. a truncate is identical to a write: it needs exclusive access for the byte range (new EOF, current EOF).
You don't need any new sync objects: only a normal spinlock for additions and removals from the collision list, and a wait queue for blocked threads. The collision list is similar to an extended semaphore: the "dec sem->count" is replaced with a check of all pending operations, so it's a very flexible and "fine grained" lock.
> > Btw, I think that the lock_kernel()-call in sys_lseek() is superflous: > > sys_lseek accesses the same fields as sys_write(), but sys_write() > > does not acquire the big kernel lock. > > Atavism again.
only partially: if f_op->llseek is NULL, then the lock_kernel() call is superflous. Otherwise, it's needed because the actual filesystem could rely on it.
-- Manfred
- 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/
| |