Date: Wed, 14 Dec 2011 22:45:59 +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: <20111214204559.GI50300@deviant.kiev.zoral.com.ua> In-Reply-To: <201112141543.14130.jhb@freebsd.org> References: <201112141141.41168.jhb@freebsd.org> <20111214165830.GG50300@deviant.kiev.zoral.com.ua> <201112141543.14130.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--M3mBFhrxhGLhlzsC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2011 at 03:43:13PM -0500, John Baldwin wrote: > On Wednesday, December 14, 2011 11:58:30 am Kostik Belousov wrote: > > 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 r= egular=20 > > > file recently. Specifically, in the manpage it says: > > >=20 > > > 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 descri= ptor > > > type. > > >=20 > > > ... > > >=20 > > > Vnodes > > > Returns when the file pointer is not at the e= nd of > > > file. data contains the offset from current = position > > > to end of file, and may be negative. > > >=20 > > > He was then working on a program that read to EOF, then seeked back i= nto the > > > file. He was expecting to get a new kevent after seeking back into t= he file > > > since for his file descriptor after the lseek "there is data availabl= e to=20 > > > read" and "the file pointer is not at the end of file". I have a pat= ch to fix=20 > > > this by doing a KNOTE() on a vnode after a successful seek. I checke= d OS X=20 > > > 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=3Dxnu-1699= .24.8#L4182). > > >=20 > > > The one patch to fix this is below along with a test. Note that unli= ke 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= =20 > > > 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 "a= fter=20 > > > third read" cases. > >=20 > > Just curious - wouldn't it generate a spurious event if lseek is > > performed with zero offset, e.g. SEEK_CUR with offset 0 ? >=20 > Yes, it would, though if you aren't specifying EV_CLEAR and haven't gotte= n to > EOF yet, then it would already be pending anyway. In the case of EV_CLEAR > this could cause a new event to fire, yes. However, judging by OS X's > implementation of lseek(), they would do the same. Also, you won't get an > event if you are at EOF and merely seek back to EOF. I suppose we could > check for the case where the new offset =3D=3D the old one, but I'm not s= ure it > is a common enough case in conjunction with use of kevents() to really > warrant that? Note you can already get spurious events on an EVFILT_READ > filter if some other process creates a new link to the file, or does a > chown, chmod, etc. I think getting the note is fine, I mostly checked my understanding of the patch. I do not see any value in checking the specific case to not send the note. An application shall be ready to get the file extended and truncated by other process anyway. --M3mBFhrxhGLhlzsC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7pCwcACgkQC3+MBN1Mb4hzNgCcDnZIg9EJ3EndhVnzhLzUrDWu 2LYAoMr1xiI/K8BImkCLg5iqkh9/1wjM =TTOk -----END PGP SIGNATURE----- --M3mBFhrxhGLhlzsC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111214204559.GI50300>