lkml.org 
[lkml]   [2019]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject[PATCH net 0/3] rxrpc: Fixes
From
Date

Here are a couple of bugfixes plus a patch that makes one of the bugfixes
easier:

(1) Move the ping and mutex unlock on a new call from rxrpc_input_packet()
into rxrpc_new_incoming_call(), which it calls. This means the
lock-unlock section is entirely within the latter function. This
simplifies patch (2).

(2) Don't take the call->user_mutex at all in the softirq path. Mutexes
aren't allowed to be taken or released there and a patch was merged
that caused a warning to be emitted every time this happened. Looking
at the code again, it looks like that taking the mutex isn't actually
necessary, as the value of call->state will block access to the call.

(3) Fix the incoming call path to check incoming calls earlier to reject
calls to RPC services for which we don't have a security key of the
appropriate class. This avoids an assertion failure if YFS tries
making a secure call to the kafs cache manager RPC service.

The patches are tagged here:

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-fixes-20191220

and can also be found on the following branch:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes

David
---
David Howells (3):
rxrpc: Unlock new call in rxrpc_new_incoming_call() rather than the caller
rxrpc: Don't take call->user_mutex in rxrpc_new_incoming_call()
rxrpc: Fix missing security check on incoming calls


net/rxrpc/ar-internal.h | 10 +++++--
net/rxrpc/call_accept.c | 60 ++++++++++++++++++++++++---------------
net/rxrpc/conn_event.c | 16 +----------
net/rxrpc/conn_service.c | 4 +++
net/rxrpc/input.c | 18 ------------
net/rxrpc/rxkad.c | 5 ++-
net/rxrpc/security.c | 70 ++++++++++++++++++++++------------------------
7 files changed, 85 insertions(+), 98 deletions(-)

\
 
 \ /
  Last update: 2019-12-21 00:06    [W:0.032 / U:4.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site