Bug 132772
Summary: | GFS OOPSes when a lock module returns an error on mount | ||
---|---|---|---|
Product: | [Retired] Red Hat Cluster Suite | Reporter: | Corey Marthaler <cmarthal> |
Component: | gfs | Assignee: | michael conrad tadpol tilstra <mtilstra> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | GFS Bugs <gfs-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-27 21:23:02 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
Corey Marthaler
2004-09-16 20:26:40 UTC
the oops isn't happening in gulm. It seems to be either up in gfs or perhap up in the vfs after gulm returns an error on mount. Still, it does seem the fault of gulm. I'm making a guess that when gulm returns a mount error, it leaves many of the other params untouched. And perhaps gfs is trying to dereference those. maybe. will dig more. Not a gulm bug. Lock modules returning errors to gfs on mount panic. If you make the first line of the mount function in the nolock module to return an error, you get the same OOPS. Yes, it is a gulm bug. In Linux error numbers are negative. lock_gulm is returning a positive error number (1003) which GFS passes up to the VFS. The VFS interprets the positive number as not being a error and continues on. Nolock only causes the same oops if you have it return a positive error number. VFS does weird things with the error results, so before we try to return a gulm error code, flip it to -1 fix verified. |