From owner-freebsd-current Sat Apr 15 15:10: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C1BC737B7A9; Sat, 15 Apr 2000 15:09:57 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 15 Apr 2000 18:09:56 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Alan Cox Cc: Matthew Dillon , Alfred Perlstein , Michael Reifenberger , current@freebsd.org, alc@freebsd.org Subject: Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set. In-Reply-To: <20000415140945.B3462@cs.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 15 Apr 2000, Alan Cox wrote: > > It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count > > is greater then 1. > > Agreed. OBJ_ONEMAPPING actually means that *each page* within the object > is mapped at most once. The object itself may be mapped many times, > as long as the previous rule isn't violated. In other words, none > of the mappings map an overlapping set of pages. Alright, this makes sense to me. > > ... The ref_count has no bearing on the shareability > > of the object any more. The tests were there before due to all sorts > > of crud that had been hacked in in the 2.2.x and 3.x era to get around > > serious bugs in the OBJ_ONEMAPPING flag and elsewhere in the VM system. > > > > Note that the ref_count == 1 test in the vm_object_shadow optimization > > should be left intact. This optimization requires a much stricter set > > of tests because we do not want to assume sharability of an object > > if someone else (the 'else' being 'someone unknown to us') has a reference > > on it, even if OBJ_ONEMAPPING is set. > > > > Here's what troubles me about the state of the OBJ_ONEMAPPING management > code: When we clear the OBJ_ONEMAPPING attribute on an object, we don't > touch any of its backing objects. Specifically, we don't guarantee > that they don't have OBJ_ONEMAPPING set. I think we should, if only > because it makes reasoning about the system's behavior a lot easier. > > If we cleared OBJ_ONEMAPPING recursively, then the rationale for > this assertion would go away. 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? So, when you set OBJ_ONEMAPPING, should you check upward recursively to check if those objects can have OBJ_ONEMAPPING set? I assume that you mean that a backing object itself should have OBJ_ONEMAPPING cleared if any of the children have it cleared. > Brian, if you'd like to try this, I'll be happy to review it. I'm going to research the VM a bit more now that you and Matt have gotten me on track again, and soon wouldn't mind doing that :) > Alan -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message