Commit 4549fc7
atomic_open(): fix the handling of create_error
commit 10c64cea04d3c75c306b3f990586ffb343b63287 upstream.
* if we have a hashed negative dentry and either CREAT|EXCL on
r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
with failing may_o_create(), we should fail with EROFS or the
error may_o_create() has returned, but not ENOENT. Which is what
the current code ends up returning.
* if we have CREAT|TRUNC hitting a regular file on a read-only
filesystem, we can't fail with EROFS here. At the very least,
not until we'd done follow_managed() - we might have a writable
file (or a device, for that matter) bound on top of that one.
Moreover, the code downstream will see that O_TRUNC and attempt
to grab the write access (*after* following possible mount), so
if we really should fail with EROFS, it will happen. No need
to do that inside atomic_open().
The real logics is much simpler than what the current code is
trying to do - if we decided to go for simple lookup, ended
up with a negative dentry *and* had create_error set, fail with
create_error. No matter whether we'd got that negative dentry
from lookup_real() or had found it in dcache.
Acked-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>1 parent b657027 commit 4549fc7
1 file changed
Lines changed: 4 additions & 16 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2906 | 2906 | | |
2907 | 2907 | | |
2908 | 2908 | | |
2909 | | - | |
2910 | | - | |
2911 | | - | |
2912 | | - | |
2913 | | - | |
2914 | | - | |
2915 | | - | |
2916 | | - | |
2917 | | - | |
2918 | | - | |
2919 | | - | |
2920 | | - | |
2921 | | - | |
2922 | | - | |
2923 | | - | |
2924 | | - | |
| 2909 | + | |
| 2910 | + | |
| 2911 | + | |
| 2912 | + | |
2925 | 2913 | | |
2926 | 2914 | | |
2927 | 2915 | | |
| |||
0 commit comments