Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 11 Oct 2018 10:26:03 -0700 (PDT)
Message-Id: <20181011.102603.2088827315896221671.davem@davemloft.net>
To:     ying.xue@windriver.com
Cc:     jon.maloy@ericsson.com, dvyukov@google.com,
        parthasarathy.bhuvaragan@ericsson.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, tipc-discussion@lists.sourceforge.net
Subject: Re: [PATCH net] tipc: eliminate possible recursive locking
 detected by LOCKDEP
From:   David Miller <davem@davemloft.net>
In-Reply-To: <1539259076-8562-1-git-send-email-ying.xue@windriver.com>
References: <1539259076-8562-1-git-send-email-ying.xue@windriver.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Ying Xue <ying.xue@windriver.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@google.com>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>

Applied.