Bug 450209 - use forked gfs1-specific lock modules
use forked gfs1-specific lock modules
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-kmod (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Abhijith Das
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-05 17:27 EDT by David Teigland
Modified: 2010-01-11 22:28 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:18:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
First draft: Merge gfs1-specific lock modules into gfs1 (61.30 KB, patch)
2008-07-14 01:30 EDT, Abhijith Das
no flags Details | Diff
second attempt patch (61.21 KB, patch)
2008-07-31 15:11 EDT, Abhijith Das
no flags Details | Diff
upstream patch: lock modules patch + fixes to build gfs1 with upstream kernel (89.74 KB, patch)
2008-08-10 18:12 EDT, Abhijith Das
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0132 normal SHIPPED_LIVE gfs-kmod bug-fix update 2009-01-20 11:04:57 EST

  None (edit)
Description David Teigland 2008-06-05 17:27:14 EDT
Description of problem:

Lock modules being forked for gfs1/gfs2.  Adding harness (locking.c)
to gfs1 for lock modules to use.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Abhijith Das 2008-07-14 01:30:08 EDT
Created attachment 311682 [details]
First draft: Merge gfs1-specific lock modules into gfs1

After discussing with Dave, here's my patch to port the lock modules for gfs1
into gfs-kernel. I was able to compile the code with this patch. Comments?
Comment 2 RHEL Product and Program Management 2008-07-14 09:41:06 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 Abhijith Das 2008-07-31 15:11:39 EDT
Created attachment 313124 [details]
second attempt patch

The lock_dlm in gfs1 and the lock_dlm.ko (from gfs2-kmod) don't play along
nicely because both attempt to register a kset with the name "lock_dlm" in
sysfs causing sysfs to panic. This patch changes the name of the kset used by
gfs' lock_dlm to "lock_dlm_gfs"
Comment 4 Steve Whitehouse 2008-08-04 04:37:23 EDT
Is it possible to change the name of the kset (as per comment #3) without causing a user interface change? Does this imply any changes in gfs_controld for example?
Comment 5 Abhijith Das 2008-08-04 10:34:03 EDT
The kset_register function registers the kset under /sys/kernel/lock_dlm_gfs. (gfs2's lock_dlm gets registered as /sys/kernel/lock_dlm). Other than registering the kset and creating an empty directory with this name under /sys/kernel, kset_register doesn't do much else. (It was during this creation of /sys/kernel/lock_dlm that we had a conflict; kset_register would return -EEXIST)

All the filesystem-specific sysfs objects are created under /sys/fs/gfs/<clustername:fsname>/lock_module/ during mount and is unaffected by this change in kset_name.
Comment 6 Steve Whitehouse 2008-08-04 10:44:43 EDT
If nothing uses it, can't we just ditch it entirely then?
Comment 7 Abhijith Das 2008-08-04 10:59:03 EDT
That's the unfortunate part. kset_register() does 2 things:
1. register the kset internally so it keeps a definition of the kset
2. create the directory in /sys/kernel/

The functions that perform 1 and 2 are not exported individually; I couldn't get it to register the kset but not create the empty directory in /sys/kernel/
Comment 8 Steve Whitehouse 2008-08-04 11:06:14 EDT
What is the point of the kset if its just creating an empty directory and not related to the userland interface? Afaik a kset is just a container for related kobjects, so if there are none, why do we need a container for them? Maybe I'm missing something...
Comment 9 Abhijith Das 2008-08-10 18:12:02 EDT
Created attachment 313900 [details]
upstream patch: lock modules patch + fixes to build gfs1 with upstream kernel

This patch contains the lock modules patch (ported from the RHEL5 patch in comment #3) and the following fixes to make gfs1 build with Steve's git tree.

- change all instances of <asm/semaphore.h> to <linux/semaphore.h>
- change all calls to permission() to inode_permission()
- change all calls to remote_llseek() to generic_file_llseek_unlocked()

I have been able to successfully compile with the patch against Steve's git tree, insmod the gfs.ko module, and mount a nolock filesystem using it. I don't have a cluster running upstream bits, so I couldn't test the module in a cluster.

If nobody has objections to this patch, I'll check it in.
Comment 12 errata-xmlrpc 2009-01-20 16:18:30 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0132.html

Note You need to log in before you can comment on or make changes to this bug.