Bug 450209 - use forked gfs1-specific lock modules
use forked gfs1-specific lock modules
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-kmod (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Abhijith Das
Cluster QE
Depends On:
  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:
Last Closed: 2009-01-20 16:18:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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

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


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