cluster/gfs-kernel/src/gfs ops_inode.c

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	bmarzins@sourceware.org	2006-10-23 20:47:23

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://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&r1=1.14&r2=1.15

cluster/gfs-kernel/src/gfs ops_inode.c

[rpeterso]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL51
Changes by:	rpeterso@sourceware.org	2007-07-11 22:15:22

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Resolves: bz #241096: GFS: bug in gfs truncate

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL51&r1=1.15.2.2&r2=1.15.2.2.2.1

cluster/gfs-kernel/src/gfs ops_inode.c

[rpeterso]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL5
Changes by:	rpeterso@sourceware.org	2007-07-11 21:58:53

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Resolves: bz #241096: GFS: bug in gfs truncate

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.15.2.2&r2=1.15.2.3

cluster/gfs-kernel/src/gfs ops_inode.c

[rpeterso]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	rpeterso@sourceware.org	2007-06-29 21:57:23

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Resolves: bz 241096: GFS: bug in gfs truncate

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&r1=1.18&r2=1.19

cluster/gfs-kernel/src/gfs ops_inode.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2007-06-05 18:21:23

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Bugzilla 242759:
	
	Bump into this problem while debugging bug #236565 (GFS SPECsfs panic).
	Apparently a minor oversight while adding new function into GFS for
	RHEL5. GFS versions <= RHEL4 is immuned from this issue.
	
	Upon memory pressure, VM starts to release inode cache entries that would
	fail gfs iget. GFS1 flags this error as "ENOMEM" but returns from gfs_create
	call without releasing the glock.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&r1=1.17&r2=1.18

cluster/gfs-kernel/src/gfs ops_inode.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL5
Changes by:	wcheng@sourceware.org	2007-06-05 17:46:38

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Bugzilla 242759
	
	Upon memory pressure, vm could start to release inode cache entries.
	Any process trying to get an inode during this time period will fail.
	GFS flags the error as "ENOMEM" but leaves gfs_create() call without
	unlocking the associated directory and file glocks. This patch fixes
	this minor coding oversight.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.15.2.1&r2=1.15.2.2

cluster/gfs-kernel/src/gfs ops_inode.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2007-01-18 20:40:12

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	bugzilla 190475 (rename 3-2):
	
	This patch fixes:
	Current rename doesn't lock the (to be deleted) source file during
	rename operation unless the source is a directory. This issue would
	not show up in a single node case since VFS layer has done its i_sem/
	i_mutex locks for both directories and involved files.
	
	This patch excludes a previous proposed change (in the draft patch sent
	out for review in cluster-devel list) that adds gfs rename global lock
	to prevent a rare case of cluster deadlock. Since cluster rename global
	lock is very expensive, we prefer to find other means to fix that issue.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.6.2.4&r2=1.6.2.5

cluster/gfs-kernel/src/gfs ops_inode.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2006-10-15 07:25:14

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Just found 2.6.18 kernel has something called down_read_non_onwer for
	rwsemaphore. If we can implement a similar function that does something
	like "up_write_if_owner", then we can put i_alloc_sem back to correct
	state. Correct the comment and mark this possibility.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&r1=1.13&r2=1.14

cluster/gfs-kernel/src/gfs ops_inode.c

[rohara]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	rohara@sourceware.org	2006-10-03 17:27:34

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Added gfs_security_init to initialize SELinux xattrs for newly created
	inodes.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&r1=1.11&r2=1.12

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

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 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://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.6.6.1.2.2&r2=1.6.6.1.2.3

cluster/gfs-kernel/src/gfs ops_inode.c

[cfeist]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U2
Changes by:	cfeist@sourceware.org	2005-09-27 22:51:09

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	Reverted Ben's earlier change as it will not make RHEL4U2.

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

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	bmarzins@sourceware.org	2005-09-27 18:26:45

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	fix for bug 169039. GFS no longer checks permissions before truncating a
	file in gfs_setattr.  I don't know what this check was ever added (It didn't
	exist in gfs 6.0). Since I don't know why the check was added, I can't say
	for certain that it is unessential.  However, I can't see any reason to do
	it, so I commented it out.

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

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U2
Changes by:	bmarzins@sourceware.org	2005-09-27 18:25:21

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	fix for bug 169039. GFS no longer checks permissions before truncating a
	file in gfs_setattr.  I don't know what this check was ever added (It didn't
	exist in gfs 6.0). Since I don't know why the check was added, I can't say
	for certain that it is unessential.  However, I can't see any reason to do
	it, so I commented it out.

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

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	bmarzins@sourceware.org	2005-09-27 18:19:31

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	fix for bug 169039. GFS no longer checks permissions before truncating a
	file in gfs_setattr.  I don't know what this check was ever added (It didn't
	exist in gfs 6.0). Since I don't know why the check was added, I can't say
	for certain that it is unessential.  However, I can't see any reason to do
	it, so I commented it out.

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.2.1&r2=1.6.2.2

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U2
Changes by:	bmarzins@sourceware.org	2005-09-09 19:22:05

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=RHEL4U2&r1=1.6&r2=1.6.8.1

cluster/gfs-kernel/src/gfs ops_inode.c

[bmarzins]

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

cluster/gfs-kernel/src/gfs ops_inode.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-08-31 04:33:23

Modified files:
	gfs-kernel/src/gfs: ops_inode.c 

Log message:
	follow_link returns a pointer in 2.6.13

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