> Ehm, I'll put the building tarball on our ftp site:
>
> ftp://ftp.huygens.org/pub/linux/knfsd/linux-nfs-0.4.22-1.tar.gz
>
> It's 0.4.22 based, and it works over here.
I finally found a time window where I was (nearly) alone in the room, to
happily reboot and freeze the whole NFS net... So I tried your patch. It
seems it does a step in the right direction, but there are still bogus
values down to the kernel.
In my case (exporting a single directory to a single group of machines), I
get, in the file linux/fs/nfsd/export.c, line 220 or so (the
if (something) {
/* I'm being just paranoid */
goto finish;
}
section) strange values :
inode->i_dev == 0x02000008, but nxp->ex_dev == 0x00000808 (which happens
to be what the userland half sees, thanks to stat() ).
Couldn't a solution be to somehow (privately) expose the functionality of
stat() used by the userland part in support/export/nfsctl.c/exp_export()
(ie : from a pathname, get the device number and the inode) so that mountd
always gives the right ones, regardless of the (g)libc quirks ?
Although that's ugly, I'm thinking of the following (pseudo)function, to
be exported by knfsd :
#define EVERYTHING
#define MY_IGNORANCE (ULONG_MAX + 1)
int exp_nfsd_stat( WHATEVER_PARMS ) {
struct dentry *dentry = NULL;
struct inode *inode = NULL;
struct { long int dev, long int ino } to_return;
if (!exp_verify_string(the_path, NFS_MAXPATHLEN))
retrun -EINVAL;
dentry = lookup_dentry(the_path, NULL, 0);
if (IS_ERR(dentry))
return -EINVAL;
inode = dentry->d_inode
if (!inode)
return -EINVAL;
to_return.dev = inode->i_dev;
to_return.ino = inode->i_ino;
dput(dentry);
PACKAGE_FOR_RETURN(to_return);
return 0;
}
There's not much work turning this into real code, just one 'slight'
difficulty : I just don't know how to make a kernel function visible (is
there a HOWTO somewhere ? I somewhat lack of time to rev the sources,
and it's really a pain to recompile and test on an ssIPX. Especially
when it's a (cough) production server). If someone is kind enough to point
me at the right direction, I'd be happy to convert the above snippet to
something working (hoping that the whole thing follows...)
Of course, the above proposal is not a real fix, just a kludge with the
hope of making that run...
TIA
-- Cyrille
------------------------------
Zog Zog
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu