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? seems like another process could be truncating or lengthening
the file and cause mmap() misbehavior (for example an inappropriate
SIGBUS, or access to random data pages).
all other accesses to this field that i could find are behind the global
kernel lock.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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/