[OpenAFS-devel] question: binary interface to kernel module (RHEL6.2/6.3, openafs 1.6.1)?

[Marc Dionne]

On Wed, Aug 29, 2012 at 11:21 AM, Stephan Wiesand
<stephan.wiesand@desy.de> wrote:
> Hi All,
>
> this is just a question. I'm not asserting an openafs bug.
>
> Since SL6, we have we have been using "kABI tracking kmods" for installin=
g the OpenAFS kernel module on clients. For full information on this mechan=
ism, see http://people.redhat.com/jcm/el6/dup/docs/dup_book.pdf . In short,=
 you only have to compile and install the module once, and it will be used =
with future kernels as long as it doesn't use parts of the ABI that changed=
.
>
> Trying this may have been stupid in the first place. If so, happy bashing=
 :-)
>
> But in practice, it has worked perfectly for a long time. The modules bui=
lt against the EL6 GA kernel (2.6.32-71.el6) work fine with every released =
kernel up to the latest EL6.2 kernels (2.6.32-220.23.1.el6), on both 32-bit=
 and 64-bit systems.
>
> But with the EL6.3 update (2.6.32-279.el5), something changed that broke =
at least the interface to the 32-bit module. The symptoms are reads getting=
 stuck at the very beginning, except for very small files. The reads can be=
 interrupted, but the client can no longer be stopped cleanly.

Anything interesting in the syslog when this occurs?

> Using a module built against the 6.3 kernel with pre-6.3 ones has worse e=
ffects. BUGs, panics, spontaneous reboots.
>
> All this was only observed on 32-bit systems, and only if the cache is on=
 ext4. I have a suspicion that it might be related to a change described he=
re: http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/ . Qu=
ote: << a patch against ext4 to "return 32/64-bit dir name hash according t=
o usage type". Prior to that, ext2/3/4 would return a 32-bit hash value fro=
m telldir()/seekdir() [. . .] That patch was for kernel v3.3-rc2. To make t=
hings more fun, [. . .] merged in that patch in 2.6.32-268.el6 >>
>
> The direct link to the patch is http://git.kernel.org/?p=3Dlinux/kernel/g=
it/stable/linux-stable.git;a=3Dcommit;h=3Dd1f5273e9adb40724a85272f248f210dc=
4ce919a .
>
> Does anyone familiar withe the openafs module's inner workings see whethe=
r that patch would have the effects described above, on 32-bit systems only=
?
>
> Thanks a lot in advance for any insights.
>
>         Stephan

Offhand I don't see anything in that change that should affect
openafs.  Within the kernel module each cache file is looked up up
individually with a full path that it receives from afsd - the
directory scanning is done by afsd in user space using readdir.  The
lookup returns a dentry which is then converted to a file handle by
the underlying file system's own conversion function.  The file
handles for all cache files are stored in memory by the module.  When
a file is used, the file handle is converted to a dentry with the fs's
conversion function, and the file is opened with dentry_open.  Any
other changes to ext4 in that update?

Does the module work correctly on this system, with ext4, if it is recompil=
ed?

Marc