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/