From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: LOOKUP_CREATE checks in nfs ->create() instances
Date: Thu, 17 Feb 2011 03:37:30 +0000
Message-ID: <20110217033730.GI22723@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:34916 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751393Ab1BQDhd (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 16 Feb 2011 22:37:33 -0500
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

	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...