From owner-p4-projects Mon Jul 15 11:48:54 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A780437B405; Mon, 15 Jul 2002 11:48:47 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17CB137B400; Mon, 15 Jul 2002 11:48:47 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8768B43E5E; Mon, 15 Jul 2002 11:48:46 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g6FIaROo078176; Mon, 15 Jul 2002 14:36:27 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 15 Jul 2002 14:36:27 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Brian F. Feldman" Cc: Perforce Change Reviews Subject: Re: PERFORCE change 14125 for review In-Reply-To: <200207151636.g6FGadD69438@green.bikeshed.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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