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]

Message-ID: <001501c7eb5d$d295d870$77c18950$@com>
Date:	Thu, 30 Aug 2007 16:30:57 -0700
From:	"Hua Zhong" <hzhong@...il.com>
To:	"'Trond Myklebust'" <trond.myklebust@....uio.no>
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:
> > >
> > > 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,n
> fsve
> > rs=3,actimeo=600 fs1.domain.com:/a/tools
> > share
> > -
> fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n
> fsve
> > 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.

There are two disjoint directories. I am wondering why there would be cache
coherency issues in this case? Is this Linus nfs implementation specific or
all other Unix systems all have the same 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".

"working" as in "I can mount the directory and do my work". And there has
never been any problems as far as I know.

> 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".

Fine. These are all very nice theories, but I just want to report this
regression and hope it won't cause any big problems for any users out there.
In the mean time, I am returning to 2.6.22.

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