From owner-freebsd-current Tue Mar 2 9:37:33 1999 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 8543D14D79 for ; Tue, 2 Mar 1999 09:37:23 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: from nonpc.cs.rice.edu (nonpc.cs.rice.edu [128.42.1.219]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id LAA00057; Tue, 2 Mar 1999 11:37:04 -0600 (CST) Received: (from alc@localhost) by nonpc.cs.rice.edu (8.9.2/8.7.3) id LAA90896; Tue, 2 Mar 1999 11:37:04 -0600 (CST) Date: Tue, 2 Mar 1999 11:37:04 -0600 From: Alan Cox To: Bruce Evans Cc: current@freebsd.org Subject: Re: lockmgr panic with mmap() Message-ID: <19990302113704.B90473@nonpc.cs.rice.edu> References: <199903021141.WAA03136@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199903021141.WAA03136@godzilla.zeta.org.au>; from Bruce Evans on Tue, Mar 02, 1999 at 10:41:46PM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 02, 1999 at 10:41:46PM +1100, Bruce Evans wrote: > > Doesn't it modify the map indirectly vi subyte()? I think it wants > to prevent modifications, but this is impossible. > Bear with me, I'll have to split some hairs... We're only interested in whether mincore directly changes the vm_map, literally modifying a vm_map_entry, etc. subyte is writing to memory, not a vm_map_entry. subyte is only indirectly changing the map because a page fault occurs. That page fault *is* (frequently) changing the map, and we're deadlocking when it attempts to acquire the write lock on the map. Basically, what I believe that you suggested yesterday, that mincore release the lock around the subyte is correct. Code will appear shortly... Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message