Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:1231 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995Ab1IWQlU (ORCPT ); Fri, 23 Sep 2011 12:41:20 -0400 From: David Howells In-Reply-To: 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> <1316792468.3346.144.camel@perseus.themaw.net> To: Linus Torvalds Cc: dhowells@redhat.com, Ian Kent , Trond Myklebust , miklos@szeredi.hu, Jeff Layton , viro@zeniv.linux.org.uk, gregkh@suse.de, linux-nfs@vger.kernel.org, leonardo.lists@gmail.com Subject: Re: [PATCH] VFS: Suppress automount on [l]stat, [l]getxattr, etc. Date: Fri, 23 Sep 2011 17:40:07 +0100 Message-ID: <13920.1316796007@redhat.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: Content-Type: text/plain MIME-Version: 1.0 Linus Torvalds wrote: > We may indeed have to revert for sanity at this point, but I have to > say that I think the arguments have been very weak, and the logic for > when to auto-mount and when not to seems to not really be based on any > real logic. Can you look over the patchset I've just posted. It moves the policy on whether or not to suppress automount out of follow_automount() - which is probably the wrong place for it anyway. Depending on which patch you want to stop at it can reinstate the pre-Miklos behaviour; reinstate the Miklos behaviour, but without the regression; or reinstate the pre-d_automount behaviour. > For example, I think the whole "let's consider lstat different from > stat" model is broken. It works for symlinks, but that's because That's a reasonable way to look at it; the difference between stat and lstat is about handling symlinks only. Furthermore, we have fstatat, so this isn't really an issue - that can be given flags to let userspace decide what it should do. getxattr and co. are trickier because they don't have an AT_ flags form, and it can be argued that these, lgetxattr and co. included should automount. However, that would seriously upset ls, so I think we have to leave lgetxattr not automounting, and so getxattr should follow. We should consider adding an AT_ flags form of the xattr calls, but that's another matter we can argue over later. > So *that* is why I thought the LOOKUP_DIRECTORY flag was so nice. And > I still suspect that if paired with LOOKUP_OPEN, it would actually be > a complete solution that avoids the crazy issues with "random > implementation detail" and could give us something that is both > accessible from user space *and* something we can explain to a user > from a logical basis. I don't like this because it's fragile. We're giving an implied second meaning to LOOKUP_DIRECTORY/LOOKUP_OPEN, albeit a reasonable one. Can we please move the policy to the pathwalk callers instead? David