linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* LOOKUP_CREATE checks in nfs ->create() instances
@ 2011-02-17  3:37 Al Viro
  2011-02-17 19:07 ` Trond Myklebust
  0 siblings, 1 reply; 3+ messages in thread
From: Al Viro @ 2011-02-17  3:37 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: linux-fsdevel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: LOOKUP_CREATE checks in nfs ->create() instances
  2011-02-17  3:37 LOOKUP_CREATE checks in nfs ->create() instances Al Viro
@ 2011-02-17 19:07 ` Trond Myklebust
  2011-02-17 19:50   ` Al Viro
  0 siblings, 1 reply; 3+ messages in thread
From: Trond Myklebust @ 2011-02-17 19:07 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: LOOKUP_CREATE checks in nfs ->create() instances
  2011-02-17 19:07 ` Trond Myklebust
@ 2011-02-17 19:50   ` Al Viro
  0 siblings, 0 replies; 3+ messages in thread
From: Al Viro @ 2011-02-17 19:50 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: linux-fsdevel

On Thu, Feb 17, 2011 at 02:07:00PM -0500, Trond Myklebust wrote:

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

Um...  You mean, before we had .open.flags set to O_EXCL in there?
Makes sense - it's about 3 years older than lookup_create() change.
OK, then I'm going to remove the checks (treating condition as always
true) and place BUG_ON for a few months just in case...

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-02-17 19:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-17  3:37 LOOKUP_CREATE checks in nfs ->create() instances Al Viro
2011-02-17 19:07 ` Trond Myklebust
2011-02-17 19:50   ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).