Date: Mon, 15 Feb 1999 15:27:04 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (Ask the authors) Message-ID: <199902152027.PAA01706@y.dyson.net> In-Reply-To: <199902151944.LAA18828@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 11:44:24 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > 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. > I don't know what you are trying to do in your code, but there is alot of history of problems in that area. I suspect that you might be making one of the mistakes that we used to do, and there is a resource deadlock problem in that area. I suggest that you look at some of the mailing-list archives (either in -hackers or in -current) for information on such deadlocks. It could be cloaked by other subjects. Hint: it isn't generally a good idea to fault data into the kernel. If that isn't the problem, then there are other deadlock issues (throughout the VM system structure), that need to be carefully considered before hacking away. I strongly suggest that if you are hacking away at DGs and my VM code, that you contact the authors, rather than randomly asking questions on the mailing lists :-). Being very busy, I cannot answer questions immediately all the time. However, DG and I are the authors of the existing code (mostly leaving old copyrights on for reasons of convienience), so contact the authors who are available. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. 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?199902152027.PAA01706>