: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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
