Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1715434

Re: [PATCH v4] blktrace: Fix potentail deadlock between delete & sysfs ops

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From Bart Van Assche <Bart.VanAssche@wdc.com>
Newsgroups linux.kernel
Subject Re: [PATCH v4] blktrace: Fix potentail deadlock between delete & sysfs ops
Date Fri, 18 Aug 2017 22:20:01 +0200
Message-ID <ufVUl-8uR-7@gated-at.bofh.it> (permalink)
References <ufVKG-8rE-19@gated-at.bofh.it>
X-Original-To "mingo@kernel.org" <mingo@kernel.org>, "longman@redhat.com" <longman@redhat.com>, "rostedt@goodmis.org" <rostedt@goodmis.org>, "axboe@kernel.dk" <axboe@kernel.dk>
X-Ironport-Av E=Sophos;i="5.41,393,1498492800"; d="scan'208";a="139893000"
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharedspace.onmicrosoft.com; s=selector1-wdc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sG/lFmYIML4ARw883pUdU82j4u4VI7vf294AbTHKEIU=; b=MzCq8JZN36zJfqsqsJTZW5SPcEkE/t/3dj81VsPb0YYgdm/bCNkNOnHwMFUw1Hq2VhvhTsB0u7pvmZTTXckrd8XzTmT/2ZzbUm5GEO2fe0NkNUdeE2uiA6lGmhbUW0uMQ+7KIJrKqUqyy/HCWHV03WX1Tfk8sdKzdySJK65kuFc=
Thread-Topic [PATCH v4] blktrace: Fix potentail deadlock between delete & sysfs ops
Thread-Index AQHTGFzHomVm/w0FJUW3QWQDXLjARqKKjYEA
Accept-Language en-US
Content-Language en-US
Authentication-Results spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@wdc.com;
X-Originating-IP [63.163.107.100]
X-Ms-Publictraffictype Email
X-Microsoft-Exchange-Diagnostics 1;CY1PR0401MB0908;20:g8NwVGjHG1Ma8UfBuKptfCa6/Hjpbtlb6p7QNAc0UTr001xVImnXVeJsXOGa5Own5QTDPn11wX+lcTtAGSQ+8auSuiSse0KD4Asf45eN7AN0No/iyd/eMrGatZBqIV35Mc6ZmzPD0zy/+NoW4ojWKdI0ek2rPn5HD+mJH0kb/v8=
X-Ms-Exchange-Antispam-Srfa-Diagnostics SSOS;
X-Ms-Office365-Filtering-Correlation-ID 973a6e7b-e047-48e0-1eb0-08d4e6764114
X-Ms-Office365-Filtering-Ht Tenant
X-Microsoft-Antispam UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1PR0401MB0908;
X-Ms-Traffictypediagnostic CY1PR0401MB0908:
Wdcipoutbound EOP-TRUE
X-Exchange-Antispam-Report-Test UriScan:;
X-Microsoft-Antispam-Prvs <CY1PR0401MB0908A423381F6FCBAEF61CEE98800@CY1PR0401MB0908.namprd04.prod.outlook.com>
X-Exchange-Antispam-Report-Cfa-Test BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0401MB0908;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0401MB0908;
X-Forefront-Prvs 040359335D
X-Forefront-Antispam-Report SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(377424004)(199003)(189002)(24454002)(36756003)(102836003)(6116002)(86362001)(97736004)(2950100002)(2501003)(77096006)(4326008)(6486002)(229853002)(2201001)(478600001)(8936002)(3846002)(2906002)(103116003)(189998001)(25786009)(101416001)(66066001)(7736002)(305945005)(14454004)(3280700002)(33646002)(6436002)(6506006)(53936002)(76176999)(72206003)(8676002)(3660700001)(5660300001)(106356001)(68736007)(54906002)(81166006)(81156014)(50986999)(99286003)(105586002)(2900100001)(6512007)(54356999)(6246003);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB0908;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
Received-Spf None (protection.outlook.com: wdc.com does not designate permitted sender hosts)
Spamdiagnosticoutput 1:99
Spamdiagnosticmetadata NSPM
Content-Type text/plain; charset="utf-8"
Content-ID <A5BC9BDF3ABAF2458C365EEE89896840@namprd04.prod.outlook.com>
Content-Transfer-Encoding base64
MIME-Version 1.0
X-Originatororg wdc.com
X-Ms-Exchange-Crosstenant-Originalarrivaltime 18 Aug 2017 20:18:13.7199 (UTC)
X-Ms-Exchange-Crosstenant-Fromentityheader Hosted
X-Ms-Exchange-Crosstenant-ID b61c8803-16f3-4c35-9b17-6f65f441df86
X-Ms-Exchange-Transport-Crosstenantheadersstamped CY1PR0401MB0908
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 25
Organization linux.* mail to news gateway
X-Original-Cc "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
X-Original-Date Fri, 18 Aug 2017 20:18:13 +0000
X-Original-Message-ID <1503087492.2622.13.camel@wdc.com>
X-Original-References <1503086474-20187-1-git-send-email-longman@redhat.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1715434

Show key headers only | View raw


On Fri, 2017-08-18 at 16:01 -0400, Waiman Long wrote:
> [ ... ]
> Instead of using bd_mutex, a new global blktrace mutex is now used
> to protect against concurrent access, creation and destruction of the
> blk_trace structure that is used only in the blktrace.c file. As
> blktrace files will not be frequently accessed, using a global mutex
> should not cause any performance problem.
> [ ... ]
> +/*
> + * The bd_mutex was used previously for protecting blk_trace structure.
> + * That could lead to deadlock with concurrent block device deletion and
> + * sysfs access. So a global blktrace_mutex is now used instead for
> + * protecting the blk_trace structure.
> + *
> + * The references to the opened sysfs or device files should prevent the
> + * underlying block device from being removed.
> + */
> +static DEFINE_MUTEX(blktrace_mutex);

Hello Waiman,

Thanks for having addressed my previous comment. Regarding this patch: sorry
but I don't think it's a good idea to use a global mutex for serializing
accesses to tracing data of a single block device. Global mutexes create
unwanted lock dependencies between different block devices. Additionally, on
multiprocessor systems global mutexes can cause cache line ping-pong between
processors and hence can cause a severe slowdown. Please make blktrace_mutex
per block device instead of global.

Thanks,

Bart.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v4] blktrace: Fix potentail deadlock between delete & sysfs ops Waiman Long <longman@redhat.com> - 2017-08-18 22:10 +0200
  Re: [PATCH v4] blktrace: Fix potentail deadlock between delete &  sysfs ops Bart Van Assche <Bart.VanAssche@wdc.com> - 2017-08-18 22:20 +0200
    Re: [PATCH v4] blktrace: Fix potentail deadlock between delete &  sysfs ops Waiman Long <longman@redhat.com> - 2017-08-18 22:40 +0200

csiph-web