From owner-freebsd-current Sun Feb 28 12:40:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C81C1152D8 for ; Sun, 28 Feb 1999 12:40:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA39025; Sun, 28 Feb 1999 12:40:18 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Feb 1999 12:40:18 -0800 (PST) From: Matthew Dillon Message-Id: <199902282040.MAA39025@apollo.backplane.com> To: Rahul Dhesi Cc: current@FreeBSD.ORG Subject: Re: lockmgr panic with mmap() References: <199902281908.AA09561@waltz.rahul.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Please forgive me if this is a silly question. : :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. If a user :deliberately does something to deadlock the kernel, his process just :gets killed and a denial-of-service attack has been averted. : :As I vaguely recall, VAX/VMS used to do soemthing like this if a :deadlock was detected. : :Rahul Well, the lockmgr panic with mmap() is something that ought to be easily fixable ( by whoever did the stack changes ). There are also deadlock problems when read()ing or write()ing a file-backed mmap()'d area. Most of the deadlocks remaining in the kernel are more complex and often cannot be detected without significant new work. For example, there is no tracking of the PIDs holding shared locks, only exclusive locks. Deadlocks can occur due to chains of locks across multiple processes ( e.g. 5 or 6 or more ) that loop back in on themselves. Detecting the loop is the hard part. This is known as 'deadlock detection'. It's the same sort of deadlock detection commercial SQL databases use to implement transactions and rollback. 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