Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753818AbdHQXXs (ORCPT ); Thu, 17 Aug 2017 19:23:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:55950 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752872AbdHQXXr (ORCPT ); Thu, 17 Aug 2017 19:23:47 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 742CB21482 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Thu, 17 Aug 2017 19:23:43 -0400 From: Steven Rostedt To: Waiman Long Cc: Jens Axboe , Jeff Layton , "J. Bruce Fields" , Ingo Molnar , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops Message-ID: <20170817192343.503fac3d@gandalf.local.home> In-Reply-To: <20170817181818.4ef4acf3@gandalf.local.home> References: <1502916040-18067-1-git-send-email-longman@redhat.com> <20170817093444.3276f7ab@gandalf.local.home> <20170817171007.1ab33b8f@gandalf.local.home> <6bb40f9f-7f55-28b4-812b-a80f05bec6ea@redhat.com> <20170817181320.60b02500@gandalf.local.home> <20170817181818.4ef4acf3@gandalf.local.home> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1442 Lines: 35 On Thu, 17 Aug 2017 18:18:18 -0400 Steven Rostedt wrote: > On Thu, 17 Aug 2017 18:13:20 -0400 > Steven Rostedt wrote: > > > On Thu, 17 Aug 2017 17:27:22 -0400 > > Waiman Long wrote: > > > > > > > It is actually what the patch is trying to do by checking for the > > > deletion flag in the mutex_trylock loop. Please note that mutex does not > > > guarantee FIFO ordering of lock acquisition. As a result, cpu1 may call > > > mutex_lock() and wait for it while cpu2 can set the deletion flag later > > > and get the mutex first before cpu1. So checking for the deletion flag > > > before taking the mutex isn't enough. > > > > Yeah, I figured that out already (crossed emails). BTW, how did you > > trigger this warning. I'm playing around with adding loop devices, > > volume groups, and logical volumes, and reading the trace files > > created in the sysfs directory, then removing those items, but it's > > not triggering the "delete" path. What operation deletes the partition? > > I'm guessing that deleting an actual partition may work (unfortunately, > my test box has no partition to delete ;-) I'll find another box to > test on. > OK, deleting a partition doesn't trigger the lockdep splat. But I also added a printk in the BLKPG_DEL_PARTITION case switch, which also doesn't print. What command do I need to do to trigger that path? Thanks, -- Steve