Date: Wed, 14 Dec 2011 18:58:30 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Changing lseek() to KNOTE on the vnode when seeking on a file Message-ID: <20111214165830.GG50300@deviant.kiev.zoral.com.ua> In-Reply-To: <201112141141.41168.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 ? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7o1bYACgkQC3+MBN1Mb4hU0wCeMul5vUVedn8Ujcs7AXDNnY9f jXcAn16gdJFhDhRDXYdARMYi7bblzJQG =hP4y -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111214165830.GG50300>