From owner-freebsd-hackers Mon Feb 15 14:12:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15059 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 14:12:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15054 for ; Mon, 15 Feb 1999 14:12:10 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA15389; Mon, 15 Feb 1999 17:11:38 -0500 (EST) (envelope-from luoqi) Date: Mon, 15 Feb 1999 17:11:38 -0500 (EST) From: Luoqi Chen Message-Id: <199902152211.RAA15389@lor.watermarkgroup.com> To: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I found an interesting interlock situation between what I believe to > be a program binaries inode and the exec_map. The machine locked up > trying to exec new programs. > > This was running a make -j10 buildworld on a machine with 16MB of ram > configured, while testing my new VM system. I don't think the lockup is > due to my VM system, though. It took it 7 hours of extremely heavy > paging before it locked up. > > When I broke the machine out into DDB and did a ps, all of the cc's > were stuck in 'inode' wait, while a single ld program was stuck in > 'thrd_sleep'. > > I tracked 'thrd_sleep' down to a vm_map lock and the map down to > the exec_map. I tracked down the inode lock to the 'cc' program binary. > The inode had one shared lock and 7 waiters. The exec_map appears to > own one shared lock with 6 waiters ( but most of the waiters are due to > me trying to run other programs before breaking into the DDB ). > > I am guessing that there is an interlock situation with exec_map and > a program inode where one process locks exec_map followed by the program > inode, and another locks the program inode followed by exec_map. But > I'm not familiar with that section of the code so I would appreciate > any help. > > -Matt > Matthew Dillon > > I have a fix for this problem posted to -current a while ago: do a search on "deadlock". (I should have filed a PR, but I kept forgetting). It would also be nice to change "thrd_sleep" to something more sensible, say "vmmap". -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message