From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21DB2C43387 for ; Tue, 8 Jan 2019 19:33:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DD71A20827 for ; Tue, 8 Jan 2019 19:33:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546976021; bh=P+WvAiFqn7Lm5ontZNRDQ3bLzZ7nWF1+k+tJK6m8Tpw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=QXetlyQB2i151EmfoOCdG3QO2qE5ajFYsZw4Aqg4gB7X8h58ybtx4c2p5UsO8dOsD cuvucmzO2Ud/cSGwmojKQGQ/vVsHFVpeECzKNWRk2HEzN7CcPJ2FsK/f8hWQhuCcK+ zpGcKNDRB/H9L7aAuinTrajY/t46NQ84h3hbCxsg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731772AbfAHTdj (ORCPT ); Tue, 8 Jan 2019 14:33:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:42382 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730491AbfAHTdf (ORCPT ); Tue, 8 Jan 2019 14:33:35 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1623220827; Tue, 8 Jan 2019 19:33:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546976014; bh=P+WvAiFqn7Lm5ontZNRDQ3bLzZ7nWF1+k+tJK6m8Tpw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xIyTqg2x4x5wDOGL5m69eh6o+40sP0u/wOtWHEi0frKz5uGhANBz4Fbz3LOnJj0Sc PrABkUVgXETzSttWtcl8SoFWzoKVFL902ej7e414RxMRdYYQLyXp+7wIciAqVlrXcB A/BxOP8ZZSBRA+PQnYWBLw5qKK9uS0tV9NhKhwuA= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Parvi Kaustubhi , Jason Gunthorpe , Sasha Levin , linux-rdma@vger.kernel.org Subject: [PATCH AUTOSEL 4.14 46/53] IB/usnic: Fix potential deadlock Date: Tue, 8 Jan 2019 14:32:14 -0500 Message-Id: <20190108193222.123316-46-sashal@kernel.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20190108193222.123316-1-sashal@kernel.org> References: <20190108193222.123316-1-sashal@kernel.org> MIME-Version: 1.0 X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Parvi Kaustubhi [ Upstream commit 8036e90f92aae2784b855a0007ae2d8154d28b3c ] Acquiring the rtnl lock while holding usdev_lock could result in a deadlock. For example: usnic_ib_query_port() | mutex_lock(&us_ibdev->usdev_lock) | ib_get_eth_speed() | rtnl_lock() rtnl_lock() | usnic_ib_netdevice_event() | mutex_lock(&us_ibdev->usdev_lock) This commit moves the usdev_lock acquisition after the rtnl lock has been released. This is safe to do because usdev_lock is not protecting anything being accessed in ib_get_eth_speed(). Hence, the correct order of holding locks (rtnl -> usdev_lock) is not violated. Signed-off-by: Parvi Kaustubhi Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin --- drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c index 3c3453d213dc..fdfa25059723 100644 --- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c +++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c @@ -310,13 +310,16 @@ int usnic_ib_query_port(struct ib_device *ibdev, u8 port, usnic_dbg("\n"); - mutex_lock(&us_ibdev->usdev_lock); if (ib_get_eth_speed(ibdev, port, &props->active_speed, - &props->active_width)) { - mutex_unlock(&us_ibdev->usdev_lock); + &props->active_width)) return -EINVAL; - } + /* + * usdev_lock is acquired after (and not before) ib_get_eth_speed call + * because acquiring rtnl_lock in ib_get_eth_speed, while holding + * usdev_lock could lead to a deadlock. + */ + mutex_lock(&us_ibdev->usdev_lock); /* props being zeroed by the caller, avoid zeroing it here */ props->lid = 0; -- 2.19.1