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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 27 Dec 2017 16:56:24 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     tom@...ntonium.net
Cc:     netdev@...r.kernel.org, dvyukov@...gle.com, rohit@...ntonium.net
Subject: Re: [PATCH v2 net-next 0/2] kcm: Fix two locking issues

From: Tom Herbert <tom@...ntonium.net>
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.