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
