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: <1188513433.6626.24.camel@heimdal.trondhjem.org>
Date:	Thu, 30 Aug 2007 18:37:13 -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 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.

If you need to mount the same filesystem with incompatible mount options
on the same client, then there is a new mount option "nosharecache",
which enables it.
The new option is there in order to make it damned clear to sysadmins
that this is a dangerous thing to do: mounts which don't share the same
superblock also don't share the same data and attribute caches. Any file
or directory which appears in both mounts had better only be used by one
application at a time or be using an appropriate locking scheme.

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/