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:	Thu, 30 Aug 2007 19:22:53 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Hua Zhong <hzhong@...il.com>
Cc:	'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>,
	'Linus Torvalds' <torvalds@...ux-foundation.org>,
	akpm@...ux-foundation.org
Subject: RE: recent nfs change causes autofs regression

On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
> Hi Trond,
> 
> > On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > > I am re-sending this after help from Ian and git-bisect. To me it's a
> > > show-stopper: I cannot find an acceptable workaround that I can
> > > implement. The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes 
> > > several autofs mounts to fail silently - they just not appear when 
> > > they should.
> > > I believe it's caused by the NFS change that forces multiple mounts
> > > from different directories under the same server side filesystem to have
> > > the same mount options by default, otherwise it returns EBUSY.
> > >
> > > For example, if server has a filesystem /a, and it exports /a/x and /a/y
> > > (maybe with rw or ro), and a client must mount /a/x and /a/y with the
> > > same mount options now.
> > 
> > Which is better than having it fail silently, or giving you a mount
> > with the wrong mount options.
> 
> Well, it depends on how you define "better".

"better" as in: "I now have a chance to notice, when my 'read-only
mount' is actually 'read-write'".

> In this particular scenario, the maps read as follows:
> 
> tools
> -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve
> rs=3,actimeo=600 fs1.domain.com:/a/tools
> share
> -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve
> rs=3 fs1.domain.com:/a/share
> 
> The only difference is in the actimeo (I don't even know what it means). Is
> this enough to fail a mount?

Yes. The default values for acregmin, acregmax, acdirmin, acdirmax are
not 600. If /a/tools and /a/share are on the same filesystem on the
server, then the NFS client should warn you that you are about to do
something that may result in cache coherency problems instead of
silently allowing it, and then leaving you to debug the coherency issue.

If you know what you are doing, then there is an option which allows you
to override the default behaviour.

> More importantly, it is a regression. My understanding is that unless
> absolutely necessary we do not introduce a "feature" that breaks working
> setups.

Your turn to define what you mean by "working"? In my book that means "a
setup that doesn't include unexpected or unintended behaviour".

Not being able to notice cache coherency failures on a file that is
mounted in two different places with two different sets of mount options
counts as "unexpected behaviour".

Not being able to notice that your mount options have been overridden by
the kernel also counts as "unexpected behaviour".

Trond

-
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/