linux-kernel - Re: [PATCH net] tipc: eliminate possible recursive locking detected by LOCKDEP

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]

Message-Id: <20181011.102603.2088827315896221671.davem@davemloft.net>
Date:   Thu, 11 Oct 2018 10:26:03 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     ying.xue@...driver.com
Cc:     jon.maloy@...csson.com, dvyukov@...gle.com,
        parthasarathy.bhuvaragan@...csson.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net] tipc: eliminate possible recursive locking
 detected by LOCKDEP

From: Ying Xue <ying.xue@...driver.com>
Date: Thu, 11 Oct 2018 19:57:56 +0800

> When booting kernel with LOCKDEP option, below warning info was found:
> 
> WARNING: possible recursive locking detected
> 4.19.0-rc7+ #14 Not tainted
 ...
> The reason why the noise above was complained by LOCKDEP is because we
> nested to hold l->wakeupq.lock and l->inputq->lock in tipc_link_reset
> function. In fact it's unnecessary to move skb buffer from l->wakeupq
> queue to l->inputq queue while holding the two locks at the same time.
> Instead, we can move skb buffers in l->wakeupq queue to a temporary
> list first and then move the buffers of the temporary list to l->inputq
> queue, which is also safe for us.
> 
> Fixes: 3f32d0be6c16 ("tipc: lock wakeup & inputq at tipc_link_reset()")
> Reported-by: Dmitry Vyukov <dvyukov@...gle.com>
> Signed-off-by: Ying Xue <ying.xue@...driver.com>

Applied.