Bug 450209

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?

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.

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"

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?

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.

If nothing uses it, can't we just ditch it entirely then?

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/

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

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.

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