public inbox for cluster-cvs@sourceware.org
help / color / mirror / Atom feed
* cluster/gfs-kernel/src/gfs ops_export.c ops_in ...
@ 2007-06-05  5:43 wcheng
  0 siblings, 0 replies; 4+ messages in thread
From: wcheng @ 2007-06-05  5:43 UTC (permalink / raw)
  To: cluster-cvs

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

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

Log message:
	Bugzilla 236565:
	
	Fix a GFS panic found in NFS SPECsfs benchmark runs. The crash is caused
	by a race between GFS lookup code and VM cache reclaim logic kicked off
	under memory pressure. At the end of the lookup, gfs releases inode glock
	pre-maturely. This creates a window inside the bottom portion of logic
	that could make gfs_iget to update the associated GFS inode structure that
	has been freed. Depending on who gets the new memory, unspecified corruptions
	occur. In this case, it corrupts TCP buffer head that ends up over-running
	NFSD kernel stack after 2-3 hours of benchmark runs.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_export.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.8.2.2&r2=1.8.2.3
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&r2=1.15.2.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* cluster/gfs-kernel/src/gfs ops_export.c ops_in ...
@ 2007-06-08 16:12 wcheng
  0 siblings, 0 replies; 4+ messages in thread
From: wcheng @ 2007-06-08 16:12 UTC (permalink / raw)
  To: cluster-cvs

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL45
Changes by:	wcheng@sourceware.org	2007-06-08 16:12:38

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

Log message:
	Bugzilla 243146 (clone of bug #242720 for RHEL 4.5 z-stream):
	
	There is a race between GFS lookup code and inode cache reclaim logic that
	would create a window to allow GFS to corrupt its (GFS) inode cache. The
	occurrence is rare and only happens when gfs_inode_destroy() is invoked
	(mostly under memory pressure such that VM starts to free its inode cache
	entries). Depending on who gets the freed memory, the result can't be specified.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_export.c.diff?cvsroot=cluster&only_with_tag=RHEL45&r1=1.3.2.4&r2=1.3.2.4.2.1
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL45&r1=1.6.2.6&r2=1.6.2.6.2.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* cluster/gfs-kernel/src/gfs ops_export.c ops_in ...
@ 2007-06-05 18:43 wcheng
  0 siblings, 0 replies; 4+ messages in thread
From: wcheng @ 2007-06-05 18:43 UTC (permalink / raw)
  To: cluster-cvs

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2007-06-05 18:43:53

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

Log message:
	Bugzilla 242720
	
	Fix a race between GFS lookup code and VM cache reclaim logic kicked off
	under memory pressure. At the end of the lookup, gfs releases inode glock
	pre-maturely.  This creates a window inside the bottom portion of logic
	that could make gfs_iget updating the associated GFS inode memory that
	has been freed. Depending on who gets the new memory, unspecified corruptions
	occur.
	
	In the case where this bug is found (RHEL5 bugzilla 236565), it corrupts
	TCP buffer head that ends up trashing nfsd kernel stack.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_export.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.3.2.4&r2=1.3.2.5
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.6&r2=1.6.2.7


^ permalink raw reply	[flat|nested] 4+ messages in thread

* cluster/gfs-kernel/src/gfs ops_export.c ops_in ...
@ 2007-06-05 18:15 wcheng
  0 siblings, 0 replies; 4+ messages in thread
From: wcheng @ 2007-06-05 18:15 UTC (permalink / raw)
  To: cluster-cvs

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

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

Log message:
	Bugzilla 236565
	
	Fix a race between GFS lookup code and VM cache reclaim logic kicked off
	under memory pressure. At the end of the lookup, gfs releases inode glock
	pre-maturely.  This creates a window inside the bottom portion of logic
	that could make gfs_iget updating the associated GFS inode structure that
	has been freed. Depending on who gets the new memory, unspecified corruptions
	occur.
	
	In the case where this bug is found, it corrupts TCP buffer head that ends
	up trashing nfsd kernel stack.

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-06-08 16:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-05  5:43 cluster/gfs-kernel/src/gfs ops_export.c ops_in wcheng
2007-06-05 18:15 wcheng
2007-06-05 18:43 wcheng
2007-06-08 16:12 wcheng

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