[OpenAFS-devel] Kernel module recompilation, stability, etc.

[Kuba Ober]

> If you build a 2.4.2-2 module without the extradefs stuff, it will be
> broken. Likewise for any kernel with Alan Cox patches. The patch you
> submitted undoes the fixes for this instead of fixing the problem you're
> having. You need to find out why Makefile.extradefs isn't being created as
> an empty file, instead of suppressing it.

What goes into extradefs files? The default .rpm module doesn't have this 
file. I can obviously create it as an empty file, but will it help?

Another thing is the link-creation brokenness, and this is a valid bug I 
assume.

> Because you're not defining any of the stuff the Makefile.extradefs stuff
> works to define. It's not just there to make the build break, it does
> something. If you don't do the something, well, the module won't match the
> kernel you're running.

How would an empty makefile.extradefs file help here? The module that I 
obtain by recompiling works just as well (or as bad ;-) as the stock one 
supplied in .rpm file.

> [root@scully cvs]# uname -r
> 2.4.2-2
> [root@scully cvs]# df
> ...
> AFS                    9000000         0   9000000   0% /afs
> [root@scully cvs]# umount /afs
> [root@scully cvs]# /usr/vice/etc/afsd -shutdown
> afsd: Shutting down all afs processes and afs state
> [root@scully cvs]# rmmod afs
> [root@scully cvs]# lsmod|grep afs
> [root@scully cvs]#
>
> Host is running RedHat 7.1.

I can do this a few times. Sooner or later umount /afs complains about 
filesystem being busy, and that's it.

> > Since I've seen no constructive input as to why a well-designed kernel
> > module cannot be safely removed, as well as why a well-designed
> > filesystem cannot be unmounted, I'm going to look after a fix myself.
> > Yes, I know that *currently* when I umount I'm in trouble, but it's *not
> > supposed* to be so. I was just hoping that maybe it's something simple
> > that has to be configured somewhere in order to get it right. It doesn't
> > seem so, or maybe?
>
> There is some problem with inode references being leaked, apparently, but
> it only happens sometimes. [snip]

Which basically means that it's damned unsafe to do any administration on the 
afs server itself, since the client can eventually bring it down :-(

> > 4. /afs should be unmount-able as soon as no process is referencing the
> > /afs subtree - that's the behaviour of all other filesystems; in case
> > there are afs daemons with pending requests, those daemons should be
> > signaled (say with HUP) to immediately return with error, so that control
> > can be returned to the calling process (via the module)
>
> Yes, and generally this does work, unless a reference is leaked and the
> kernel still believes the filesystem is busy, and if anything, that is
> your problem.

Well, that a bug, and that's everybody (who's involved) problem ;-). I'm 
trying to put some debugging code right now to see the reference counts and 
pick the place where it actually leaks.

> Also, are you building from the RPM source, or a tar file from
> www.openafs.org?

openafs-kernel-source-1.0.4.rpm

I assume that packagers did their job. I can try the .tar as well if that's 
going to help.

Kuba