From ed0630dcf648884bf67328234c0df859baae2335 Mon Sep 17 00:00:00 2001 From: David Sheets Date: Wed, 20 Jul 2016 16:22:21 +0100 Subject: [PATCH] kernel: backport af_vsock lockdep cleanliness patch from v4.7-rc6 From torvalds/linux@4192f672fae559f32d82de72a677701853cc98a7 which was part of torvalds/linux@v4.7-rc6. The change is purely to ensure that vsock is lockdep-clean. Signed-off-by: David Sheets --- ...istener-child-lock-ordering-explicit.patch | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 alpine/kernel/patches/0041-VSOCK-make-listener-child-lock-ordering-explicit.patch diff --git a/alpine/kernel/patches/0041-VSOCK-make-listener-child-lock-ordering-explicit.patch b/alpine/kernel/patches/0041-VSOCK-make-listener-child-lock-ordering-explicit.patch new file mode 100644 index 000000000..b8e9bc33a --- /dev/null +++ b/alpine/kernel/patches/0041-VSOCK-make-listener-child-lock-ordering-explicit.patch @@ -0,0 +1,59 @@ +From 4192f672fae559f32d82de72a677701853cc98a7 Mon Sep 17 00:00:00 2001 +From: Stefan Hajnoczi +Date: Thu, 23 Jun 2016 16:28:58 +0100 +Subject: [PATCH] vsock: make listener child lock ordering explicit + +There are several places where the listener and pending or accept queue +child sockets are accessed at the same time. Lockdep is unhappy that +two locks from the same class are held. + +Tell lockdep that it is safe and document the lock ordering. + +Originally Claudio Imbrenda sent a similar +patch asking whether this is safe. I have audited the code and also +covered the vsock_pending_work() function. + +Suggested-by: Claudio Imbrenda +Signed-off-by: Stefan Hajnoczi +Signed-off-by: David S. Miller +--- + net/vmw_vsock/af_vsock.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c +index b5f1221..b96ac918 100644 +--- a/net/vmw_vsock/af_vsock.c ++++ b/net/vmw_vsock/af_vsock.c +@@ -61,6 +61,14 @@ + * function will also cleanup rejected sockets, those that reach the connected + * state but leave it before they have been accepted. + * ++ * - Lock ordering for pending or accept queue sockets is: ++ * ++ * lock_sock(listener); ++ * lock_sock_nested(pending, SINGLE_DEPTH_NESTING); ++ * ++ * Using explicit nested locking keeps lockdep happy since normally only one ++ * lock of a given class may be taken at a time. ++ * + * - Sockets created by user action will be cleaned up when the user process + * calls close(2), causing our release implementation to be called. Our release + * implementation will perform some cleanup then drop the last reference so our +@@ -443,7 +451,7 @@ void vsock_pending_work(struct work_struct *work) + cleanup = true; + + lock_sock(listener); +- lock_sock(sk); ++ lock_sock_nested(sk, SINGLE_DEPTH_NESTING); + + if (vsock_is_pending(sk)) { + vsock_remove_pending(listener, sk); +@@ -1292,7 +1300,7 @@ static int vsock_accept(struct socket *sock, struct socket *newsock, int flags) + if (connected) { + listener->sk_ack_backlog--; + +- lock_sock(connected); ++ lock_sock_nested(connected, SINGLE_DEPTH_NESTING); + vconnected = vsock_sk(connected); + + /* If the listener socket has received an error, then we should