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 <b...@zeta.org.au> > To: curr...@freebsd.org, pango...@home.com > Message-Id: <199902281252.xaa24...@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 majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message