Zach Brown wrote:
> I'm not sure that I've gotten either the sctp or lockdep details right,
> but with this patch I don't get lockdep yelling at me any more :)
>
> ------
>
> sctp: lock_sock_nested in sctp_sock_migrate
>
> sctp_sock_migrate() grabs the socket lock on a newly allocated socket while
> holding the socket lock on an old socket. lockdep worries that this might
> be a recursive lock attempt.
>
> task/3026 is trying to acquire lock:
> (sk_lock-AF_INET){--..}, at: [<ffffffff88105b8c>]
> sctp_sock_migrate+0x2e3/0x327 [sctp]
> but task is already holding lock:
> (sk_lock-AF_INET){--..}, at: [<ffffffff8810891f>] sctp_accept+0xdf/0x1e3
> [sctp]
>
> This patch tells lockdep that this locking is safe by using
> lock_sock_nested().
Hm... This is another case of of two different sockets taking the same lock...
Arjan, did this every get fixed, or is the nested locking the right solution
to this?
Thanks
-vlad
>
> Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
>
> diff -r 8adcfdf2545b net/sctp/socket.c
> --- a/net/sctp/socket.c Fri Jun 22 11:11:33 2007 -0700
> +++ b/net/sctp/socket.c Fri Jun 22 15:05:22 2007 -0700
> @@ -6084,8 +6084,11 @@ static void sctp_sock_migrate(struct soc
> * queued to the backlog. This prevents a potential race between
> * backlog processing on the old socket and new-packet processing
> * on the new socket.
> - */
> - sctp_lock_sock(newsk);
> + *
> + * The caller has just allocated newsk so we can guarantee that other
> + * paths won't try to lock it and then oldsk.
> + */
> + lock_sock_nested(newsk, SINGLE_DEPTH_NESTING);
> sctp_assoc_migrate(assoc, newsk);
>
> /* If the association on the newsk is already closed before accept()
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
