From owner-freebsd-stable@FreeBSD.ORG Thu Aug 4 03:24:06 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AE1F16A41F; Thu, 4 Aug 2005 03:24:06 +0000 (GMT) (envelope-from howard@163.com) Received: from 163.com (bj44-212.i.netease.com [202.108.44.212]) by mx1.FreeBSD.org (Postfix) with SMTP id 026B743D46; Thu, 4 Aug 2005 03:24:03 +0000 (GMT) (envelope-from howard@163.com) Received: from h (unknown [61.135.152.194]) by smtp4 (Coremail) with SMTP id LYCk2ASK8ULw0SUK.1 for ; Thu, 04 Aug 2005 11:22:47 +0800 (CST) X-Originating-IP: [61.135.152.194] To: freebsd-stable@freebsd.org Date: Thu, 04 Aug 2005 11:23:54 +0800 From: "Howard.Wang" Organization: ChinaACG Content-Type: text/plain; format=flowed; delsp=yes; charset=gb18030 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.0 (Win32, build 7561) Cc: delphij@freebsd.org Subject: Mysterous fork related panic with RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 03:24:06 -0000 Hi, Guys, Recently I have found a mysterous fork related panic with RELENG_5 which does not affect -HEAD. With some track down we have simplified the program to trigger the kernel map exhausting: The program fork(2)'s only one child, then sleep; and the child will do the same thing, until a designated depth. On RELENG_5, a depth of 252 would be enough to trigger the panic within a Xeon box equipped with 3.2GB of RAM (actually 4GB, but PAE is not enabled so kernel drops part of the memory). We tried the same experiment on other boxes, with different CPU/Memory Type/ Memory Size/Storage Controller, and the panic can be reliabily reproduced. However, fortunatelly, it seems that 7.0-CURRENT is not affected. A further investigation about KVA_PAGES, and other related KMEM settings in the kernel configuration shows that they do little about the panics. It seems that user_ldt_alloc() in sys/i386/i386/sys_machdep.c is getting a quickly increasing parameter of 'len', which will then translate to a failed kmem_alloc (due to exhaustion of the kernel map), and subsequently, a NULL pointer deference with panic "Could not copy LDT", in line 255 of sys/i386/i386/vm_machdep.c (RELENG_5_4). //Below is a copy of the trigger program (executed as "./chain_fork 1024 1 15") /* chain_fork.c 1.0 by Howard. */ #include #include #include #include #include int main(int argc, char** argv) { int N,M,T; int pid; char *p; int j; if(argc!=4) { printf("Usage: %s \n",argv[0]); return (0); } N = atoi(argv[1]); //How many depth. M = atoi(argv[2])*1024*1024; //Size per Proc. T = atoi(argv[3]); //Life per Proc. while(N>0) { pid = fork(); if (pid != 0) { p = malloc(M); memset(p,0,M); sleep(T); exit(0); } else { printf("I forked a child No.%d\n",N); N--; } } return (0); } /* end of file */ --- regards, Howard.wang