Re: [PATCH v2 net-next 0/2] kcm: Fix two locking issues

2017-12-27 Thread David Miller
From: Tom Herbert 
Date: Sat, 23 Dec 2017 09:17:14 -0800

> One issue is lockdep warnings when sock_owned_by_user returns true
> in strparser. Fix is to add and call sock_owned_by_user_nocheck since
> the check for owned by user is not an error condition in this case.
> 
> The other issue is a potential deadlock between TX and RX paths
> 
> KCM socket lock and the psock socket lock are acquired in both
> the RX and TX path, however they take the locks in opposite order
> which can lead to deadlock. The fix is to add try_sock_lock to see
> if psock socket lock can get acquired in the TX path with KCM lock
> held. If not, then KCM socket is released and the psock socket lock
> and KCM socket lock are acquired in the same order as the RX path.
> 
> Tested:
> 
> Ran KCM traffic without incident.
> 
> v2: Remove patches to address potential deadlock. I couldn't convince
> myself this is an issue after looking at the code some more.

If this fixes real locking bugs you should target them at 'net' not
'net-next'.

I also see you telling some people hitting kcm locking problems to
test "the patch" but you give them no idea what patch you are even
talking about.

Is it this series?  Nobody knows.

Please poing them at exactly what patch you want them to test, get
their testing results, and add appropriate Tested-by: tags as you
respin this for 'net'.

Thanks.


[PATCH v2 net-next 0/2] kcm: Fix two locking issues

2017-12-23 Thread Tom Herbert
One issue is lockdep warnings when sock_owned_by_user returns true
in strparser. Fix is to add and call sock_owned_by_user_nocheck since
the check for owned by user is not an error condition in this case.

The other issue is a potential deadlock between TX and RX paths

KCM socket lock and the psock socket lock are acquired in both
the RX and TX path, however they take the locks in opposite order
which can lead to deadlock. The fix is to add try_sock_lock to see
if psock socket lock can get acquired in the TX path with KCM lock
held. If not, then KCM socket is released and the psock socket lock
and KCM socket lock are acquired in the same order as the RX path.

Tested:

Ran KCM traffic without incident.

v2: Remove patches to address potential deadlock. I couldn't convince
myself this is an issue after looking at the code some more.


Tom Herbert (2):
  sock: Add sock_owned_by_user_nocheck
  strparser: Call sock_owned_by_user_nocheck

 include/net/sock.h| 5 +
 net/strparser/strparser.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.11.0