Konstantin Belousov 854c3ce7ac Fix locking for f_offset, vn_read() and vn_write() cases only, for now.
It seems that intended locking protocol for struct file f_offset field
was as follows: f_offset should always be changed under the vnode lock
(except fcntl(2) and lseek(2) did not followed the rules). Since
read(2) uses shared vnode lock, FOFFSET_LOCKED block is additionally
taken to serialize shared vnode lock owners.

This was broken first by enabling shared lock on writes, then by
fadvise changes, which moved f_offset assigned from under vnode lock,
and last by vn_io_fault() doing chunked i/o. More, due to uio_offset
not yet valid in vn_io_fault(), the range lock for reads was taken on
the wrong region.

Change the locking for f_offset to always use FOFFSET_LOCKED block,
which is placed before rangelocks in the lock order.

Extract foffset_lock() and foffset_unlock() functions which implements
FOFFSET_LOCKED lock, and consistently lock f_offset with it in the
vn_io_fault() both for reads and writes, even if MNTK_NO_IOPF flag is
not set for the vnode mount. Indicate that f_offset is already valid
for vn_read() and vn_write() calls from vn_io_fault() with FOF_OFFSET
flag, and assert that all callers of vn_read() and vn_write() follow
this protocol.

Extract get_advice() function to calculate the POSIX_FADV_XXX value
for the i/o region, and use it were appropriate.

Reviewed by:	jhb
Tested by:	pho
MFC after:	2 weeks
2012-06-21 09:19:41 +00:00
..
2012-05-31 19:32:37 +00:00
2012-05-31 19:34:53 +00:00
2012-05-24 11:24:44 +00:00
2011-12-05 10:34:52 +00:00
2012-06-14 17:32:58 +00:00
2011-04-13 11:28:46 +00:00
2012-01-02 12:12:10 +00:00
2012-03-28 20:58:30 +00:00
2012-03-28 20:58:30 +00:00
2012-03-28 20:58:30 +00:00
2012-05-27 05:24:53 +00:00
2012-03-28 20:58:30 +00:00
2012-03-28 20:58:30 +00:00
2011-07-10 00:53:04 +00:00
2012-01-02 12:12:10 +00:00
2012-02-01 14:34:52 +00:00
2012-01-26 16:35:09 +00:00
2012-06-11 18:47:26 +00:00
2012-06-10 20:24:01 +00:00
2012-05-25 21:52:57 +00:00
2012-05-25 21:52:57 +00:00
2012-01-02 12:12:10 +00:00