Date: Tue, 2 Apr 2002 10:51:12 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: freebsd-bugs@FreeBSD.ORG, "Dorr H. Clark" <dclark@applmath.scu.edu> Subject: Re: kern/36504: crash/panic vm_object_allocate under file system code w/fix Message-ID: <200204021851.g32IpCu16951@apollo.backplane.com> References: <200204020819.g328JPJ21423@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, I've looke at this some more. The second part of the patch
created a little confusion because you diff'd the files backwards, but
I see what you are doing.
But there's a problem. Actually several problems. The biggest one is
that many filesystems, including UFS uses VM backing store heavily.
If the object creation fails, UFS is screwed up and so is any user
program that uses mmap() on the file in question. So we can't allow it
to fail.
Second problem: vm_object_allocate() assumes that the zalloc() will
succeed. The system must be crashing in there, before your defensive
check.
The only thing that can cause vm_object_allocate() to fail that I know
of is if the system runs out of KVM. If the system runs out of KVM the
system is in real trouble. I will make changes that check for the
zalloc failure and panic the system, but that's about the best I can do
for the moment.
What you need to do if you are experiencing crashes is to compile up a
debug kernel and obtain a crash dump. I should be able to diagnose
the cause of the crash from that.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204021851.g32IpCu16951>