From owner-freebsd-current Sat Apr 15 16:57:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 1DF0737B536; Sat, 15 Apr 2000 16:57:20 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id SAA18969; Sat, 15 Apr 2000 18:57:18 -0500 (CDT) Date: Sat, 15 Apr 2000 18:57:18 -0500 From: Alan Cox To: Brian Fundakowski Feldman Cc: current@freebsd.org Subject: Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set. Message-ID: <20000415185718.E3462@cs.rice.edu> References: <20000415140945.B3462@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: ; from Brian Fundakowski Feldman on Sat, Apr 15, 2000 at 06:09:56PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 15, 2000 at 06:09:56PM -0400, Brian Fundakowski Feldman wrote: > > I'm still trying to understand this: if you know that the object may > have pages mapped elsewhere, the backing objects recursively inherit > the assumption that it may have parts mapped elsewhere? Umm, just to be clear, it's not that the object has pages mapped elsewhere, it's that one (or more) pages in the object have two or more mappings. In other words, the same physical page is mapped twice. It's okay for an object to have multiple mappings (and thus ref_count > 1) and have OBJ_ONEMAPPING set if all of these mappings map disjoint sets of pages. (This is what's happening when the assertion gets mistriggered.) So, OBJ_ONEMAPPING gets cleared whenever it becomes possible for the same physical page to get mapped twice. (In other words, it happens before the mapping is actually created, e.g., from vm_map_copy_entry() that gets called on a fork.) Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level object, and none of its backing objects. Nothing guarantees that these backing objects have OBJ_ONEMAPPING cleared. The page that we're "double" mapping may, however, reside in one of its backing objects. This is bad. > ... So, when you > set OBJ_ONEMAPPING, should you check upward recursively to check if > those objects can have OBJ_ONEMAPPING set? No. When you clear OBJ_ONEMAPPING, you should clear OBJ_ONEMAPPING on all of its backing objects. You can only set OBJ_ONEMAPPING under limited circumstances where you can prove that no page within an object has two or more mappings, e.g., the object's ref_count == 1. > ... I assume that you mean that > a backing object itself should have OBJ_ONEMAPPING cleared if any of > the children have it cleared. > No. backing object == child. Stepping back from the details, keep in mind the following: OBJ_ONEMAPPING is an optimization. If you clear it when it could be set, nothing breaks. (The worst case is that we don't free up swap space as quickly. An entire chain of objects has to disappear before we can reclaim the swap.) On the other hand, if you set OBJ_ONEMAPPING when it shouldn't be set, you break things badly. (Go back and look at the mailing lists when John first introduced this code.) Alan P.S. This is one area where UVM has the advantage. They have per-page ref counts in their vm objects, and not just vm object granularity ref counts. Thus OBJ_ONEMAPPING isn't necessary. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message