Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 12 Jul 1999 21:58:31 +0100 (BST) | Subject | Re: protecting inode->i_size |
| |
Hi,
On Fri, 9 Jul 1999 15:10:59 -0400 (EDT), Chuck Lever <cel@monkey.org> said:
> i know some of you are working on this area, so i thought i'd ask a broad > question.
> what lock currently protects the inode->i_size field in 2.3.7+ ? if the > answer is "global kernel lock" are there plans to change this protection > to something more fine-grained?
> it appears that filemap_nopage releases the global lock, but then proceeds > to call try_to_read_ahead, which reads the inode's i_size field. is this > a problem?
As long as all modifications are under the kernel lock, i_size itself is safe enough. If another CPU is modifying i_size, then by the end of the modification the unlock_kernel() should guarantee a memory write barrier, so we'll see the correct value by the end of the update.
Of course, if we have other data structures dependent on i_size and lacking the global lock, then things are a little more tricky, but the important functions like ext2_block_map and ext2_get_block are still kernel-locked so we should be OK there.
What really concerns me at the minute is code like:
if (pos > inode->i_size) inode->i_size = pos;
in generic_file_write, outside the kernel lock. Ingo, comments? We still have non-atomic O_APPEND due to the lack of any locking in generic_file_write, which breaks Unix semantics completely. Have you had any more thoughts on how to deal with this? Locking the inode semaphore for any inode modifications to i_size would seem to be the obvious thing.
Incidentally, I don't think we can safely do the i_size assignment from inside filemap.c. We really need to do what truncate() does, which is to perform a notify_change() on i_size.
--Stephen
- 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/
| |