Jeff Layton 5bb5e6ee6f ceph: don't try to handle hashed dentries in non-O_CREAT atomic_open
If ceph_atomic_open is handed a !d_in_lookup dentry, then that means
that it already passed d_revalidate so we *know* that it's negative (or
at least was very recently). Just return -ENOENT in that case.

This also addresses a subtle bug in dentry handling. Non-O_CREAT opens
call atomic_open with the parent's i_rwsem shared, but calling
d_splice_alias on a hashed dentry requires the exclusive lock.

If ceph_atomic_open receives a hashed, negative dentry on a non-O_CREAT
open, and another client were to race in and create the file before we
issue our OPEN, ceph_fill_trace could end up calling d_splice_alias on
the dentry with the new inode with insufficient locks.

Cc: stable@vger.kernel.org
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-11-05 15:42:44 +01:00
..
2019-09-27 15:10:34 -07:00
2019-10-23 06:14:29 -04:00
2019-09-19 09:42:37 -07:00
2019-09-19 13:09:28 -07:00
2019-07-12 17:37:53 -07:00
\n
2019-09-21 13:53:34 -07:00
2019-09-29 19:25:39 -07:00
2019-09-21 14:26:33 -07:00
2019-09-27 15:54:24 -07:00
2019-09-19 09:42:37 -07:00
2019-09-19 09:42:37 -07:00
2019-07-03 17:52:09 -04:00
2019-09-27 17:00:27 -07:00
2019-09-27 17:00:27 -07:00
2019-09-19 10:21:35 -07:00
2019-10-19 06:32:32 -04:00
2019-08-30 08:11:25 -07:00
2019-09-19 09:42:37 -07:00
2019-09-18 17:35:20 -07:00
2019-07-15 21:20:52 -07:00
2019-04-08 18:21:02 -05:00
2019-08-07 21:51:47 -04:00
2019-03-08 14:48:40 -08:00
2019-09-18 16:59:14 -07:00
2019-10-14 15:04:01 -07:00
2019-09-27 17:00:27 -07:00
2019-09-18 16:59:14 -07:00
2019-08-01 20:51:23 +02:00
2019-09-25 17:51:41 -07:00