linux-stable.git/fs/ceph, branch v5.14.2

ceph: fix possible null-pointer dereference in ceph_mdsmap_decode()

2021-08-25T14:34:11+00:00

kcalloc() is called to allocate memory for m->m_info, and if it fails,
ceph_mdsmap_destroy() behind the label out_err will be called:
  ceph_mdsmap_destroy(m);

In ceph_mdsmap_destroy(), m->m_info is dereferenced through:
  kfree(m->m_info[i].export_targets);

To fix this possible null-pointer dereference, check m->m_info before the
for loop to free m->m_info[i].export_targets.

[ jlayton: fix up whitespace damage
	   only kfree(m->m_info) if it's non-NULL ]

Reported-by: TOTE Robot 
Signed-off-by: Tuo Li 
Signed-off-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: correctly handle releasing an embedded cap flush

2021-08-25T14:34:11+00:00

The ceph_cap_flush structures are usually dynamically allocated, but
the ceph_cap_snap has an embedded one.

When force umounting, the client will try to remove all the session
caps. During this, it will free them, but that should not be done
with the ones embedded in a capsnap.

Fix this by adding a new boolean that indicates that the cap flush is
embedded in a capsnap, and skip freeing it if that's set.

At the same time, switch to using list_del_init() when detaching the
i_list and g_list heads.  It's possible for a forced umount to remove
these objects but then handle_cap_flushsnap_ack() races in and does the
list_del_init() again, corrupting memory.

Cc: stable@vger.kernel.org
URL: https://tracker.ceph.com/issues/52283
Signed-off-by: Xiubo Li 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: take snap_empty_lock atomically with snaprealm refcount change

2021-08-04T17:20:29+00:00

There is a race in ceph_put_snap_realm. The change to the nref and the
spinlock acquisition are not done atomically, so you could decrement
nref, and before you take the spinlock, the nref is incremented again.
At that point, you end up putting it on the empty list when it
shouldn't be there. Eventually __cleanup_empty_realms runs and frees
it when it's still in-use.

Fix this by protecting the 1->0 transition with atomic_dec_and_lock,
and just drop the spinlock if we can get the rwsem.

Because these objects can also undergo a 0->1 refcount transition, we
must protect that change as well with the spinlock. Increment locklessly
unless the value is at 0, in which case we take the spinlock, increment
and then take it off the empty list if it did the 0->1 transition.

With these changes, I'm removing the dout() messages from these
functions, as well as in __put_snap_realm. They've always been racy, and
it's better to not print values that may be misleading.

Cc: stable@vger.kernel.org
URL: https://tracker.ceph.com/issues/46419
Reported-by: Mark Nelson 
Signed-off-by: Jeff Layton 
Reviewed-by: Luis Henriques 
Signed-off-by: Ilya Dryomov

ceph: reduce contention in ceph_check_delayed_caps()

2021-08-04T17:20:05+00:00

Function ceph_check_delayed_caps() is called from the mdsc->delayed_work
workqueue and it can be kept looping for quite some time if caps keep
being added back to the mdsc->cap_delay_list.  This may result in the
watchdog tainting the kernel with the softlockup flag.

This patch breaks this loop if the caps have been recently (i.e. during
the loop execution).  Any new caps added to the list will be handled in
the next run.

Also, allow schedule_delayed() callers to explicitly set the delay value
instead of defaulting to 5s, so we can ensure that it runs soon
afterward if it looks like there is more work.

Cc: stable@vger.kernel.org
URL: https://tracker.ceph.com/issues/46284
Signed-off-by: Luis Henriques 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: don't WARN if we're still opening a session to an MDS

2021-07-20T15:57:33+00:00

If MDSs aren't available while mounting a filesystem, the session state
will transition from SESSION_OPENING to SESSION_CLOSING.  And in that
scenario check_session_state() will be called from delayed_work() and
trigger this WARN.

Avoid this by only WARNing after a session has already been established
(i.e., the s_ttl will be different from 0).

Fixes: 62575e270f66 ("ceph: check session state after bumping session->s_seq")
Signed-off-by: Luis Henriques 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov

ceph: take reference to req->r_parent at point of assignment

2021-06-28T22:15:52+00:00

Currently, we set the r_parent pointer but then don't take a reference
to it until we submit the request. If we end up freeing the req before
that point, then we'll do a iput when we shouldn't.

Instead, take the inode reference in the callers, so that it's always
safe to call ceph_mdsc_put_request on the req, even before submission.

Signed-off-by: Jeff Layton 
Reviewed-by: Luis Henriques 
Signed-off-by: Ilya Dryomov

ceph: eliminate ceph_async_iput()

2021-06-28T22:15:52+00:00

Now that we don't need to hold session->s_mutex or the snap_rwsem when
calling ceph_check_caps, we can eliminate ceph_async_iput and just use
normal iput calls.

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

ceph: don't take s_mutex in ceph_flush_snaps

2021-06-28T22:15:52+00:00

Signed-off-by: Jeff Layton 
Reviewed-by: Luis Henriques 
Signed-off-by: Ilya Dryomov

ceph: don't take s_mutex in try_flush_caps

2021-06-28T22:15:52+00:00

The s_mutex doesn't protect anything in this codepath.

Signed-off-by: Jeff Layton 
Reviewed-by: Luis Henriques 
Signed-off-by: Ilya Dryomov

ceph: don't take s_mutex or snap_rwsem in ceph_check_caps

2021-06-28T22:15:52+00:00

These locks appear to be completely unnecessary. Almost all of this
function is done under the inode->i_ceph_lock, aside from the actual
sending of the message. Don't take either lock in this function.

Signed-off-by: Jeff Layton 
Reviewed-by: Luis Henriques 
Signed-off-by: Ilya Dryomov