From owner-freebsd-current Sun Feb 28 13:23:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id BAA8415321 for ; Sun, 28 Feb 1999 13:23:26 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.3) id PAA00692; Sun, 28 Feb 1999 15:23:00 -0600 (CST) (envelope-from dick) Date: Sun, 28 Feb 1999 15:23:00 -0600 From: "Richard Seaman, Jr." To: Bruce Evans Cc: current@FreeBSD.ORG, pangolin@home.com, Julian Elischer Subject: Re: lockmgr panic with mmap() Message-ID: <19990228152300.A467@tar.com> References: <199902281252.XAA24877@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=sm4nu43k4a2Rpi4c X-Mailer: Mutt 0.95.1i In-Reply-To: <199902281252.XAA24877@godzilla.zeta.org.au>; from Bruce Evans on Sun, Feb 28, 1999 at 11:52:57PM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii On Sun, Feb 28, 1999 at 11:52:57PM +1100, Bruce Evans wrote: [snip] > Here is a simpler example. > > --- > #include > #include > > #include > #include > > #define SIZE (32 * 1024 * 1024) > > int > main(void) > { > void *p; > char vec[SIZE / PAGE_SIZE]; > > p = malloc(SIZE); > if (mincore(p, SIZE, vec) != 0) > err(1, "mincore"); > return (0); > } > --- > > mincore() locks the vmspace map, and initialises vec[] a byte at a time > using subyte(). When vec[] is sufficiently large, it is not all in core > initially and a page fault occurs in subyte(). The new stack growing > code locks the vmspace map early and panics. It appears to me the potential for deadlock exists in the old grow code too, but is less likely. I've attached a patch that addresses the issue, though there is a question if this is the best solution. With the old grow code, if the map lock is already held, one of the following will be true a) the grow code doesn't get executed because the va is not in the stack region, which is equivalent to grow returning success b) the grow code returns success because there's no need to grow the region because the va is aready in the mapped region. c) the grow code returns false if the va is within the stack region and there's no room left, which normally will result in a SIGSEGV d) the grow code attempts to grow the stack via vm_map_find and will then deadlock at the vm_map_lock call With this patch, if the map lock is already held, by always returning success, cases a) and b) will be the same as before. For case c) the code will attempt to continue to execute, generally calling vm_fault, which should, I think, generate a SIGSEGV, essentially the same result as the old code, but via a different path. Case d) will now continue executing in a manner equivalent to the new case c). The question is whether there is a way to do the autogrow function if the map lock is already held. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5850 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=vmfix Index: vm_map.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_map.c,v retrieving revision 1.152 diff -c -r1.152 vm_map.c *** vm_map.c 1999/02/24 21:26:25 1.152 --- vm_map.c 1999/02/28 20:41:25 *************** *** 663,668 **** --- 663,674 ---- int rv; int is_procstack = 0; + + #define vm_map_locked(map) lockstatus(&(map)->lock) + + if (vm_map_locked(map)) + return (KERN_SUCCESS); + vm_map_lock(map); /* If addr is already in the entry range, no need to grow.*/ --sm4nu43k4a2Rpi4c-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message