Date: Mon, 15 Jul 2002 12:36:39 -0400 From: "Brian F. Feldman" <green@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Perforce Change Reviews <perforce@FreeBSD.org> Subject: Re: PERFORCE change 14125 for review Message-ID: <200207151636.g6FGadD69438@green.bikeshed.org> In-Reply-To: Your message of "Fri, 12 Jul 2002 22:50:32 EDT." <Pine.NEB.3.96L.1020712224406.1968B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@FreeBSD.org> wrote: > > On Fri, 12 Jul 2002, Brian F. Feldman wrote: > > > Robert Watson <rwatson@FreeBSD.org> wrote: > > > http://people.freebsd.org/~peter/p4db/chv.cgi?CH=14125 > > > > > > Change 14125 by rwatson@rwatson_paprika on 2002/07/11 21:54:24 > > > > > > Back out the lazy instantiate component of @14031, as it broke > > > mount-derived labels on multilabel (read-only or full) file > > > systems, as the EA write could result in a failure of the > > > label refresh, even though a valid label is available. > > > > > > Approved by: green > > > > Ack! No, you backed out all of it and re-re-reintroduced the bug where > > mac_update_vnode_from_externalized _NEVER_ gets called! > > We probably need to sit down with the source, because I think this still > isn't right. mac_update_vnode_from_externalized() is intended to take a > fully filled out extmac from the extended attribute, and initialize a > vnode label from it. You've changed the code flow so that you call it > even when extmac doesn't contain any valid data, which is simply > incorrect. Probably what we need is a new entry point intended > specifically to handle policies that manage the loading of the > externalized form themselves. Something on the order of: > > mac_update_vnode(vp); 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. > Also, we'll need to figure out how to arrange things so that > mac_update_vnode_from_mount() does the right thing in this context. The > real answer may be to take this opportunity to jump off the 'extmac on > disk' notion and switch all policies to use EAs directly now that we have > a working model for how it should happen. > > 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. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ 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?200207151636.g6FGadD69438>