Date: Mon, 15 Feb 1999 17:11:38 -0500 (EST) From: Luoqi Chen <luoqi@watermarkgroup.com> To: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? Message-ID: <199902152211.RAA15389@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> 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 > <dillon@backplane.com> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902152211.RAA15389>