Changing lseek() to KNOTE on the vnode when seeking on a file

[Kostik Belousov]

On Wed, Dec 14, 2011 at 11:41:41AM -0500, John Baldwin wrote:
> A co-worker ran into an issue with using an EVFILT_READ kevent on a regular 
> file recently.  Specifically, in the manpage it says:
> 
>      EVFILT_READ    Takes a descriptor as the identifier, and returns whenever
>                     there is data available to read.  The behavior of the fil-
>                     ter is slightly different depending on the descriptor
>                     type.
> 
>                     ...
> 
>                     Vnodes
>                         Returns when the file pointer is not at the end of
>                         file.  data contains the offset from current position
>                         to end of file, and may be negative.
> 
> He was then working on a program that read to EOF, then seeked back into the
> file.  He was expecting to get a new kevent after seeking back into the file
> since for his file descriptor after the lseek "there is data available to 
> read" and "the file pointer is not at the end of file".  I have a patch to fix 
> this by doing a KNOTE() on a vnode after a successful seek.  I checked OS X 
> and it looks like they added this to their lseek() in Snow Leopard
> (http://fxr.watson.org/fxr/source/bsd/vfs/vfs_syscalls.c?v=xnu-1699.24.8#L4182).
> 
> The one patch to fix this is below along with a test.  Note that unlike OS X
> I did not add a new NOTE_NONE for this case.  OS X has logic in their VFS
> filter operations that make special assumptions about a hint value of 0, so
> they had to add NOTE_NONE as a hack.  We do not have the same special 
> assumptions about a hint of 0, so we can just use "0".  Without this fix the
> test below complains about missing events for the "after seek" and "after 
> third read" cases.

Just curious - wouldn't it generate a spurious event if lseek is
performed with zero offset, e.g. SEEK_CUR with offset 0 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20111214/b9362f96/attachment.pgp