Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Feb 1999 12:40:18 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Rahul Dhesi <dhesi@rahul.net>
Cc:        current@FreeBSD.ORG
Subject:   Re: lockmgr panic with mmap() 
Message-ID:  <199902282040.MAA39025@apollo.backplane.com>
References:   <199902281908.AA09561@waltz.rahul.net>

next in thread | previous in thread | raw e-mail | index | archive | help
: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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902282040.MAA39025>