afs: Fix race in async call refcounting
authorDavid Howells <dhowells@redhat.com>
Thu, 10 Jan 2019 15:40:50 +0000 (15:40 +0000)
committerDavid Howells <dhowells@redhat.com>
Thu, 17 Jan 2019 15:17:28 +0000 (15:17 +0000)
commit34fa47612bfe5d7de7fcaf658a6952b6aeec3b13
treeda3d177e153d5cf07192e355bb885d4f9a799279
parent7a75b0079a1d54e342c502c3c8107ba97e05d3d3
afs: Fix race in async call refcounting

There's a race between afs_make_call() and afs_wake_up_async_call() in the
case that an error is returned from rxrpc_kernel_send_data() after it has
queued the final packet.

afs_make_call() will try and clean up the mess, but the call state may have
been moved on thereby causing afs_process_async_call() to also try and to
delete the call.

Fix this by:

 (1) Getting an extra ref for an asynchronous call for the call itself to
     hold.  This makes sure the call doesn't evaporate on us accidentally
     and will allow the call to be retained by the caller in a future
     patch.  The ref is released on leaving afs_make_call() or
     afs_wait_for_call_to_complete().

 (2) In the event of an error from rxrpc_kernel_send_data():

     (a) Don't set the call state to AFS_CALL_COMPLETE until *after* the
       call has been aborted and ended.  This prevents
       afs_deliver_to_call() from doing anything with any notifications
       it gets.

     (b) Explicitly end the call immediately to prevent further callbacks.

     (c) Cancel any queued async_work and wait for the work if it's
       executing.  This allows us to be sure the race won't recur when we
       change the state.  We put the work queue's ref on the call if we
       managed to cancel it.

     (d) Put the call's ref that we got in (1).  This belongs to us as long
       as the call is in state AFS_CALL_CL_REQUESTING.

Fixes: 341f741f04be ("afs: Refcount the afs_call struct")
Signed-off-by: David Howells <dhowells@redhat.com>
fs/afs/rxrpc.c
include/trace/events/afs.h