Date: Mon, 15 Jul 2002 14:36:27 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: Perforce Change Reviews <perforce@FreeBSD.org> Subject: Re: PERFORCE change 14125 for review Message-ID: <Pine.NEB.3.96L.1020715143117.72988C-100000@fledge.watson.org> In-Reply-To: <200207151636.g6FGadD69438@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Jul 2002, Brian F. Feldman wrote: > I suppose adding that hook probably will be a solution, if not an > elegant one. I'd rather it just not call it for policies that have no > data but a reserved data slow. Not sure how to parse the last sentence. The direction we seem to be moving in is to permit policies to implement their own label persistence in EAs as they see appropriate. The commit I did over the weekend for improved caching should help, I think. Note that policies currently have the option to pick one (or both) of the two approaches: they can implement neither, mac_update_vnode_from_extattr(), mac_update_vnode_from_externalized(), or both. Right now I have SEBSD implementing ..._extattr(), and the other policies still using ..._externalized(). I don't want to move the other policies over until we figure out what the right failure modes are in various crash/failure cases. > > I'm surprised you can even boot this with any of the non-SEBSD policies > > enabled. > > I don't run with corrupt labels, though. And I also wasn't running with > "no labels" since I was lazy-instantiating them. The logic I had made > sense except for read-only cases. Right now I run several file systems in nomultilabel mode. The changes you made appeared to cause mac_update_vnode_from_externalized() to accept an un-filled-out 'struct mac' in the case where the EA wasn't present (ENOATTR), resulting in externalized() policies often panicking. In general, we can't assume that we'll be able to write a persistent label in every case we can read, since the main tree uses shared locks for some cases where exclusive locks are required to modify the extended attribute. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020715143117.72988C-100000>