From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fieldses.org ([173.255.197.46]:49490 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726882AbeHJDXv (ORCPT ); Thu, 9 Aug 2018 23:23:51 -0400 Date: Thu, 9 Aug 2018 20:56:26 -0400 From: "J. Bruce Fields" To: NeilBrown Cc: Jeff Layton , Alexander Viro , Martin Wilck , linux-fsdevel@vger.kernel.org, Frank Filz , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/5] fs/locks: change all *_conflict() functions to return a new enum. Message-ID: <20180810005626.GC3915@fieldses.org> References: <153378012255.1220.6754153662007899557.stgit@noble> <153378028114.1220.3708291796442871726.stgit@noble> <20180809130959.GH23873@fieldses.org> <87d0urrtvw.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d0urrtvw.fsf@notabene.neil.brown.name> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Aug 10, 2018 at 09:40:35AM +1000, NeilBrown wrote: > caller_fl is first and sys_fl is second. > > if sys_fl, the second, is a read lock, and caller_fl, the first, is a > write lock, they clearly conflict but any other lock that conflict > with caller_fl (The write lock) would *not* necessarily conflict with > the read lock. So this situation is *not* FL_TRANSITIVE_CONFLICT. > > locks_conflict() only returns FL_TRANSITIVE_CONFLICT when sys_fl (the > second) is a write lock, which it isn't in this case. So I think that > this case is handled correctly. > posix_locks_conflict() will return FL_CONFLICT, but not > FL_TRANSITIVE_CONFLICT. > > Have I convinced you, or have I missed your point? Eh, I was just confused. And now I'm tempted to blame you for confusing me, but maybe that's just my ego going defensive. (My bruised ego suggests leaving locks_conflict and its callers alone, and having an entirely separate function that checks this when we need it.) --b.