All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@ownmail.net>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	Chuck Lever <cel@kernel.org>, Jeff Layton <jlayton@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [PATCH 3/7] vfs: vfs_lookup_open() should only return -EFTYPE for non-regular files
Date: Thu, 10 Sep 2026 10:20:49 +1000	[thread overview]
Message-ID: <20260910002934.192979-4-neilb@ownmail.net> (raw)
In-Reply-To: <20260910002934.192979-1-neilb@ownmail.net>

From: NeilBrown <neil@brown.name>

Decoding the non-regular type into over-loaded error codes doesn't
really help nfsd much and it isn't particularly elegant.
It also isn't reliable as some filesystems may return -EFTYPE
from their atomic_open() for any non-regular file, given that
__O_REGULAR was passed.

So change to only return -EFTYPE for non-regular files.
Also use d_is_reg() to detect this case.

Caller can repeat the lookup in the dcache to determine what sort of
object was there.  This might find a different dentry if there is a
race, but that is not significant.

Signed-off-by: NeilBrown <neil@brown.name>
---
 fs/namei.c | 30 ++++--------------------------
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index c4be59213352..0c787363b101 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4616,14 +4616,8 @@ static struct dentry *lookup_open(struct nameidata *nd, struct file *file,
  * nfsd.
  * It uses ->atomic_open or ->lookup / ->create / ->open as appropriate.
  *
- * If the fs object found is not a regular file then an error is returned.
- * In some cases, related errors are repurposed so that the caller can
- * determine the type of file found from the error.
- * -EISDIR : a directory was found
- * -ELOOP  : a symlink was found
- * -ENODEV : a block or character device special file was found
- * -EFTYPE : any other non-regular file was found, such as FIFO or SOCK.
- *           or ->atomic_open responded to __O_REGULAR.
+ * If the fs object found is not a regular file then -EFTYPE is
+ * returned.
  *
  * Returns: the opened struct file, or an error.
  */
@@ -4671,24 +4665,8 @@ struct file *vfs_lookup_open(struct path *parent, struct qstr *last,
 		error = -ENOENT;
 	} else if (!(file->f_mode & FMODE_CREATED) && (open_flag & O_EXCL)) {
 		error = -EEXIST;
-	} else if ((dentry->d_inode->i_mode & S_IFMT) != S_IFREG) {
-		switch (dentry->d_inode->i_mode & S_IFMT) {
-		case S_IFDIR:
-			error = -EISDIR;
-			break;
-		case S_IFLNK:
-			error = -ELOOP;
-			break;
-		case S_IFBLK:
-		case S_IFCHR:
-			error = -ENODEV;
-			break;
-		case S_IFIFO:
-		case S_IFSOCK:
-		default:
-			error = -EFTYPE;
-			break;
-		}
+	} else if (!d_is_reg(dentry)) {
+		error = -EFTYPE;
 	} else if (!(file->f_mode & FMODE_OPENED)) {
 		nd.path.dentry = dentry;
 		error = vfs_open(&nd.path, file);
-- 
2.50.0.107.gf914562f5916.dirty


  parent reply	other threads:[~2026-09-10  0:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  0:20 [PATCH 0/7 RFC] fixes for vfs_lookup_open, and integration with nfsd NeilBrown
2026-09-10  0:20 ` [PATCH 1/7] vfs: add some allowed open flags to vfs_lookup_open() NeilBrown
2026-09-10  0:20 ` [PATCH 2/7] vfs: O_NONBLOCK|O_CREAT open shouldn't wait for directory delegation NeilBrown
2026-09-10  0:20 ` NeilBrown [this message]
2026-09-10  0:20 ` [PATCH 4/7] vfs: change vfs_lookup_open() to return found dentry in path.dentry NeilBrown
2026-09-10  0:39   ` NeilBrown
2026-09-10 15:13   ` Chuck Lever
2026-09-10  0:20 ` [PATCH 5/7] nfsd: switch NFS4 OPEN to use vfs_lookup_open() NeilBrown
2026-09-10 15:41   ` Chuck Lever
2026-09-10  0:20 ` [PATCH 6/7] nfsd: nfsd_check_obj_isreg() to use nfs error codes NeilBrown
2026-09-10  0:20 ` [PATCH 7/7] nfsd: use vfs_lookup_open() for non-creating open requests too NeilBrown
2026-09-10 15:47   ` Chuck Lever

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=20260910002934.192979-4-neilb@ownmail.net \
    --to=neilb@ownmail.net \
    --cc=brauner@kernel.org \
    --cc=cel@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.