public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Jeff Layton <jlayton@poochiereds.net>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM
Date: Sat, 9 Jul 2016 04:10:01 +0100	[thread overview]
Message-ID: <20160709031001.GS14480@ZenIV.linux.org.uk> (raw)
In-Reply-To: <71EA6CA5-3451-4A0F-BAA0-59843BA2D153@linuxhacker.ru>

On Fri, Jul 08, 2016 at 05:47:22PM -0400, Oleg Drokin wrote:

> I wonder if people just accept that "NFS is just weird" and code in workarounds,
> where as with Lustre we promise (almost) full POSIX compliance, and also came much later
> so people are just seeing that "this does not work" and complain more loudly?

To quote POSIX: "If more than one error occurs in processing a function call,
any one of the possible errors may be returned, as the order of detection is
undefined." (from System Interfaces: General Information: 2.3 Error Numbers)

And regarding mkdir(2) it has
[EACCES]
    Search permission is denied on a component of the path prefix, or write
permission is denied on the parent directory of the directory to be created.
[EEXIST]
    The named file exists.
among the error conditions.  In situations when both apply, the implementation
is bloody well allowed to return either.  It might be nicer to return EEXIST
in such cases, for consistency sake (if another thread does stat() on the
pathname in question just as you are about to call mkdir(2), you will get
EEXIST without ever reaching permission(9), let alone ->mkdir() method), but
please do not bring POSIX compliance as an argument.  It's a QoI argument and
nothing beyond that.

  reply	other threads:[~2016-07-09  3:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08  1:47 [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM Oleg Drokin
2016-07-08 11:02 ` Jeff Layton
2016-07-08 15:14   ` Oleg Drokin
2016-07-08 15:53     ` Jeff Layton
2016-07-08 15:59       ` Oleg Drokin
2016-07-08 16:17         ` Jeff Layton
2016-07-08 16:28           ` Oleg Drokin
2016-07-09  2:52         ` Al Viro
2016-07-09  2:58           ` Oleg Drokin
2016-07-09  3:13             ` Al Viro
2016-07-08 16:04       ` J. Bruce Fields
2016-07-08 16:16         ` Oleg Drokin
2016-07-08 20:49           ` J. Bruce Fields
2016-07-08 21:47             ` Oleg Drokin
2016-07-09  3:10               ` Al Viro [this message]
2016-07-09  3:41                 ` Oleg Drokin
2016-07-13 19:00                   ` J. Bruce Fields
2016-07-08 20:54 ` J. Bruce Fields
2016-07-08 21:53   ` Oleg Drokin
2016-07-21 20:34     ` J. Bruce Fields
2016-07-21 20:37       ` Oleg Drokin
2016-07-22  1:57         ` J. Bruce Fields
2016-07-22  6:35           ` Oleg Drokin
2016-07-22 10:55             ` J. Bruce Fields
2016-07-22 15:13               ` Oleg Drokin
2016-07-22 17:48                 ` J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 1/7] nfsd: Make creates return EEXIST instead of EACCES J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 2/7] nfsd: remove redundant zero-length check from create J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 3/7] nfsd: remove redundant i_lookup check J. Bruce Fields
2016-07-24  0:22                     ` Al Viro
2016-07-24 12:10                       ` J. Bruce Fields
2016-07-24 14:23                         ` Al Viro
2016-07-24 20:21                           ` J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 4/7] nfsd: reorganize nfsd_create J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 5/7] nfsd: remove unnecessary positive-dentry check J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 6/7] nfsd: clean up bad-type check in nfsd_create_locked J. Bruce Fields
2016-07-22 17:48                   ` [PATCH 7/7] nfsd: drop unnecessary MAY_EXEC check from create J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160709031001.GS14480@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bfields@fieldses.org \
    --cc=green@linuxhacker.ru \
    --cc=jlayton@poochiereds.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox