--z6Eq5LdranGa6ru8
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,
>=20
> 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.
>=20
> i've been puzzling with this yes. The reason i went for this solution is=
=20
> that the origional code retrieved the vattr of the top vnode that userlan=
d=20
> sees whereas if the file system would issue vattr it would refer to the=
=20
> 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=
=20
> 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=
=20
> authentication does a seek need anyway... why is it passed a kauth_cred_t=
=20
> 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=
=20
> locked on entry and left locked. The current configuration file doesn't=
=20
> 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,

Bill


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFFBy0Wz+3JHUci9cRAoxUAJ9u+vBpLIE+MlvhAnkmGw1KovPvpwCdFAfF
wvHdOorA+WfgEckHMsrsqLo=
=9r8T
-----END PGP SIGNATURE-----

--z6Eq5LdranGa6ru8--