From: Bas van der Vlies <basv@sara.nl>
To: linux-kernel@vger.kernel.org
Subject: Re: Nfsd/gfs crashes/oops in 2.6.16-rc5
Date: Thu, 09 Mar 2006 08:43:35 +0100 [thread overview]
Message-ID: <440FDCA7.5050506@sara.nl> (raw)
In-Reply-To: <440EF1A7.8020400@sara.nl>
Bas van der Vlies wrote:
> uname: 2.6.16-rc5
> libc: libc-2.3.2.so
> Debian: Sarge
> SMP system: 2 CPU's
>
> On our 4 node GFS-cluster we use nfs to export the GFS filesystems to
> our 640 node cluster On our fileserver nodes we get an nfs crash/oops.
> We tried serveral kernels and they crashes/oops are the same. We node
> installed 2.6.16-rc5 and here is the oops:
>
> nable to handle kernel NULL pointer dereference at virtual address 00000038
> printing eip:
> f89a4be3
> *pde = 37809001
> *pte = 00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in: lock_dlm dlm cman dm_round_robin dm_multipath sg
> ide_floppy ide_cd cdrom qla2xxx siimage piix e1000 gfs lock_harness dm_mod
> CPU: 0
> EIP: 0060:[<f89a4be3>] Tainted: GF VLI
> EFLAGS: 00010246 (2.6.16-rc5-sara3 #1)
> EIP is at gfs_create+0x6f/0x153 [gfs]
Is is an GFS-crash and just for the record the GFS guys have made a fix
in the CVS Stable branch:
CVSROOT: /cvs/cluster
Module name: cluster
Branch: STABLE
Changes by: bmarzins@sourceware.org 2006-03-08 20:47:09
Modified files:
gfs-kernel/src/gfs: ops_inode.c
Log message:
Really gross hack!!!
This is a workaround for one of the bugs the got lumped into 166701. It
breaks POSIX behavior in a corner case to avoid crashing... It's icky.
when NFS opens a file with O_CREAT, the kernel nfs daemon checks to see
if the file exists. If it does, nfsd does the *right thing* (either
opens the file, or if the file was opened with O_EXCL, returns an
error). If the file doesn't exist, it passes the request down to the
underlying file system. Unfortunately, since nfs *knows* that the file
doesn't exist, it doesn't bother to pass a nameidata structure, which
would include the intent information. However since gfs is a cluster
file system, the file could have been created on another node after nfs
checks for it. If this is the case, gfs needs the intent information to
do the *right thing*. It panics when it finds a NULL pointer, instead
of the nameidata. Now, instead of panicing, if gfs finds a NULL
nameidata pointer. It assumes that the file was not created with _EXCL.
This assumption could be wrong, with the result that an application
could thing that it has created a new file, when in fact, it has opened
an existing one.
--
--
********************************************************************
* *
* Bas van der Vlies e-mail: basv@sara.nl *
* SARA - Academic Computing Services phone: +31 20 592 8012 *
* Kruislaan 415 fax: +31 20 6683167 *
* 1098 SJ Amsterdam *
* *
********************************************************************
prev parent reply other threads:[~2006-03-09 7:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-08 15:00 Nfsd crashes/oops in 2.6.16-rc5 Bas van der Vlies
2006-03-09 7:43 ` Bas van der Vlies [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=440FDCA7.5050506@sara.nl \
--to=basv@sara.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.