linux.git/fs/ceph/caps.c, branch v5.9

ceph: fix inode number handling on arches with 32-bit ino_t

2020-08-24T15:25:26+00:00

Tuan and Ulrich mentioned that they were hitting a problem on s390x,
which has a 32-bit ino_t value, even though it's a 64-bit arch (for
historical reasons).

I think the current handling of inode numbers in the ceph driver is
wrong. It tries to use 32-bit inode numbers on 32-bit arches, but that's
actually not a problem. 32-bit arches can deal with 64-bit inode numbers
just fine when userland code is compiled with LFS support (the common
case these days).

What we really want to do is just use 64-bit numbers everywhere, unless
someone has mounted with the ino32 mount option. In that case, we want
to ensure that we hash the inode number down to something that will fit
in 32 bits before presenting the value to userland.

Add new helper functions that do this, and only do the conversion before
presenting these values to userland in getattr and readdir.

The inode table hashvalue is changed to just cast the inode number to
unsigned long, as low-order bits are the most likely to vary anyway.

While it's not strictly required, we do want to put something in
inode->i_ino. Instead of basing it on BITS_PER_LONG, however, base it on
the size of the ino_t type.

NOTE: This is a user-visible change on 32-bit arches:

1/ inode numbers will be seen to have changed between kernel versions.
   32-bit arches will see large inode numbers now instead of the hashed
   ones they saw before.

2/ any really old software not built with LFS support may start failing
   stat() calls with -EOVERFLOW on inode numbers >2^32. Nothing much we
   can do about these, but hopefully the intersection of people running
   such code on ceph will be very small.

The workaround for both problems is to mount with "-o ino32".

[ idryomov: changelog tweak ]

URL: https://tracker.ceph.com/issues/46828
Reported-by: Ulrich Weigand 
Reported-and-Tested-by: Tuan Hoang1 
Signed-off-by: Jeff Layton 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov

ceph: clean up and optimize ceph_check_delayed_caps()

2020-08-03T09:05:21+00:00

Make this loop look a bit more sane. Also optimize away the spinlock
release/reacquire if we can't get an inode reference.

Signed-off-by: Jeff Layton 
Reviewed-by: Xiubo Li 
Signed-off-by: Ilya Dryomov

ceph: add global total_caps to count the mdsc's total caps number

2020-08-03T09:05:15+00:00

This will help to reduce using the global mdsc->mutex lock in many
places.

Signed-off-by: Xiubo Li 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: skip checking caps when session reconnecting and releasing reqs

2020-06-01T11:22:53+00:00

It make no sense to check the caps when reconnecting to mds. And
for the async dirop caps, they will be put by its _cb() function,
so when releasing the requests, it will make no sense too.

URL: https://tracker.ceph.com/issues/45635
Signed-off-by: Xiubo Li 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov

ceph: ceph_kick_flushing_caps needs the s_mutex

2020-06-01T11:22:53+00:00

The mdsc->cap_dirty_lock is not held while walking the list in
ceph_kick_flushing_caps, which is not safe.

ceph_early_kick_flushing_caps does something similar, but the
s_mutex is held while it's called and I think that guards against
changes to the list.

Ensure we hold the s_mutex when calling ceph_kick_flushing_caps,
and add some clarifying comments.

Signed-off-by: Jeff Layton 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov

ceph: request expedited service on session's last cap flush

2020-06-01T11:22:52+00:00

When flushing a lot of caps to the MDS's at once (e.g. for syncfs),
we can end up waiting a substantial amount of time for MDS replies, due
to the fact that it may delay some of them so that it can batch them up
together in a single journal transaction. This can lead to stalls when
calling sync or syncfs.

What we'd really like to do is request expedited service on the _last_
cap we're flushing back to the server. If the CHECK_CAPS_FLUSH flag is
set on the request and the current inode was the last one on the
session->s_cap_dirty list, then mark the request with
CEPH_CLIENT_CAPS_SYNC.

Note that this heuristic is not perfect. New inodes can race onto the
list after we've started flushing, but it does seem to fix some common
use cases.

URL: https://tracker.ceph.com/issues/44744
Reported-by: Jan Fajerski 
Signed-off-by: Jeff Layton 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov

ceph: convert mdsc->cap_dirty to a per-session list

2020-06-01T11:22:52+00:00

This is a per-sb list now, but that makes it difficult to tell when
the cap is the last dirty one associated with the session. Switch
this to be a per-session list, but continue using the
mdsc->cap_dirty_lock to protect the lists.

This list is only ever walked in ceph_flush_dirty_caps, so change that
to walk the sessions array and then flush the caps for inodes on each
session's list.

If the auth cap ever changes while the inode has dirty caps, then
move the inode to the appropriate session for the new auth_cap. Also,
ensure that we never remove an auth cap while the inode is still on the
s_cap_dirty list.

Signed-off-by: Jeff Layton 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov

ceph: reset i_requested_max_size if file write is not wanted

2020-06-01T11:22:52+00:00

write can stuck at waiting for larger max_size in following sequence of
events:

- client opens a file and writes to position 'A' (larger than unit of
  max size increment)
- client closes the file handle and updates wanted caps (not wanting
  file write caps)
- client opens and truncates the file, writes to position 'A' again.

At the 1st event, client set inode's requested_max_size to 'A'. At the
2nd event, mds removes client's writable range, but client does not reset
requested_max_size. At the 3rd event, client does not request max size
because requested_max_size is already larger than 'A'.

Signed-off-by: "Yan, Zheng" 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: fix potential race in ceph_check_caps

2020-06-01T11:22:52+00:00

Nothing ensures that session will still be valid by the time we
dereference the pointer. Take and put a reference.

In principle, we should always be able to get a reference here, but
throw a warning if that's ever not the case.

Signed-off-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: don't take i_ceph_lock in handle_cap_import

2020-06-01T11:22:52+00:00

Just take it before calling it. This means we have to do a couple of
minor in-memory operations under the spinlock now, but those shouldn't
be an issue.

Signed-off-by: Jeff Layton 
Signed-off-by: Ilya Dryomov