From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Killing POSIX deadlock detection Date: Sun, 06 Jun 2004 16:52:27 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1086555145.7635.22.camel@lade.trondhjem.org> References: <200406050725.i557P3hQ004052@supreme.pcug.org.au> <20040606130422.0c8946b3.sfr@canb.auug.org.au> <20040606132751.GZ5850@parcelfarce.linux.theplanet.co.uk> <1086551360.5472.48.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Matthew Wilcox , Stephen Rothwell , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from dh132.citi.umich.edu ([141.211.133.132]:51587 "EHLO lade.trondhjem.org") by vger.kernel.org with ESMTP id S264134AbUFFUwf convert rfc822-to-8bit (ORCPT ); Sun, 6 Jun 2004 16:52:35 -0400 To: "Eric W. Biederman" In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org P=E5 su , 06/06/2004 klokka 16:09, skreiv Eric W. Biederman: > Trond Myklebust writes: >=20 > > P=E5 su , 06/06/2004 klokka 09:27, skreiv Matthew Wilcox: > > \ > > > > T1 locks file F1 -> lock (P1, F1) > > > > P2 locks file F2 -> lock (P2, F2) > > > > P2 locks file F1 -> blocks against (P1, F1) > > > > T1 locks file F2 -> blocks against (P2, F2) > > >=20 > > > Less contrived example -- T2 locks file F2. We report deadlock h= ere too, > > > even though T1 is about to unlock file F1. >=20 > There is a fairly sane linux specific definition here. We should > track these things not by pid or tid, but by struct files_struct. RTFC... Look carefully in fs/locks.c at stuff like posix_same_owner(). We currently use both the tgid and the struct files_struct (although there are a few notable bugs where we only check the one or the other)... That is, however, a definition which breaks the SUS standards, and it therefore ends up introducing pathologies such as the steal_locks crap. struct files_struct is NOT a sane basis for tracking locks. > > Yes: As Chuck points out, that is a fairly nasty change of the user= land > > API. >=20 > ???? Failing to detect a deadlock is not a change in the API. > It is simply a change in behavior. It is a change in functionality from one where potential deadlocks are detected and reported as errors to one where deadlocks are suddenly possible. Are you saying that functionality is not a part of the API? > Perhaps what we should do is simply not attempt to detect deadlocks > involving threaded processes. So how do you define (and detect) a threaded process? Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html