linux-kernel - Re: recent nfs change causes autofs regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 31 Aug 2007 10:01:50 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Trond Myklebust <trond.myklebust@....uio.no>
cc:	Frank van Maarseveen <frankvm@...nkvm.com>,
	Hua Zhong <hzhong@...il.com>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org
Subject: Re: recent nfs change causes autofs regression

On Fri, 31 Aug 2007, Trond Myklebust wrote:
>
> The best I can do given the constraints appears to be to have the kernel
> first look for a superblock that matches both the fsid and the
> user-specified mount options, and then spawn off a new superblock if
> that search fails.

I think this is probably acceptable to get roughly the old behaviour, but 
I still think it's a bit stupid.

What happens at "mount -o remount,..." time?

The fact is, the whole "match the fsid and user mount options, and re-use 
the mount" sounds like it's trying to solve a problem that doesn't need 
solving. If the user really wants to duplicate the mount, he really should 
be using a a bind-mount instead.

In other words, let's assume that the user has /some/nfs/mount mounted 
over NFS, and wants to re-mount it (or even just a subset of it) somewhere 
else, the sane thing to do is not to mount it again, but to just do

	mount --bind /some/nfs/mount/subdir /new/mount/place

instead. That *guarantees* that the low-level filesystem uses the same 
flags, and it also means that things like re-mounting have sane and 
well-defined semantics, and will fail or succeed predictably.

In contrast, if a user wants to create a new NFS mount, it really should 
be independent of the old one, because that's (a) what other systems do, 
and (b) also makes the semantics of re-mounting it with other flags be 
clear and unambiguous (ie the remount has nothing what-so-ever to do with 
the independent NFS mount).

See? 

This is why I think "nosharecache" should just be the default, because 
that's the behaviour that simply does not have any subtle issues. The 
*special* case should be the "sharecache" case, and 99% of the time that 
one should likely be done with a "--bind" mount.

(I don't really see the point of _ever_ doing anything but a bind mount, 
but maybe there are reasons to try to share at a NFS layer that I don't 
really see)

> The attached patch does just that.

Hua, does this fix things for you? If it gets rid of the regression, I can 
certainly live with it, but as per above, I don't really think this makes 
much sense in the "bigger picture" kind of thing.

> Finally, for the record: I still feel very uncomfortable about not being
> able to report the state of the client setup back to the sysadmin.
> AFAIK, the only way to do so is to stat the mountpoints, and compare the
> device ids.

Well, not only don't I see that as being horribly wrong, I actually think 
that the sysadmin should know what his mount setup is, even without having 
to ask. But since he *can* ask, using easy and standard interfaces, I 
don't really see what the problem really is.

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