Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4320497imu; Mon, 14 Jan 2019 20:26:27 -0800 (PST) X-Google-Smtp-Source: ALg8bN6QwF9c2awccvOBAhDadev/ZyAxf34TA40Bij351BBJ8S9R0quygMjbIilZn467Tk19hxrF X-Received: by 2002:a63:2f86:: with SMTP id v128mr1919348pgv.407.1547526387417; Mon, 14 Jan 2019 20:26:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547526387; cv=none; d=google.com; s=arc-20160816; b=xtvtlCp698G86j59+nRrYt21LNCqFoUhx7PShI+v7aKhHdnJaxJkyO+vStPtWqRZEp 6e3wBTw6CxPNxJ+3uaseQQgrJ7D3TQ7gK+ZybPJlLZnLlpzK4zDk5Koh8Kfcf4qJB6XL bMfaXvRaLQtkKOX1dJKpcT5lRfyE1g9T8H7j19RcZCJrQrf1QA/3/fHK0yikxRBtMai1 bxyzrYXGRldzXZA97nMfxwAAjRAdSR9IhHpgROQzS0JIDFbzOew8xTvxk5ZwoXEAg1Cv tlcQK1Ytm3rVsQhy1D+Wa0ZNjfi9zq4qkOv4mSPr5sbigChCz8Ee27HS1P29IJsnGieh iujA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=a4IcEmUIjzUmf4lYDUOrPdmybeiSIqpcFa7M4MwBJU0=; b=qDnDBYwipeteUMcdG5rfo2gi+N+iNek5eMSo3gkwUQ1dsIVbMt9w9V118hGZ8SqLy0 8SMTzucRPW66Vf64zuXL6iOU2bue4yUhrCGuvs1xclb7lOxioQw2jWcSStaWK3hOW2pp WOWhwIVf+Kj9NCfbdVqm+T8npk1aUn3ucWwUq3pOBgxqxNgFF3IiCp3QZd0Y34tWXXct zXUUV8tUPlogg5e9qa+wvrM1Y2nlj/D2sSRVIe8enUwmx8QFjyTT3YAWyH9qBWKoeEHQ Tu9OTtT2NMU+xN2rfhThdoNwjpNC7IFBvLqASOTLM3A7/PscjZ6uH2PSTDkQKcX3VLZy pK7g== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r14si2341221pgk.75.2019.01.14.20.26.12; Mon, 14 Jan 2019 20:26:27 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728132AbfAOEAX (ORCPT + 99 others); Mon, 14 Jan 2019 23:00:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38630 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727547AbfAOEAX (ORCPT ); Mon, 14 Jan 2019 23:00:23 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CDBE52D7FF; Tue, 15 Jan 2019 04:00:22 +0000 (UTC) Received: from localhost (ovpn-8-20.pek2.redhat.com [10.72.8.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id BD7015D9CA; Tue, 15 Jan 2019 04:00:04 +0000 (UTC) From: Ming Lei To: Jens Axboe Cc: linux-block@vger.kernel.org, Ming Lei , Clark Williams , Guenter Roeck , Steven Rostedt , Linus Torvalds , linux-kernel@vger.kernel.org Subject: [PATCH] sbitmap: Protect swap_lock from hardirq Date: Tue, 15 Jan 2019 11:59:52 +0800 Message-Id: <20190115035952.13325-1-ming.lei@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 15 Jan 2019 04:00:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The original report is actually one real deadlock: [ 106.132865] Possible interrupt unsafe locking scenario: [ 106.132865] [ 106.133659] CPU0 CPU1 [ 106.134194] ---- ---- [ 106.134733] lock(&(&sb->map[i].swap_lock)->rlock); [ 106.135318] local_irq_disable(); [ 106.136014] lock(&sbq->ws[i].wait); [ 106.136747] lock(&(&hctx->dispatch_wait_lock)->rlock); [ 106.137742] [ 106.138110] lock(&sbq->ws[i].wait); Because we may call blk_mq_get_driver_tag() directly from blk_mq_dispatch_rq_list() without holding any lock, then HARDIRQ may come and the above DEADLOCK is triggered. ab53dcfb3e7b ("sbitmap: Protect swap_lock from hardirq") tries to fix this issue by using 'spin_lock_bh', which isn't enough because we complete request from hardirq context direclty in case of multiqueue. Cc: Clark Williams Fixes: ab53dcfb3e7b ("sbitmap: Protect swap_lock from hardirq") Cc: Jens Axboe Cc: Ming Lei Cc: Guenter Roeck Cc: Steven Rostedt (VMware) Cc: Linus Torvalds Cc: linux-kernel@vger.kernel.org Signed-off-by: Ming Lei --- lib/sbitmap.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/sbitmap.c b/lib/sbitmap.c index 864354000e04..5b382c1244ed 100644 --- a/lib/sbitmap.c +++ b/lib/sbitmap.c @@ -27,8 +27,9 @@ static inline bool sbitmap_deferred_clear(struct sbitmap *sb, int index) { unsigned long mask, val; bool ret = false; + unsigned long flags; - spin_lock_bh(&sb->map[index].swap_lock); + spin_lock_irqsave(&sb->map[index].swap_lock, flags); if (!sb->map[index].cleared) goto out_unlock; @@ -49,7 +50,7 @@ static inline bool sbitmap_deferred_clear(struct sbitmap *sb, int index) ret = true; out_unlock: - spin_unlock_bh(&sb->map[index].swap_lock); + spin_unlock_irqrestore(&sb->map[index].swap_lock, flags); return ret; } -- 2.14.4