public inbox for cluster-cvs@sourceware.org
help / color / mirror / Atom feed
From: bmarzins@sourceware.org
To: cluster-cvs@sources.redhat.com
Subject: cluster/gfs-kernel/src/gfs ops_inode.c
Date: Fri, 09 Sep 2005 16:54:00 -0000	[thread overview]
Message-ID: <20050909165425.7132.qmail@sourceware.org> (raw)

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	bmarzins@sourceware.org	2005-09-09 16:54:25

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 O_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.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.6&r2=1.6.2.1


             reply	other threads:[~2005-09-09 16:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09 16:54 bmarzins [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-11 22:15 rpeterso
2007-07-11 21:58 rpeterso
2007-06-29 21:57 rpeterso
2007-06-05 18:21 wcheng
2007-06-05 17:46 wcheng
2007-01-18 20:40 wcheng
2006-10-23 20:47 bmarzins
2006-10-15  7:25 wcheng
2006-10-03 17:27 rohara
2006-03-08 20:47 bmarzins
2005-09-27 22:51 cfeist
2005-09-27 18:45 bmarzins
2005-09-27 18:44 bmarzins
2005-09-27 18:36 bmarzins
2005-09-09 19:22 bmarzins
2005-08-31  4:33 teigland

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=20050909165425.7132.qmail@sourceware.org \
    --to=bmarzins@sourceware.org \
    --cc=cluster-cvs@sources.redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).