Hi Miklos,
I found some time to track down the O_CREAT error code issue. Patch is
below. Does this look correct?
I was reproducing with
ceph-fuse mnt
mkdir -p mnt/a
cd mnt
.../pjd-fstest-20080816/fstest -u 65534 -g 65534 open a/foo O_RDONLY,O_CREAT 0644
EACCES is expected, ENOENT was returned instead.
Thanks!
sage
(BTW: strangely, the correct value was returned if I traverse across
mounts, e.g.
mkdir -p mnt/a
.../pjd-fstest-20080816/fstest -u 65534 -g 65534 open mnt/a/foo O_RDONLY,O_CREAT 0644
)
>From d438bfcae681251c957bcd2b6a2559567faee218 Mon Sep 17 00:00:00 2001
From: Sage Weil <sage@xxxxxxxxxxx>
Date: Wed, 15 Aug 2012 13:30:12 -0700
Subject: [PATCH] vfs: fix propagation of atomic_open create error on negative
dentry
If ->atomic_open() returns -ENOENT, we take care to return the create
error (e.g., EACCES), if any. Do the same when ->atomic_open() returns 1
and provides a negative dentry.
This fixes a regression where an unprivileged open O_CREAT fails with
ENOENT instead of EACCES, introduced with the new atomic_open code. It
is tested by the open/08.t test in the pjd posix test suite, and was
observed on top of fuse (backed by ceph-fuse).
Signed-off-by: Sage Weil <sage@xxxxxxxxxxx>
---
fs/namei.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 26c28ec..db76b86 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2489,6 +2489,10 @@ static int atomic_open(struct nameidata *nd, struct dentry *dentry,
dput(dentry);
dentry = file->f_path.dentry;
}
+ if (create_error && dentry->d_inode == NULL) {
+ error = create_error;
+ goto out;
+ }
goto looked_up;
}
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
