Date: Sun, 28 Feb 99 11:08:29 -0800 From: Rahul Dhesi <dhesi@rahul.net> To: current@FreeBSD.ORG Subject: Re: lockmgr panic with mmap() Message-ID: <199902281908.AA09561@waltz.rahul.net> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> of Sun, 28 Feb 99 23:52:57 %2B1100
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
> Date: Sun, 28 Feb 99 23:52:57 +1100
> From: Bruce Evans <bde@zeta.org.au>
> To: current@FreeBSD.ORG, pangolin@home.com
> Message-Id: <199902281252.XAA24877@godzilla.zeta.org.au>
> Subject: Re: lockmgr panic with mmap()
> >The attached program sometimes causes a lockmgr panic. I do not think is always
> >did. I am running 4.0-CURRENT form Feb 19.
> >
> >The trace is:
> > panic lockmgr: locking against self
> > lockmgr
> > mv_map_growstack
> > grow_stack
> > trap_pfault
> > trap
> > calltrap
> > subyte
> > syscall
> > ...
> >
> >A command on a running image such as this usually does it, though I do not know what
> >conditions are neccessary:
> >
> > fincore /usr/local/netscape-4.5/communicator-4.5.bin
>
> Here is a simpler example.
>
> ---
> #include <sys/param.h>
> #include <sys/mman.h>
>
> #include <err.h>
> #include <stdlib.h>
>
> #define SIZE (32 * 1024 * 1024)
>
> int
> main(void)
> {
> void *p;
> char vec[SIZE / PAGE_SIZE];
>
> p = malloc(SIZE);
> if (mincore(p, SIZE, vec) != 0)
> err(1, "mincore");
> return (0);
> }
> ---
>
> mincore() locks the vmspace map, and initialises vec[] a byte at a time
> using subyte(). When vec[] is sufficiently large, it is not all in core
> initially and a page fault occurs in subyte(). The new stack growing
> code locks the vmspace map early and panics.
>
> Bruce
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
>
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?199902281908.AA09561>