Return-Path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:52308 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751856Ab1IZWZV (ORCPT ); Mon, 26 Sep 2011 18:25:21 -0400 Received: by wyg34 with SMTP id 34so6398933wyg.19 for ; Mon, 26 Sep 2011 15:25:20 -0700 (PDT) In-Reply-To: <1317072718.19951.13.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> From: Linus Torvalds Date: Mon, 26 Sep 2011 15:24:59 -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 2:31 PM, Trond Myklebust wrote: > > A bind mount doesn't actually want us to set up OPEN state on the NFSv4 > server and return a fully initialised 'struct file' in the struct > nameidata. If it did, we would already have set the LOOKUP_OPEN flag > together with the accompanying open intent structure in the struct > nameidata. > > Ditto for the quotactl(). Umm. As far as I can see, adding LOOKUP_OPEN doesn't actually even *do* what you claim. The whole "allocate struct file in struct nameidata" happens in path_openat(), it doesn't happen in the normal path creation (do_path_lookup() and friends). The only thing NFS does with LOOKUP_OPEN is to check whether it needs to do a revalidate regardless. But even more importantly than your apparent confusion about filling in the 'nameidata.intent' fields, even *if* we were to do unnecessary filp allocations etc (which we don't do, as mentioned), from a user standpoint, what would be the actual downside? It would be extra work for a (very rare) operation, but compared to the known downside that is LOOKUP_FOLLOW and auto-mounting when we shouldn't, even that hypothetical downside seems pretty benign, doesn't it? In other words, what I don't understand is how you seem to be totally happy ignoring the known problems with LOOKUP_FOLLOW, but LOOKUP_OPEN is some monster thing that you don't want to deal with. WHY? Linus PS. That said, looking at the *cifs* code, it seems to do some nasty things on LOOKUP_OPEN, and assumes that it always has a 'file' pointer. Sad. That might actually argue for another flag, or alternatively for just fixing CIFS.