From owner-freebsd-current@freebsd.org Mon Jan 9 21:59:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2925FCA8F0F for ; Mon, 9 Jan 2017 21:59:00 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0E2218CF for ; Mon, 9 Jan 2017 21:58:59 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-573ff700000009b9-a1-5874066a30ec Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 05.43.02489.A6604785; Mon, 9 Jan 2017 16:53:48 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v09LrkNL011149; Mon, 9 Jan 2017 16:53:46 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v09Lrgqc028381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Jan 2017 16:53:45 -0500 Date: Mon, 9 Jan 2017 15:53:42 -0600 From: Benjamin Kaduk To: Anindya Mukherjee Cc: "freebsd-current@freebsd.org" Subject: Re: New Lock Order Reversal in 12.0? Message-ID: <20170109215342.GI8460@kduck.kaduk.org> References: <20170109004717.GE8460@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nopvDVhJh8Okuk8Wn9fPYLOa8+cDk wOQx49N8Fo/HPWfYApiiuGxSUnMyy1KL9O0SuDIeLtvBUnCJq6J31nKWBsbtHF2MnBwSAiYS bzY8Zu5i5OIQEmhjkth96RcbhLOBUWLi63fsEM4VJom1vxeygrSwCKhIdK3azwZiswHZDd2X mUFsEQFdiS+PN7GD2MwC9hJtd7YzgtjCQPFrH1YA2RwcvALGEgu2ZkDMvMko0Xp2LthMXgFB iZMzn7BA9GpJ3Pj3kgmknllAWmL5P7BLOQViJQ4v/84EYosKKEs0zHjAPIFRYBaS7llIumch dC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRHKYuqjsY5/z1OsQowMGo xMMbMaE4Qog1say4MvcQoyQHk5Ior8EuoBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXlfGkggh 3pTEyqrUonyYlDQHi5I476VM9wghgfTEktTs1NSC1CKYrAwHh5IEbxcrUKNgUWp6akVaZk4J QpqJgxNkOA/Q8FAWkOHFBYm5xZnpEPlTjIpS4rxtIM0CIImM0jy4XlAakcjeX/OKURzoFWFe S5AqHmAKgut+BTSYCWhwpF0xyOCSRISUVANjeZ5tZGvErAlfpRd63dJ+Xv9Bs8zv4vpU7dOr e+8cZrKSWKOz6YSlmPb6FzIWuju5z/V4Pdm/X6/p+M33Z5ZVcd/+s+r0lS+57vLXl5k6n5J2 ef5YRi5ZdIFfwaubb4NsTCsP1uowxq6N7zH6I1pjYl/I+uDKq4vHij22zZN4cb57lvKKTUcs lFiKMxINtZiLihMBFBzG8/4CAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:59:00 -0000 On Mon, Jan 09, 2017 at 02:31:39AM +0000, Anindya Mukherjee wrote: > Hi Ben, > > Thanks for your reply, and yes, I did notice #238. I should say at this point that I'm a newbie when it comes to kernel code and am trying to learn about it (hence current). Understood. It's good that you are ready to try! > The entry you refer to does look a bit like the one I've got, but I'm not totally sure if the same code path is being followed to arrive at this LOR. An inode is being created in my case, vs a directory creation (entry + inode probably) in #238, and then a sync is being attempted, which causes locks to activate in the softdep code. I've read a bit about this from McCusick's book but the details are still fuzzy. > > Perhaps you are trying to tell me that it's benign? I know that WITNESS has false positives, an example being #236 where due to shared vs exclusive vnode locks required on the two ways to lock bufwait and dirhash a deadlock never happens. Well, it's hard to say for certain, but there are a few ufs/bufwait/ufs LORs that are very commonly reported as WITNESS output but have never (IIRC) been identified as causing a deadlock. So, it seems pretty likely that this one is similarly benign -- I, for one, do not plan to put in time trying to analyze it until there is a hang or deadlock associated with it. -Ben