[PATCH AUTOSEL 6.17-5.4] ceph: add checking of wait_for_completion_killable() return value

[Sasha Levin <sashal@kernel.org>]

From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

[ Upstream commit b7ed1e29cfe773d648ca09895b92856bd3a2092d ]

The Coverity Scan service has detected the calling of
wait_for_completion_killable() without checking the return
value in ceph_lock_wait_for_completion() [1]. The CID 1636232
defect contains explanation: "If the function returns an error
value, the error value may be mistaken for a normal value.
In ceph_lock_wait_for_completion(): Value returned from
a function is not checked for errors before being used. (CWE-252)".

The patch adds the checking of wait_for_completion_killable()
return value and return the error code from
ceph_lock_wait_for_completion().

[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232

Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES – returning the error from the killable wait is required for correct
abort handling in the Ceph MDS client.

- `fs/ceph/locks.c:224-226` now propagates the
  `wait_for_completion_killable()` status instead of unconditionally
  succeeding. This covers the case where a task waiting for
  `req->r_safe_completion` is interrupted by a fatal signal (the helper
  returns `-ERESTARTSYS` per `kernel/sched/completion.c`), so
  `ceph_lock_wait_for_completion()` no longer hides that failure.
- `ceph_mdsc_wait_request()` relies on the wait callback’s return code
  to drive error cleanup (`fs/ceph/mds_client.c:3761-3776`): only when
  the callback returns `< 0` does it set `CEPH_MDS_R_ABORTED`, preserve
  the error, and call `ceph_invalidate_dir_request()` for write-style
  operations. With the old code the callback always returned 0, so a
  second signal during the safe-completion wait would skip that abort
  path even though `req->r_err` eventually propagates a failure; in
  turn, the caller could observe stale directory state and inconsistent
  locking semantics.
- The change is tiny, affects only the Ceph lock abort path, and has no
  dependencies. It keeps normal success cases untouched (`err == 0`
  still returns early) while making the error handling consistent.
- Given it fixes a real user-visible bug (signals during lock abort
  losing associated cleanup) with negligible regression risk, it’s a
  good candidate for the stable series.

 fs/ceph/locks.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/ceph/locks.c b/fs/ceph/locks.c
index ebf4ac0055ddc..dd764f9c64b9f 100644
--- a/fs/ceph/locks.c
+++ b/fs/ceph/locks.c
@@ -221,7 +221,10 @@ static int ceph_lock_wait_for_completion(struct ceph_mds_client *mdsc,
 	if (err && err != -ERESTARTSYS)
 		return err;
 
-	wait_for_completion_killable(&req->r_safe_completion);
+	err = wait_for_completion_killable(&req->r_safe_completion);
+	if (err)
+		return err;
+
 	return 0;
 }
 
-- 
2.51.0