From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Killing POSIX deadlock detection Date: Sun, 06 Jun 2004 15:49:20 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1086551360.5472.48.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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: 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]:32643 "EHLO lade.trondhjem.org") by vger.kernel.org with ESMTP id S264073AbUFFTtY convert rfc822-to-8bit (ORCPT ); Sun, 6 Jun 2004 15:49:24 -0400 To: Matthew Wilcox In-Reply-To: <20040606132751.GZ5850@parcelfarce.linux.theplanet.co.uk> List-Id: linux-fsdevel.vger.kernel.org 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 here = too, > even though T1 is about to unlock file F1. So what is better: report an error and give the user a chance to recover, or allowing the potential deadlock? Only the user can resolve problems such as the above threaded problem, given the SuS definitions. > So, final call. Any objections to never returning -EDEADLCK? Yes: As Chuck points out, that is a fairly nasty change of the userland API. Worse: it is a change that fixes only one problem for only a minority o= f users (those that combine locking over multiple NPTL threads - a situation which after the "fix" remains just as poorly defined) at the expense of reintroducing a series of deadlocking problems for those single threaded users that rely on the EDEADLK (and have done so throughout the entire 2.4.x series). =46inally, EDEADLK does actually appear to be mandatory to implement in SUSv3, given that it states: A potential for deadlock occurs if a process controlling a locked region is put to sleep by attempting to lock another process' locked region. If the system detects that sleeping until a locked region is unlocked would cause a deadlock, fcntl() shall fail with an [EDEADLK] error. =20 (again see http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html) 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