From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752060AbcGFApu (ORCPT ); Tue, 5 Jul 2016 20:45:50 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:36057 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111AbcGFApt (ORCPT ); Tue, 5 Jul 2016 20:45:49 -0400 Date: Wed, 6 Jul 2016 08:49:43 +0800 From: Boqun Feng To: Byungchul Park Cc: Peter Zijlstra , mingo@kernel.org, linux-kernel@vger.kernel.org, walken@google.com Subject: Re: [PATCH] lockdep: Add a document describing crossrelease feature Message-ID: <20160706004943.GA20366@insomnia> References: <1466398527-1122-1-git-send-email-byungchul.park@lge.com> <1467346538-1579-1-git-send-email-byungchul.park@lge.com> <20160701104521.GG30154@twins.programming.kicks-ass.net> <20160704064259.GX2279@X58A-UD3R> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20160704064259.GX2279@X58A-UD3R> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 04, 2016 at 03:42:59PM +0900, Byungchul Park wrote: [snip] > > > +2. A lock has dependency with all locks in the releasing context, ha= ving > > > + been held since the lock was held. > >=20 > > But you cannot tell this. The 'since the lock was held' thing fully > > depends on timing and is not fundamentally correct. > >=20 > > lock(A) > > unlock(A) > > lock(A) > > wait_for(B) > > unlock(A) > > wake(B) > >=20 > > Between the wait_for(B) and wake(B), _nothing_ has been held, yet still > > there's the deadlock potential. >=20 > Crossreleas feature can detect this situation as a deadlock. wait_for() > is not an actual lock, but we can make it detectable by using acquring and > releasing semantics on wait_for() and wake(). >=20 > > And note that if the timing was 'right', you would never get to wake(B) > > because deadlock, so you'd never establish that there would be a > > deadlock. >=20 > If a deadlock actually happens, then we cannot establish it as you said. > Remind that current lockdep does nothing for this situation. But at least > crossrelease feature can detect this deadlock possibility at the time the > dependency tree(graph) is built, which is better than doing nothing. >=20 Confused, how? Say the sequence of events is as follow: (two tasks are initially with no lock held) Task 1 Task 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D lock(A) unlock(A) lock(A) wait_for(B) // acquire wake(B) // commit + release unlock(A) by the time, the commit are called, the dependency tree will be built, and we will find there is _no_ lock held before wake(B). Therefore at the release stage, you will end up only adding dependency chain A->B in the lockdep, right? And it looks like neither Task1 or Task2 will break the dependency chain A->B. So how can crossrelease detect the potential deadlock? It will be better, that you could provide some samples that crossrelease can detect after your confirmation. Regards, Boqun --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXfFWiAAoJEEl56MO1B/q49SAH+QEKv/NxiMDUBHVgJBKfy0T2 1zMsai80eNFmSCV4PkdyFOTxYhSu54PLRbbLJFTwQOJzU3BIdx82VPA9m1H+FK1k az2fUTIxbmqGbmKUFOGomL6iJ7hCjtzW9WhvBHAQ8sl0v9Mdim3+qu0EDi3OjN5E 1D5PTyRFdhdf99XTFyCOaAe3uJ9Uy057nCsEhkRhR2nxNVOgU4qYXAsgk/bWMHvM haDm0XqNh+MUO9e3V8Iy9nJCimpyjrq6JJV7D3tUEjlGU9gJmHZZRMOG1hBvHYy9 qzrWfCx4JHtjXZf0uZ3NgCXTKSsAjiwYbAyqEm2GkfrAp60IFiKdTQeE2jCfCuA= =LZev -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7--