--OaZoDhBhXzo6bW1J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 10, 2006 at 02:01:13PM -0700, Jason Thorpe wrote:
>=20
> On Jul 10, 2006, at 1:39 PM, Bill Studenmund wrote:
>=20
> >My concerns are around what's going on if l->l_cred !=3D p->p_cred. =20
> >Since a
> >process is supposed to have one credential state, if we ever change
> >p_cred, we REALLY need all the l_creds to change at the same time. And
> >that means a global lock.
>=20
> Unless you consider that an LWP entering the kernel is like a =20
> "transaction", and that the credential state should remain constant =20
> from the beginning to the end of the "transaction".  Do you agree?

I'm not sure about the cause&effect here. :-) I DO agree that we don't=20
want an lwp to change credentials in the middle of a systemcall. However a=
=20
shared lock with upgrade to exclusive will also do that. :-)

> If so, then it makes PERFECT sense to set the LWP's creds upon kernel =20
> entry, and not change those creds unless the LWP is requesting a cred =20
> change.  That way, a cred change by the proc while the LWP sleeps =20
> (disk I/O?) won't screw up whatever the LWP is (legitimately) trying =20
> to do with the creds it started out with.

I agree we don't want to screw up the LWP.

But doing the above has an impact on changing credentials. We will return=
=20
success on changing credentials before we've realy finished the change.=20
Yes, we've put things in place so the NEXT system call will use the new=20
creds, we are still using the old ones. If the unchanged LWP stays in the=
=20
kernel "for a while", then we have a measure of shadiness.

How do other OSs handle this? Do they care?

Take care,

Bill

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

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

iD8DBQFEstUSWz+3JHUci9cRAv9RAJ95OGG6DrCAb31q0gbTT0fgAaPhUgCdFi7u
2AY+++fDc5FNd4J2uaxtoDQ=
=sPOT
-----END PGP SIGNATURE-----

--OaZoDhBhXzo6bW1J--