Return-Path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:45037 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752938Ab1IZX1L (ORCPT ); Mon, 26 Sep 2011 19:27:11 -0400 Received: by wyg34 with SMTP id 34so6448578wyg.19 for ; Mon, 26 Sep 2011 16:27:10 -0700 (PDT) In-Reply-To: <1317078563.21770.8.camel@lade.trondhjem.org> References: <1316747758.3346.89.camel@perseus.themaw.net> <20110922134510.24683.14576.stgit@warthog.procyon.org.uk> <1316707443.3346.44.camel@perseus.themaw.net> <1316709935.3346.48.camel@perseus.themaw.net> <20110922133529.6d3ea8de@barsoom.rdu.redhat.com> <20110922144453.6cf53a25@barsoom.rdu.redhat.com> <1316719228.3968.14.camel@lade.trondhjem.org> <2E1EB2CF9ED1CB4AA966F0EB76EAB4430B480BD4@SACMVEXC2-PRD.hq.netapp.com> <21772.1316774025@redhat.com> <1316788444.14812.10.camel@lade.trondhjem.org> <29743.1316791138@redhat.com> <87hb43tf2g.fsf@tucsk.pomaz.szeredi.hu> <1316827854.3346.154.camel@perseus.themaw.net> <20110924073610.4b045189@tlielax.poochiereds.net> <1317013864.3187.81.camel@perseus.themaw.net> <1317071626.19951.8.camel@lade.trondhjem.org> <1317072718.19951.13.camel@lade.trondhjem.org> <1317076424.19951.32.camel@lade.trondhjem.org> <1317078563.21770.8.camel@lade.trondhjem.org> From: Linus Torvalds Date: Mon, 26 Sep 2011 16:26:50 -0700 Message-ID: Subject: Re: [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc. To: Trond Myklebust Cc: Ian Kent , Jeff Layton , Miklos Szeredi , David Howells , viro@zeniv.linux.org.uk, gregkh@suse.de, linux-nfs@vger.kernel.org, leonardo.lists@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Mon, Sep 26, 2011 at 4:09 PM, Trond Myklebust wrote: > > I assume that means that we can get rid of LOOKUP_NO_AUTOMOUNT, and just > replace the convoluted logic in follow_automount() with a test for > LOOKUP_AUTOMOUNT? If we have agreed on a default behaviour, then that > would seem cleaner than enumerating all these exceptions. I do think that LOOKUP_NO_AUTOMOUNT is bogus. It's not a kernel-internal flag, it's for that silly "vfs_fstatat()" interface, that was designed when LOOKUP_FOLLOW would cause an automount. Now that LOOKUP_FOLLOW doesn't do that, the whole reason for LOOKUP_NO_AUTOMOUNT really goes away, but then we have that crazy user interface that was encoded for it (only for the very special vfs The question then becomes: should we just ignore (and deprecate) that crazy AT_NO_AUTOMOUNT flag? I say "yup". Or should we do something *really* crazy, and say "if you *don't* have AT_SYMLINK_NOFOLLOW *and* you don't have AT_NO_AUTOMOUNT, then we make fstatat64() follow automounts, even though no sane version of *stat() does so any more"? Quite frankly, that just sounds insane. But we could do it, and it would approximate the old semantics for that system call. Even if those old semantics were clearly not very good, and the whole point of AT_NO_AUTOMOUNT was to work around problems people must have had.. So my gut feel is that we should just ignore it for now. AT_NO_AUTOMOUNT becomes a no-op, and the LOOKUP_NO_AUTOMOUNT flag is already effectively one (since nothing but vfs_fstatat sets it, and vfs_fstatat now doesn't follow automounts *anyway*) The "let's just see if anybody complains when we clean stuff up" approach, in other words. Because I bet any user who doesn't have AT_NO_AUTOMOUNT isn't because they didn't really want an automount, it's because they weren't even aware of the issue. Linus