Bug 465158

Summary:	GFS: madvise system call causes assertion
Product:	[Retired] Red Hat Cluster Suite	Reporter:	Chris Feist <cfeist>
Component:	GFS-kernel	Assignee:	Chris Feist <cfeist>
Status:	CLOSED DUPLICATE	QA Contact:	Cluster QE <mspqa-list>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	4	CC:	bkahn, cfeist, edamato, kanderso, nstraz, rpeterso, swhiteho
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-10-02 18:42:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Feist 2008-10-01 20:43:18 UTC

+++ This bug was initially created as a clone of Bug #465151 +++

Description of problem:

Since the madvise system call was enabled by the patch to bug 429343, it's possible for a inode glock holder to never get dequeued through gfs_readpage. This causes an assertion (bug 464837)

GFS: fsid=cl102a:gfs1.1: warning: assertion "(gh->gh_flags & LM_FLAG_ANY) || (tmp_gh->gh_flags & LM_FLAG_ANY)" failed
GFS: fsid=cl102a:gfs1.1: function = add_to_queue
GFS: fsid=cl102a:gfs1.1: file = /builddir/build/BUILD/gfs-kmod-0.1.23/_kmod_build_/src/gfs/glock.c, line = 1418
GFS: fsid=cl102a:gfs1.1: time = 1222739610

I can't think of a way to make madvise work, and reverting the patch mentioned above and returning ENOSYS to madvise is the currently proposed solution to this problem.

I'll post a patch as soon as I verify that everything works as expected.

Comment 2 Kiersten (Kerri) Anderson 2008-10-02 18:42:46 UTC

Turns out we fixed this one the easy way for rhel 4 in the first place, so no z-stream request is required.  Closing this as a duplicate of the original bug fix.

*** This bug has been marked as a duplicate of bug 444912 ***