From owner-freebsd-bugs Wed Feb 21 15:20: 8 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0ED1637B503 for ; Wed, 21 Feb 2001 15:20:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f1LNK1252748; Wed, 21 Feb 2001 15:20:01 -0800 (PST) (envelope-from gnats) Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id E462E37B65D for ; Wed, 21 Feb 2001 15:15:26 -0800 (PST) (envelope-from mwm@mired.org) Received: (qmail 16435 invoked by uid 100); 21 Feb 2001 23:15:26 -0000 Message-Id: <20010221231526.16434.qmail@guru.mired.org> Date: 21 Feb 2001 23:15:26 -0000 From: mwm@mired.org Reply-To: mwm@mired.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/25266: fdesc file system in -STABLE locks up during nightly builds Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 25266 >Category: kern >Synopsis: fdesc file system in -STABLE locks up during nightly builds >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 21 15:20:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Mike Meyer >Release: FreeBSD 4.2-STABLE i386 >Organization: Meyer Consulting >Environment: fdesc in use on a 4.2-STABLE system, and daily_clean_disks_enable set to yes in /etc/periodic.conf This lockup only happens if periodic is run from cron; running it from the command line will not cause a problem. >Description: The system locks up every night a few seconds into the daily periodic run. The stack trace from ddb starts in the debugger, back through sc & atkbd, thence through the interrupt (presumably from my invoking DDB at the console). From there, it's: fdesc_readdir+0xe6(
,
, 0,
, 4, 0) getdirentries+0xf4(5 ) Xint0x80_syscall+0x2b According to gdb on the core dump, the fdesc_readdir is: 0xc019223e is in fdesc_readdir (../../miscfs/fdesc/fdesc_vnops.c:614). 609 while (i < sizeof(rootent) / sizeof(rootent[0]) && 610 uio->uio_resid >= UIO_MX) { 611 dt = &rootent[i]; 612 switch (dt->d_fileno) { 613 case FD_CTTY: 614 if (cttyvp(uio->uio_procp) == NULL) 615 continue; 616 break; 617 618 case FD_STDIN: On the face of it, the while loop in fdesc_readdir is simply broken. If you hit one of the continues in the loop (there are others further down), you have missed anything in the loop that might change either i or uip, meaning the loop doesn't terminate. It may be waiting on other events to change it, but somehow I doubt it for the fdesc code. Further, note that the code that is finding the continue in this case is checking for a controlling terminal, which would explain the difference in behavior between running periodic from cron vs from the command line. >How-To-Repeat: set daily_clean_disks_enable to YES in /etc/make.conf on a 4.2 box, mount fdesc, and watch it lock up. >Fix: It's not clear how to fix the code. I note that the last MFC of this code is over a year old, and the very next commit simply removed this code. Possibly MFC'ing a more recent version would solve the problem. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message