From owner-freebsd-current Sat Apr 15 23:25:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 424E137B56B; Sat, 15 Apr 2000 23:25:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA82772; Sat, 15 Apr 2000 23:24:21 -0700 (PDT) (envelope-from dillon) Date: Sat, 15 Apr 2000 23:24:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200004160624.XAA82772@apollo.backplane.com> To: Alan Cox Cc: Brian Fundakowski Feldman , current@FreeBSD.ORG Subject: Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set. References: <20000415140945.B3462@cs.rice.edu> <20000415185718.E3462@cs.rice.edu> <200004160313.UAA82143@apollo.backplane.com> <20000415234342.H3462@cs.rice.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I don't think this is an issue. The only double-mapped pages we care :> about are those at the top-level (vm_object's connected directly to a :> vm_map_entry). This is because these are the only pages effected by :> write-faults and copy-on-write issues. :> : :I disagree. If a backing object (BO) has OBJ_ONEMAPPING set, and someone :call vm_map_delete(map, start, end) on an address space that references :BO directly, then the system will crash and burn because vm_map_delete :will (incorrectly) free physical pages: : : ... : pmap_remove(map->pmap, s, e); : if (object != NULL && : object->ref_count != 1 && : (object->flags & (OBJ_NOSPLIT|OBJ_ONEMAPPING)) == OBJ_ONEMAPPING && : (object->type == OBJT_DEFAULT || object->type == OBJT_SWAP)) { : vm_object_collapse(object); : vm_object_page_remove(object, offidxstart, offidxend, FALSE); : ^^^^^^^^^^^^^^^^^^^^^ This is in the top-level object, so it isn't a problem. OBJ_ONEMAPPING will be correct. If there are problems anywhere, they are going to be in the collapse() code.. Either vm_object_collapse() or vm_object_backing_scan() (called by vm_object_qcollapse()). I think vm_object_collapse() is safe, it will only remove pages from the backing object if the reference count is 1, which guarentees that there are no shared mappings no matter what the state OBJ_ONEMAPPING. vm_object_backing_scan() also appears to be safe... it is either only called from vm_object_collapse(), or vm_object_qcollapse(). vm_object_qcollapse() also only calls it if the backing object has only one refrence count. I think we're safe. I agree that not having OBJ_ONEMAPPING set properly in underlying objects is bad design... but it's a design we inherited and it's hard enough making the code work I don't want to introduce new bugs fixing something that may not be broken (beyond not being documented well). :> and the other process cannot see that change. OBJ_ONEMAPPING is an :> optimization that allows a process to dirty an anonymous (not vnode-backed) :> page without doing a copy-on-write in the case where that process is :> the ONLY process mapping the page. :> : :Umm, it can do this without the OBJ_ONEMAPPING attribute, because :the ref count on the object == 1. Note that the code from vm_object_shadow :doesn't even check OBJ_ONEMAPPING: :... :I do care, because I don't want those pages freed by a vm_map_delete. I think we're safe. If you can find a case where vm_map_delete() screws us up, then we have a problem. I can't find a case. :> be pre-pended or post-pended with the new pages rather then have to create :> a new vm_object (and thus not be able to coalesce the associated :> vm_map_entry structures) every time we take a copy-on-write fault. :> : :Huh? It's always been the case that when a shadow object is created, :its size is equal to the size of the mapping. This predates the :existance of OBJ_ONEMAPPING. vm_map_lookup, where shadow objects :are normally created on COW faults, has always done: Ach, yes you're right. There's a case I fixed a while back... ah, I remember what it was, it was the stack-extension code. That's what I was thinking of. It has nothing to do with what we are talking about now. Sorry, my mistake! I think there are cases where the maps get broken up, though... where is it.. Ah, here it is. The vm_map_split() code. I think this may play a role when you have long fork() chains, but I haven't checked for sure. :> In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the :> scaleability of our VM system. :> : :It's not critical. COW worked just fine (performance-wise) :before OBJ_ONEMAPPING. John Dyson introduced OBJ_ONEMAPPING :so that he could free individual pages within an object earlier, :without waiting for the entire object to be freed. : :Alan -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message