diff options
| author | Ying Xue <ying.xue@windriver.com> | 2012-12-03 16:12:07 +0800 |
|---|---|---|
| committer | Paul Gortmaker <paul.gortmaker@windriver.com> | 2012-12-07 17:23:23 -0500 |
| commit | 258f8667a29d72b1c220065632b39c0faeb061ca (patch) | |
| tree | a01ac092de6ade5a15cb9202696c635403e0e8ea | |
| parent | cbab368790f23bc917d97fcf7a338c5ba5336ee0 (diff) | |
tipc: add lock nesting notation to quiet lockdep warning
TIPC accept() call grabs the socket lock on a newly allocated
socket while holding the socket lock on an old socket. But lockdep
worries that this might be a recursive lock attempt:
[ INFO: possible recursive locking detected ]
---------------------------------------------
kworker/u:0/6 is trying to acquire lock:
(sk_lock-AF_TIPC){+.+.+.}, at: [<c8c1226c>] accept+0x15c/0x310 [tipc]
but task is already holding lock:
(sk_lock-AF_TIPC){+.+.+.}, at: [<c8c12138>] accept+0x28/0x310 [tipc]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_TIPC);
lock(sk_lock-AF_TIPC);
*** DEADLOCK ***
May be due to missing lock nesting notation
[...]
Tell lockdep that this locking is safe by using lock_sock_nested().
This is similar to what was done in commit 5131a184a3458d9 for
SCTP code ("SCTP: lock_sock_nested in sctp_sock_migrate").
Also note that this is isn't something that is seen normally,
as it was uncovered with some experimental work-in-progress
code not yet ready for mainline. So no need for stable
backports or similar of this commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
| -rw-r--r-- | net/tipc/socket.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/net/tipc/socket.c b/net/tipc/socket.c index ef75b6270247..b5c9795cf151 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -1543,7 +1543,8 @@ static int accept(struct socket *sock, struct socket *new_sock, int flags) u32 new_ref = new_tport->ref; struct tipc_msg *msg = buf_msg(buf); - lock_sock(new_sk); + /* we lock on new_sk; but lockdep sees the lock on sk */ + lock_sock_nested(new_sk, SINGLE_DEPTH_NESTING); /* * Reject any stray messages received by new socket |