lkml.org 
[lkml]   [1999]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.197 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site