Module Name: src
Committed By: riastradh
Date: Sat Sep 11 10:08:56 UTC 2021
Modified Files:
src/sys/compat/netbsd32: netbsd32_fs.c
src/sys/kern: sys_generic.c vfs_syscalls.c vfs_vnops.c
src/sys/sys: file.h
Log Message:
sys/kern: Allow custom fileops to specify fo_seek method.
Previously only vnodes allowed lseek/pread[v]/pwrite[v], which meant
converting a regular device to a cloning device doesn't always work.
Semantics is:
(*fp->f_ops->fo_seek)(fp, delta, whence, newoffp, flags)
1. Compute a new offset according to whence + delta -- that is, if
whence is SEEK_CUR, add delta to fp->f_offset; if whence is
SEEK_END, add delta to end of file; if whence is SEEK_CUR, use delta
as is.
2. If newoffp is nonnull, return the new offset in *newoffp.
3. If flags & FOF_UPDATE_OFFSET, set fp->f_offset to the new offset.
Access to fp->f_offset, and *newoffp if newoffp = &fp->f_offset, must
happen under the object lock (e.g., vnode lock), in order to
synchronize fp->f_offset reads and writes.
This change has the side effect that every call to VOP_SEEK happens
under the vnode lock now, when previously it didn't. However, from a
review of all the VOP_SEEK implementations, it does not appear that
any file system even examines the vnode, let alone locks it. So I
think this is safe -- and essentially the only reasonable way to do
things, given that it is used to validate a change from oldoff to
newoff, and oldoff becomes stale the moment we unlock the vnode.
No kernel bump because this reuses a spare entry in struct fileops,
and it is safe for the entry to be null, so all existing fileops will
continue to work as before (rejecting seek).
To generate a diff of this commit:
cvs rdiff -u -r1.93 -r1.94 src/sys/compat/netbsd32/netbsd32_fs.c
cvs rdiff -u -r1.132 -r1.133 src/sys/kern/sys_generic.c
cvs rdiff -u -r1.551 -r1.552 src/sys/kern/vfs_syscalls.c
cvs rdiff -u -r1.221 -r1.222 src/sys/kern/vfs_vnops.c
cvs rdiff -u -r1.86 -r1.87 src/sys/sys/file.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
