Date: Wed, 17 Apr 2002 10:31:56 -0700 (PDT) From: "Dorr H. Clark" <dclark@applmath.scu.edu> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/36504: crash/panic vm_object_allocate under file system code w/fix Message-ID: <Pine.GHP.4.21.0204171024110.1958-100000@hpux38.dc.engr.scu.edu> In-Reply-To: <Pine.GHP.4.21.0204161008310.11529-100000@hpux38.dc.engr.scu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Apr 2002, Matt Dillon wrote:
> Second problem: vm_object_allocate() assumes that the zalloc()
> will succeed. The system must be crashing in there, before
> your defensive check.
Mr. Dillon, you are right about that. I had an incomplete back
trace that someone else wrote down, and they missed the top symbol.
I added the following diff to the PR to cover this oversight:
--- /usr/src/sys/vm/vm_object.c Fri Aug 4 15:31:11 2000
+++ ./vm_object.c Tue Apr 9 20:44:39 2002
@@ -223,9 +223,8 @@
{
vm_object_t result;
- result = (vm_object_t) zalloc(obj_zone);
-
- _vm_object_allocate(type, size, result);
+ if ((result = (vm_object_t) zalloc(obj_zone)))
+ _vm_object_allocate(type, size, result);
return (result);
}
The back trace that occurs WITHOUT this change is here:
_vm_object_allocate+d(2,0,0)
vm_object_allocate+24
vnode_pager_alloc+b1
vop_stdcreatevobject+d4
vop_defaultop+15
ufs_vnoperate+15
vfs_object_create+32
vn_open+14b
open+b8
syscall2+1f1
> Ok, I've looke at this some more. The second part of the patch
> created a little confusion
I'm sorry about the grody patch, I hadn't used the bug system before
and I started talking to it from a HPUX system. I've submitted
a better diff (i.e.- from FreeBSD) with a slightly different
change to vfs_default.c but the same idea.
> The only thing that can cause vm_object_allocate()
> to fail that I know of is if the system runs out of KVM.
I'm just running 4.4, I'm not familiar with -current,
but I thought the zone gets it's own KVM range when initialized.
Then if the free items on the zone drops below the low-water mark
it tries to malloc inside of _zget(), so it can get handed a NULL
back if the pages are gone. I believe the crash point is indeed
in _vm_object_allocate() when it dereferences the NULL, the other
two files are just changing to propagate the NULL tolerance
back up the calling chain.
So I thought your comment in the PR about low pages was right.
I believe running out of KVM is only a condition that would
occur on bootup.
> 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.
OK, will try to do, but it's rare.
Also, as you may know, savecore is busted in 4.4,
so the core files are not readable. I understand
the problem (savecore's trying to seek on a pipe)
but I'm having a little trouble back-porting the fix.
Thanks for your attention to this problem.
-dhc
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?Pine.GHP.4.21.0204171024110.1958-100000>