Thanks! 

We changed the IOCTL numbers for the 2.8.2 version, and they both load
concurrently now. 

This is just a temporary solution for us, until the migrations are done, and
then we will revert back to the standard pvfs2 and IOCTL numbers.

The patch is below:

Index: src/io/dev/pint-dev-shared.h
===================================================================
--- src/io/dev/pint-dev-shared.h        (revision 19181)
+++ src/io/dev/pint-dev-shared.h        (revision 19182)
@@ -97,13 +97,13 @@

 #define PVFS_DEV_MAGIC 'k'

-#define DEV_GET_MAGIC           0x1
-#define DEV_GET_MAX_UPSIZE      0x2
-#define DEV_GET_MAX_DOWNSIZE    0x3
-#define DEV_MAP                 0x4
-#define DEV_REMOUNT_ALL         0x5
-#define DEV_DEBUG               0x6
-#define DEV_MAX_NR              0x7
+#define DEV_GET_MAGIC           0x8
+#define DEV_GET_MAX_UPSIZE      0x9
+#define DEV_GET_MAX_DOWNSIZE    0xA
+#define DEV_MAP                 0xB
+#define DEV_REMOUNT_ALL         0xC
+#define DEV_DEBUG               0xD
+#define DEV_MAX_NR              0xE

 /* supported ioctls, codes are with respect to user-space */
 enum {


-----Original Message-----
From: Phil Carns [mailto:[email protected]] 
Sent: Monday, March 29, 2010 9:25 AM
To: [email protected]
Cc: 'Rob Latham'; [email protected]
Subject: Re: [Pvfs2-developers] PVFS 2.8.2 kernel panics

I'm guessing it may be a conflict in the ioctl numbers across the two 
modules.  It looks like the compat registration function is global:

http://lxr.linux.no/#linux-bk+v2.6.9/fs/compat.c#L310

Maybe there is something in the error handling after that point that 
caused the actual panic.

We probably need to keep the old style conversion code in the official 
releases to be safe.  It sounds like it would be safe to remove in your 
environment, though, or maybe you could try picking different ioctl numbers?

-Phil

David Metheny wrote:
> We've changed pvfs 2.8.2 a bit, so we can have it installed side-by-side
on
> a client with pvfs 2.6.x. This basically meant that files needed to be
> renamed, slab cache names had to be unique, and the file system type
needed
> to be unique. In our case, we used pvfs28 instead of pvfs2. This will give
> us a transition period to allow clients to access both types of file
systems
> while the many (50+) file systems we have are upgraded over time.
> 
> While these changes work for RHEL3 i386, RHEL4 U7/U8 i386, RHEL5 U3/U4
> i386/x86_64, it kernel panics on RHEL4 U8 x86_64. In this case, it appears
> to be conflicting on the ioctl32_registration between the 2.6.x and 2.8.2
> versions. 
> 
> We've validated the following with ioctl32_registration active
> 1) 2.6.x and 2.8.2 load and unload fine individually (i.e if not loaded at
> the same time)
> 2) Both 2.6.x and 2.8.2 have ioctl32 registration, kernel panic on load of
> 2nd module, regardless of which module is loaded last. 
> 3) If 2.8.2 is the only module not doing ioctl32_registration, then both
> modules can be loaded at the same time.
> 4) If 2.6.x is the only module not doing ioctl32_registration, then both
> modules can be loaded at the same time. 
> 5) If both 2.6.x and 2.8.2 are not doing ioctl32_registration, both module
> can be loaded at the same time. 
> 
> I'm guessing at this point there is some bug in the RHEL4 U8 x86_64
causing
> it not to work on this system only.
> 
> If I can guarantee that we have 64bit for both client and kernel module
(or
> both 32bit), do you see any reason I can't just remove the
> ioctl32_registration?
> 
> Also, does the ioctl32_registration functionality seem like something you
> all want to keep in your trunk? I'm still a bit confused on config_compat
> vs. ioctl32_registration, so I probably just don't understand. 
> 
> 
> -----Original Message-----
> From: Rob Latham [mailto:[email protected]] 
> Sent: Thursday, March 25, 2010 10:06 AM
> To: David Metheny
> Cc: [email protected]; [email protected]
> Subject: Re: [Pvfs2-developers] PVFS 2.8.2 kernel panics
> 
> On Thu, Mar 25, 2010 at 08:56:40AM -0500, David Metheny wrote:
>> Is the register_ioctl32_conversion still needed anymore? I'm not sure
when
>> CONFIG_COMPAT comes into play, or if that is the replacement
functionality
>> for ioctl32 conversions. 
> 
> The one case where you need register_ioctl32 is when you are running a
> 64 bit kernel, but you built pvfs2-client-core as a 32 bit executable. 
> 
> The PPC64 bi-arch toolchain, for example, defaults to 32 bit.  You
> have to build with "-m64" in your CFLAGS (and LDFLAGS? I forget) to
> get a 64 bit binary.
> 
> ==rob
> 

_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to