[9] in linux-net channel archive
Re: old mount ??? bug in nfs ???? bug in new kernel ????? FEATURE ????
daemon@ATHENA.MIT.EDU (Linus Torvalds)
Tue Dec 20 04:50:55 1994
Date: Tue, 20 Dec 1994 10:31:25 +0200
From: Linus Torvalds <Linus.Torvalds@cs.helsinki.fi>
In-Reply-To: Swen Thuemmler's message as of Dec 20, 9:20
To: Swen Thuemmler <swen@uni-paderborn.de>,
Linux Activists <linux-activists@niksula.hut.fi>
Cc: Linux Kernel <linux-kernel@vger.rutgers.edu>,
Linux Net <linux-net@vger.rutgers.edu>
Swen Thuemmler: "Re: old mount ??? bug in nfs ???? bug in new kernel ????? FEATURE ????" (Dec 20, 9:20):
>
> On Mon, 19 Dec 1994, Jacek Zapala wrote:
>
> > I have observed strange behavior of the mount command from the old
> > Slackware. I am trying to mount the nfs filesystem from the host which is
> > the router and therefore it has two addresses: 1.2.3.5 and 1.2.2.5. My
> > address is 1.2.3.4. With the new kernel (1.1.72), if named gives 1.2.3.5 as
> > the first address of that host, and 1.2.2.5 as the second one, there are no
> > problems. But if 1.2.2.5 is the first reported address, mount hangs up. With
> > the old kernel everything is ok in both cases.
> >
> > So what's the real problem ? Do I need newer mount ?
>
> This is a bug in the kernel. Unfortunately, fixing it requires a change
> of the mount program: just remove the connect() in line 350 of nfsmount.c
> (mount is part of util-linux). Same holds for mount_linux.c of amd. But
> beware! This mount (or amd) will not be compatible with older kernels,
> which require a connect()ed socked. The old mount will continue to work,
> so I hope this patch will eventually make it into the official kernel.
> This would give the possibility to do the right thing in the mount program
> depending on the kernel revision. Linus?
The reason this won't go in is that I don't consider it a bug in the
kernel at all: I consider it a problem of the mount binary and/or the
NFS protocol. The current kernel does the right thing: it accepts nfs
packets only from the host we mounted, and these patches essentially
make it accept them from any machine.
Of course, the current behaviour means that you have to give the kernel
the right address for the NFS server: this can be done either with
- the user knows it (our Sun's at the university, for example, use
this: the mounting of the disks on "hydra" is done through the fddi
interface, and you actually use "hydra-fddi" to mount them)
- 'mount' finding out some way: this could be a question of the mount
binary faking a NFS request to the machine, and checking what address
it comes back with and then using that address..
I don't consider it a good idea to "solve" the problem by just accepting
NFS replies from any address..
Linus
