| Message ID | 2614633.1726742450@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | afs: Fix setting of the server responding flag | expand |
diff --git a/fs/afs/fs_operation.c b/fs/afs/fs_operation.c index 3546b087e791..f9602c9a3257 100644 --- a/fs/afs/fs_operation.c +++ b/fs/afs/fs_operation.c @@ -197,13 +197,12 @@ void afs_wait_for_operation(struct afs_operation *op) op->call_abort_code = op->call->abort_code; op->call_error = op->call->error; op->call_responded = op->call->responded; + if (op->call_responded) + set_bit(AFS_SERVER_FL_RESPONDING, &op->server->flags); afs_put_call(op->call); } } - if (op->call_responded) - set_bit(AFS_SERVER_FL_RESPONDING, &op->server->flags); - if (!afs_op_error(op)) { _debug("success"); op->ops->success(op);
In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Fixes: 98f9fda2057b ("afs: Fold the afs_addr_cursor struct in") --- fs/afs/fs_operation.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)