Re: knfsd 1.5 is released

H . J . Lu (hjl@valinux.com)
Wed, 29 Sep 1999 10:39:53 -0700

On Sat, Sep 25, 1999 at 07:50:50PM +1000, Neil Brown wrote:
> On Friday September 24, hjl@valinux.com wrote:
> > On Fri, Sep 24, 1999 at 11:31:16AM +1000, Neil Brown wrote:
> > > > ----
> > >
> > > David's Patches were only a work-in-progress, not really ready for
> > > serious use yet. The usage of "d_path" in nfsd_netlink_notify is all
> > > wrong for a start.
> > > I have mailed David privately about this and he plans to tidy it up
> > > soonish, but until then, I don't think the mountd changes in 1.5
> > > should be used, so I won't be making a patch against them.
> > >
> >
> > I am appending 2 patches to address some of the problems in
> > knfsd 1.5. Please check them out.
> >
> > Thanks.
> >
> >
> > H.J.
>
> I haven't actually down loaded 1.5.1 yet, but based on 1.5 plus these
> patches, one thing that stands out is that creating negative export
> entries will not work in general (Though they may work in many
> specific situations).

That is true. I am working on it right now.

>
> An NFS file handle has xdev and xino entries which indicate which
> export entry is being used. If mountd is to give an NFSEXP_NEGATIVE
> entry to the kernel to reject a given file handle, it needs to know
> this xdev/xino information somehow. Currently it doesn't (unless, by
> luck, xdev/xino is the root file the filesystem).
> It is only given the device, and the path to the actual file which is
> being accessed.
>

I just added "struct knfs_fh fh" to "struct nfsd_netlink_callback".
mountd will check if xdev and xino from get_rootfh () match the
ones in "struct nfsd_netlink_callback".

> How I would fix it (I wont be able to do it myself for about 2 weeks):
>
> change find_fh_dentry to take a dev/ino/parentino triple instead of
> a file handle, where the parentino is ignored if ino is a
> directory (but start with my new find_fh_dentry from
> http://www.cse.unsw.edu.au/~neilb/oss/knfsd/knfsd.1.4.7-patch-2a
> if you haven't already).
>
> change fh_verify to call it this way.
>
> change nfsd_netlink_notify to pass xdev/xino/0 to the new
> find_fh_dentry to get a dentry for the export point. Pass up to
> mountd exactly the d_path for this dentry. No need for a separate
> device name (and no need to make lookup_vfsmnt an exported symbol),
> and no need for the path to the actual file being accessed.
>

It doesn't work in my case. The problem happens

1. Server has a fs /home
2. Server exports /home/work/linux.
3. Client mount /home/work/linux
4. Server exports /home instead of /home/work/linux and restarts.
5. Client accesses /home/work/linux on server.

Now mountd cannot insert a negative entry due to the export rule in
the kernel. Client will hang in that case. I don't know what the
best fix is. Is that possible to get synchronous communication between
mountd and kernel?

For the time being, I am going to add a timeout to mountd callback. If
kernel doesn't get response from mountd within a few seconds, it will
tell the client that fh is stale.

> make the (hopefully) obvious changes to mountd.
>
> Actually, this is more of a symptomatic fix that a proper fix.
> see
> http://localhost/~neilb/oss/knfsd/mail/archive/0031.html
> for my current thoughts on how it "should" work.
>
> 

-- 
H.J. Lu (hjl@gnu.org)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/