Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4320498imu; Mon, 14 Jan 2019 20:26:27 -0800 (PST) X-Google-Smtp-Source: ALg8bN7VsxBK70ce9UW44hGS4bj88MSzzdArNXKO+HYWmrnRnA8PlE++ITmHCYpQksWR/DoU8Ol5 X-Received: by 2002:a17:902:e20b:: with SMTP id ce11mr2018644plb.251.1547526387465; 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=XKutsck9PV6pX0ulAps2tkxVO6KK7pWrdMvQ0skYxJeVXu6ea6vny0pWsg9dd648QY pbyT9CnVWpvD6io7WPXchVCavXfuCuc+bxvVsysQWBbZqxjdtoZJGBdW19+VIajhWKfg +JvVTMCsb89Ox0MbjPtR/c1zgF1mfz3Bcst8mo0R+Bvn3Kb8MEjD0wkAsaudd6UPICaW Twv3H1RQ0OqzJetO5Hm03O4Rk3Cm98manMdNr8h0iI43hlQsS93PG/5KvFQW47UwAa/v sgSvCitbcYodU6y9Dpr6+LgdC/hayA0lRRbJQS9z/9C0drrnTnp/KfQY9NCpwuAsbDgn b7hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=nAMEiPml6AffsSS0rNCaEsMvWGdbKtkypkHMcNg3DEY=; b=yJYXdox/tUqB/CLNWXYHAh/VPvRea5jZwZigGK7YKevjrdwpw0u0ugPkxA5r2IDPSx LwzSfMyFEx469RZfLoRMDxh3htlljVzug0CqnXqX8+Wuzb07MaOmjk8aFO5kFBW8M7gT zWqckeHV0uO4Il1t67c96CvmQHZklY227o9rTBI/G+ZoDunXPE7ALuHQhYnablXpVlEc XQF/haAVPxHBHZZqY613UUS29Fmid6NWYSOygqIaEOUxfiGjQOmNgcbO3OeTT2nywyL2 HF9caLNa/8lUxD/oz4uoau7SBEx99gbzbMJz9Ww8/S2jFvzTVyQjfrpABk7qCgEA7s5n GhLA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b70si2170403pfe.168.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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728004AbfAODuV (ORCPT + 99 others); Mon, 14 Jan 2019 22:50:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:46470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726769AbfAODuV (ORCPT ); Mon, 14 Jan 2019 22:50:21 -0500 Received: from vmware.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE70820859; Tue, 15 Jan 2019 03:50:19 +0000 (UTC) Date: Mon, 14 Jan 2019 22:50:17 -0500 From: Steven Rostedt To: Ming Lei Cc: Jens Axboe , LKML , Linus Torvalds , Andrew Morton , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Clark Williams , Bart Van Assche Subject: Re: Real deadlock being suppressed in sbitmap Message-ID: <20190114225017.336c2347@vmware.local.home> In-Reply-To: <20190115032355.GE10121@ming.t460p> References: <20190114121414.450ab4ea@gandalf.local.home> <20190115032355.GE10121@ming.t460p> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Jan 2019 11:23:56 +0800 Ming Lei wrote: > Given 'swap_lock' can be acquired from blk_mq_dispatch_rq_list() via > blk_mq_get_driver_tag() directly, the above deadlock may be possible. > > Sounds the correct fix may be the following one, and the irqsave cost > should be fine given sbitmap_deferred_clear is only triggered when one > word is run out of. Since the lockdep splat only showed SOFTIRQ issues, I figured I would only protect it from that. Linus already accepted my patch, can you run tests on that kernel with LOCKDEP enabled and see if it will trigger with IRQ issues, then we can most definitely upgrade that to spin_lock_irqsave(). But I was trying to keep the overhead down, as that's a bit more heavy weight than a spin_lock_bh(). -- Steve