Date: Mon, 01 Mar 99 15:10:21 -0800 From: Rahul Dhesi <dhesi@rahul.net> To: current@FreeBSD.ORG Subject: Re: lockmgr panic with mmap() Message-ID: <199903012310.AA22894@waltz.rahul.net> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of Sun, 28 Feb 99 12:40:18 -0800
next in thread | previous in thread | raw e-mail | index | archive | help
Admittedly detecting deadlock is not trivial in general. But if we are about to panic because of deadlock, then we have already detected something. The question now is: Do we crash the whole system, or just one or two user processes? Rahul > :Since bugs do happen, deadlock can occur in the kernel. > : > :Is it not possible in such cases to simply detect the deadlock, and kill > :one of the user processes involved in the deadlock, thus releasing one > :of the resources involved in the deadlock? Then you would log > :diagnostic information and let the system continue normally.... > Most of the deadlocks remaining in the kernel are more complex and often > cannot be detected without significant new work.... > Detecting the loop is the hard part. This is known as 'deadlock > detection'... ... > In FreeBSD's case, the issue is somewhat more complex due to things > that are not strictly locks causing deadlocks - such as a low memory > condition causing a process holding an inode lock to block and then the > syncer blocking on the same inode. The syncer is thus unable to run and > thus unable to sync the dirty buffers clogging memory to disk. Things > like that. > > -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903012310.AA22894>