This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue May 24 02:04:34 2022 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8IFl5X19595 for ; Wed, 18 Sep 2002 17:47:06 +0200 Received: (qmail 23345 invoked from network); 18 Sep 2002 07:05:29 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 18 Sep 2002 07:05:29 -0000 Received: (qmail 1399 invoked by uid 1000); 17 Sep 2002 20:44:11 -0000 Received: (maildatabase); juh Received: (qmail 12173 invoked by alias); 9 Nov 2001 19:37:34 -0000 Received: (qmail 12155 invoked from network); 9 Nov 2001 19:37:33 -0000 Received: from vvtp.tn.tudelft.nl (HELO vvtp.nl) (qmailr@::ffff:130.161.252.29) by spaans.ds9a.nl with SMTP; 9 Nov 2001 19:37:33 -0000 Received: (qmail 19380 invoked by uid 2547); 9 Nov 2001 19:37:31 -0000 Received: (qmail 19208 invoked from network); 9 Nov 2001 19:37:29 -0000 Received: from vger.kernel.org (199.183.24.194) by vvtp.tn.tudelft.nl with SMTP; 9 Nov 2001 19:37:29 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 9 Nov 2001 14:34:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 9 Nov 2001 14:34:50 -0500 Received: from smtp.storageapps.com ([63.101.83.13]:59666 "EHLO sa-bwmail1.storageapps.com") by vger.kernel.org with ESMTP id convert rfc822-to-8bit; Fri, 9 Nov 2001 14:34:39 -0500 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 14:31:46 -0500 Message-Id: <23D04BDBA646D411BDDD00D0B774B539046028B7@SA-BWMAIL1> From: "Christian, Chip" To: =?iso-8859-1?Q?=27Peter_W=E4chtler=27?= , linux-xfs@oss.sgi.com Cc: lkml Subject: RE: NFS hit me (2.4.9-xfs) again Date: Fri, 9 Nov 2001 14:31:45 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Tag: 1 Lines: 124 The reason that dput was dropped in 2.4.10 is that there's another one that also gets executed, causing the kernel oops right after the if (!pdentry) { } code block. I think you have a filesystem in need of repair. RedHat ships this patch with their 2.4.9 kernels: --- linux/fs/nfsd/nfsfh.c~ Fri Aug 17 21:30:25 2001 +++ linux/fs/nfsd/nfsfh.c Fri Aug 17 21:30:40 2001 @@ -275,7 +275,6 @@ d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ - dput(tdentry); pdentry = ERR_PTR(-EINVAL); } if (!pdentry) { -----Original Message----- From: Peter Wächtler [mailto:pwaechtler@loewe-komp.de] Sent: Friday, November 09, 2001 5:01 To: linux-xfs@oss.sgi.com Cc: lkml Subject: NFS hit me (2.4.9-xfs) again Unable to handle kernel NULL pointer dereference at virtual address 00000000 00000000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<00000000>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000000 ebx: c9c0d7e0 ecx: 00000000 edx: c03a7b00 esi: c9c0d560 edi: c9c0d7e0 ebp: c9c0d7e0 esp: cbddde84 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 233, stackpage=cbddd000) Stack: c01729f4 cc97f420 c9c0d560 00000005 cdc40a00 c0172e56 c9c0d7e0 00000005 cd390200 cd390000 cbed2000 cbdddf20 cdc40be8 cd390200 c0173199 cdc40a00 cd390010 00000005 00000001 00000001 00000008 cbe17e00 cbee48c0 cd390200 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; c01729f4 Trace; c0172e56 Trace; c0173199 Trace; c0173ad2 Trace; c017843d Trace; c017173c Trace; c0171003 Trace; c0240318 Trace; c0170dab Trace; c010557f This is not the initial crash location - the machine was dead (and no serial console yet). But after restarting, about 6-10 clients tried to reconnect to NFSD and caused the crash. The crash appears because "child->d_inode->i_op->lookup == NULL" struct dentry *nfsd_findparent(struct dentry *child) { struct dentry *tdentry, *pdentry; tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0}); if (!tdentry) return ERR_PTR(-ENOMEM); /* I'm going to assume that if the returned dentry is different, then * it is well connected. But nobody returns different dentrys do they? */ /* added safety check to prevent crash - peewee */ if (child->d_inode->i_op && child->d_inode->i_op->lookup){ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); } else { printk("normally we had been crashing\n"); printk("child: %p\n",child); printk("child->d_inode: %p\n",child->d_inode); printk("child->d_inode->i_op: %p\n",child->d_inode->i_op); printk("child->d_inode->i_op->lookup: %p\n",child->d_inode->i_op->lookup); return( ERR_PTR(-EINVAL) );  } d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ dput(tdentry); ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ this one was removed in 2.4.10 pdentry = ERR_PTR(-EINVAL); } if (!pdentry) { /* I don't want to return a ".." dentry. * I would prefer to return an unconnected "IS_ROOT" dentry, [...] If I use 2.4.12-xfs (with nfs-utils 0.3.3), clients can't create an archive with "ar": [ strace output of "ar" creating a lib out of several *.o] write(5, "\0\0\1\2\0\0H\2\0\0\1\2\0\0L\2\0\0\1\2\0\0P\2\0\0\1\2\0"..., 3254) = 3 close(5) = 0 munmap(0x4001f000, 4096) = 0 lstat64("lumenuila.a", {st_mode=S_IFREG|0644, st_size=8, ...}) = 0 rename("stO1wjGV", "lumenuila.a") = -1 ESTALE (Stale NFS file handle) My main question is: Is it possible that some interaction with xfs<->nfsd causes this kind of trouble? Especially when lookup("..") fails - and dealing with "disconnected dentries". Does the nfs_fh carry not enough information ( when is oldfh used, when the newer one? [ref_fh->fh_handle.fh_version == 0xca]). So we have an inode with no proper inode_operations, huh? I don't use NFSv3, should I? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/