Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp147563imd; Wed, 31 Oct 2018 16:16:04 -0700 (PDT) X-Google-Smtp-Source: AJdET5fowx8pjDWldWCwhEGAjLv8xgbHNHD/LLGtUyEtHB5WwTzIf88EA5WAaONhhg8y3yoPLo42 X-Received: by 2002:a63:f710:: with SMTP id x16mr4999643pgh.322.1541027763943; Wed, 31 Oct 2018 16:16:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541027763; cv=none; d=google.com; s=arc-20160816; b=lqVGbEUJGOs2ZVPHe+6P4UezAzmnqh1EYtiHAvh36r66StCxCA5nNFRARulvWyc8oO EPFdNAPPeCKxOznoxHCWJ/8U8Knp0gl2GsjzDIzonNbFroYjCFo2Gphi9eAIR1bLOwR9 iqhAJpnSaxn7+a1G/ez4q0IkmVhFcth596KAr9ifWL/sduxIr8VgOfn3RJVQIvV49bN1 mKASiupV/jH3LOJjE6BtzcXj8VujLGCtJm9W0pfknWtrnhwHR+pTNhYzpYuOdsoE2WEG f0Enihl3lZuJ/c96eqepZf3pcakIC+PZZq3H7h2xng9JRwo8VHLczYUZP0ZhWPuBrVZ7 /h7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=u0AiWAQIoCSYxuPzXqVkijob+dhKzgeQtDEXz94bduI=; b=aG2/3il4X4NXZDyff24RaJpm6Cdm5JjKX5Mkn6F2mHawOOrRB+Pr0Oik0lL3Tu1KJp BnnCToNYd/uqibaX5L+LW1oqJsAAFTbtxsB9Fw39rxpOFhJq96bxKkD8N+K3g/zQQtBM U96s80g1jABkkGE7n9GwQlpTw5CQP9gPFOBuZ/a4MZR5xVvcR+FtCpDu4RXL92O3HRCU jXslGLA6HJPqmUXKiDsI3gCwXtdHu/rKfUtzU8uYfkwZj9zu+1JwQ52zhkHW5mP+Pj6f 6o6Vp7h14mwKf8TOmyg8VGEAiQ89K7R/0OyXd5geJp9ZDwT5hUlLjdZptbZhLXF0IHhc zsSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qr0hXBk+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h184-v6si28244984pfe.72.2018.10.31.16.15.49; Wed, 31 Oct 2018 16:16:03 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qr0hXBk+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732169AbeKAIMQ (ORCPT + 99 others); Thu, 1 Nov 2018 04:12:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:36894 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732094AbeKAIMP (ORCPT ); Thu, 1 Nov 2018 04:12:15 -0400 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 891F821019; Wed, 31 Oct 2018 23:12:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541027522; bh=W1w1iQvZ7j6HJ5IJbqYkXuYQvyiwMiBc7e2AeWQIl+s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qr0hXBk+pYMR4JG8TDx8MNumcQtJDNafzGWA13rezSOArCZIlc9f6A8cAai6JkjaQ 0cPkB1nPOSnMEPSdmrVuIVWpDdkdNVEIoPOPDLS2+m1zcQw8B1uDAzzvpERlCe78gn GGAJq/dVl3i5eyV7pY2dfPngP+vrMSHJsgUMMSus= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Waiman Long , Vinod Koul , Sasha Levin Subject: [PATCH AUTOSEL 4.4 27/32] driver/dma/ioat: Call del_timer_sync() without holding prep_lock Date: Wed, 31 Oct 2018 19:11:32 -0400 Message-Id: <20181031231137.29429-27-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181031231137.29429-1-sashal@kernel.org> References: <20181031231137.29429-1-sashal@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Waiman Long [ Upstream commit cfb03be6c7e8a1591285849c361d67b09f5149f7 ] The following lockdep splat was observed: [ 1222.241750] ====================================================== [ 1222.271301] WARNING: possible circular locking dependency detected [ 1222.301060] 4.16.0-10.el8+5.x86_64+debug #1 Not tainted [ 1222.326659] ------------------------------------------------------ [ 1222.356565] systemd-shutdow/1 is trying to acquire lock: [ 1222.382660] ((&ioat_chan->timer)){+.-.}, at: [<00000000f71e1a28>] del_timer_sync+0x5/0xf0 [ 1222.422928] [ 1222.422928] but task is already holding lock: [ 1222.451743] (&(&ioat_chan->prep_lock)->rlock){+.-.}, at: [<000000008ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma] : [ 1223.524987] Chain exists of: [ 1223.524987] (&ioat_chan->timer) --> &(&ioat_chan->cleanup_lock)->rlock --> &(&ioat_chan->prep_lock)->rlock [ 1223.524987] [ 1223.594082] Possible unsafe locking scenario: [ 1223.594082] [ 1223.622630] CPU0 CPU1 [ 1223.645080] ---- ---- [ 1223.667404] lock(&(&ioat_chan->prep_lock)->rlock); [ 1223.691535] lock(&(&ioat_chan->cleanup_lock)->rlock); [ 1223.728657] lock(&(&ioat_chan->prep_lock)->rlock); [ 1223.765122] lock((&ioat_chan->timer)); [ 1223.784095] [ 1223.784095] *** DEADLOCK *** [ 1223.784095] [ 1223.813492] 4 locks held by systemd-shutdow/1: [ 1223.834677] #0: (reboot_mutex){+.+.}, at: [<0000000056d33456>] SYSC_reboot+0x10f/0x300 [ 1223.873310] #1: (&dev->mutex){....}, at: [<00000000258dfdd7>] device_shutdown+0x1c8/0x660 [ 1223.913604] #2: (&dev->mutex){....}, at: [<0000000068331147>] device_shutdown+0x1d6/0x660 [ 1223.954000] #3: (&(&ioat_chan->prep_lock)->rlock){+.-.}, at: [<000000008ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma] In the ioat_shutdown() function: spin_lock_bh(&ioat_chan->prep_lock); set_bit(IOAT_CHAN_DOWN, &ioat_chan->state); del_timer_sync(&ioat_chan->timer); spin_unlock_bh(&ioat_chan->prep_lock); According to the synchronization rule for the del_timer_sync() function, the caller must not hold locks which would prevent completion of the timer's handler. The timer structure has its own lock that manages its synchronization. Setting the IOAT_CHAN_DOWN bit should prevent other CPUs from trying to use that device anyway, there is probably no need to call del_timer_sync() while holding the prep_lock. So the del_timer_sync() call is now moved outside of the prep_lock critical section to prevent the circular lock dependency. Signed-off-by: Waiman Long Reviewed-by: Dave Jiang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/ioat/init.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c index ac8c28968422..106fa9b327d9 100644 --- a/drivers/dma/ioat/init.c +++ b/drivers/dma/ioat/init.c @@ -1210,8 +1210,15 @@ static void ioat_shutdown(struct pci_dev *pdev) spin_lock_bh(&ioat_chan->prep_lock); set_bit(IOAT_CHAN_DOWN, &ioat_chan->state); - del_timer_sync(&ioat_chan->timer); spin_unlock_bh(&ioat_chan->prep_lock); + /* + * Synchronization rule for del_timer_sync(): + * - The caller must not hold locks which would prevent + * completion of the timer's handler. + * So prep_lock cannot be held before calling it. + */ + del_timer_sync(&ioat_chan->timer); + /* this should quiesce then reset */ ioat_reset_hw(ioat_chan); } -- 2.17.1