From owner-freebsd-current  Sun Feb 28 11: 8:51 1999
Delivered-To: freebsd-current@freebsd.org
Received: from bolero-x.rahul.net (bolero.rahul.net [192.160.13.1])
	by hub.freebsd.org (Postfix) with SMTP id AFE1715272
	for <current@FreeBSD.ORG>; Sun, 28 Feb 1999 11:08:49 -0800 (PST)
	(envelope-from dhesi@rahul.net)
Received: from waltz.rahul.net by bolero-x.rahul.net with SMTP id AA23100
  (5.67b8/IDA-1.5 for <current@FreeBSD.ORG>); Sun, 28 Feb 1999 11:08:32 -0800
Received: by waltz.rahul.net (5.67b8/jive-a2i-1.0)
	id AA09561; Sun, 28 Feb 1999 11:08:29 -0800
Message-Id: <199902281908.AA09561@waltz.rahul.net>
To: current@FreeBSD.ORG
Subject: Re: lockmgr panic with mmap() 
In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> 
   of Sun, 28 Feb 99 23:52:57 +1100
Date: Sun, 28 Feb 99 11:08:29 -0800
From: Rahul Dhesi <dhesi@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

> 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