Subject: Re: Second patch for lseek() sparse file extension
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 09/22/2006 10:26:12
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 22, 2006 at 02:39:14PM +0200, Reinoud Zandijk wrote:
> Dear Takashi,
> On Fri, Sep 22, 2006 at 11:33:17AM +0900, YAMAMOTO Takashi wrote:
> > > -	*(off_t *)retval =3D fp->f_offset =3D newoff;
> > > - out:
> > > +	error =3D VOP_SEEK(vp, fp->f_offset, SCARG(uap, whence),
> > > +	    SCARG(uap, offset), &newoffset, &vattr, cred);
> >=20
> > passing vattr seems a bad idea to me.
> > VOP_SEEK (ie. filesystem) itself should have a better idea of
> > attributes than callers.
> i've been puzzling with this yes. The reason i went for this solution is=
> that the origional code retrieved the vattr of the top vnode that userlan=
> sees whereas if the file system would issue vattr it would refer to the=
> bottom vnode. I was worried if that could/would screw things up like=20
> permissions say on a user-mapping fs. I'd also have to pass the lwp down=
> making yet another argument to VOP_SEEK. Is this a problem or not? Or=20
> should the vattr() be queried by the FS without authentication? Then what=
> authentication does a seek need anyway... why is it passed a kauth_cred_t=
> when it is not used.

Have the file system call VOP_GETATTR(), don't pass it down.

There is no way a layered stack will misbehave as you describe. Because=20
that would be a broken layer.

Think about it. For what you describe to happen, the user-mapping layer=20
would have to remap VOP_GETATTR()'s credentials and not VOP_SEEK()'s.

> Furthermore in the VOP_SEEK(9) docs it states that the node needs to be=
> locked on entry and left locked. The current configuration file doesn't=
> enforce it on lockdebug kernels but i think it could be added without=20
> problems.

Look at what the code's doing first, please. :-) Locking is fine, and=20
useful for file systems that can have holes.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)