From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: LOOKUP_CREATE checks in nfs ->create() instances Date: Thu, 17 Feb 2011 14:07:00 -0500 Message-ID: <1297969620.2964.8.camel@heimdal.trondhjem.org> References: <20110217033730.GI22723@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Received: from mx2.netapp.com ([216.240.18.37]:35876 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757798Ab1BQTHX convert rfc822-to-8bit (ORCPT ); Thu, 17 Feb 2011 14:07:23 -0500 In-Reply-To: <20110217033730.GI22723@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2011-02-17 at 03:37 +0000, Al Viro wrote: > When are they _not_ true? AFAICS, calls of ->create() with > non-NULL nameidata are very limited to start with: > * ecryptfs one - called from its own ->create(), without changes > in LOOKUP_CREATE presence. > * sys_mknodat() - called after we'd done lookup_create(), which > sets LOOKUP_CREATE (and LOOKUP_EXCL), with O_EXCL in intent flags. Nothing > ever removes LOOKUP_CREATE once it's set. > * __open_namei_create(), which is called from from do_filp_open() > and only if we had O_CREAT passed in flags. In that case LOOKUP_CREATE > will be set before we get there. > > What am I missing here? AFAICS, there's no way to get nfs ->create() methods > called without LOOKUP_CREATE present in nd->flags... Hi Al, That is probably a remnant of the times before lookup_create() was changed to set the LOOKUP_CREATE intent in 2.6.18. I'm fine with getting rid of those checks if they are no longer needed. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com