Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2665832imm; Thu, 9 Aug 2018 17:57:54 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzA++oFwW3sU1tUoxdl/6t+ab8VdIkgnqmDDzV/fNPdBOYcqVjMTmv7zTH1QO/S/d5RciLr X-Received: by 2002:a62:8d84:: with SMTP id p4-v6mr4677052pfk.251.1533862674168; Thu, 09 Aug 2018 17:57:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533862674; cv=none; d=google.com; s=arc-20160816; b=DoCBjBbj+faG8iLTQ2yA1W4I5jQtpl+H8whxjnccgkr+oYQNkX34HZRLEYMH4uqV2V aILD4XYg6fYya1rlHtsOkPnI5KC44iJMie42PVeIfK8HU72PKTXAbYeqadif0qlzk3Tq wBCf/wVxQ1Q/GAQZNv5MnU/wuQBBSjdybIHy7QzcK71hOgBAjTtGhNchpqssgiguARnv 7t7VH4CmG+Eq56a/Tk6tZeVxRF+Y0KUuNAQ6R3Md+ODAKzwA+fqROAtZahW4PQgrduE8 cTubc7djA1WqxBXIRVonHxpNjTGRX6L2WFLHf7+v63wa5dKzNO8lkEI0roa83ZUHr15m n6Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=FPJK2IJQ8goOf2AfoEu2pYKISzkSIaT9XXZuJHv4TTI=; b=BzDVEpQOswa2t8ixc1WvvL/Gj5mtKLaQk2M1rWLjQJ5m+Ni7MShU7xuF2dUgHG3UQo AiOz9jkF/66B3OiTa8gDKiHVt9wPfyK1nNamWHfCzDVU5GawUfbEJt0i4WeHYSa+0Jvn bhhzhTPeWX4pYL9HPuBNUzMdwWj/9z5hIZ6H6MfjxJUdlTepJTNt56QJPvV+PwPeZZDz gH/HOWgZHcXqvo108DcenarseAawOywZR2EvYUHl6E3YU3eL+YShJI+PJuWqKkkCA7Na upJrQEsHmnOIWwjArSgl/WjOzexnAWeMyggNLlsd0Ws9TC1OdBu/EdwzY+zThJRTLi0M YWcA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j20-v6si8535828pgb.92.2018.08.09.17.57.39; Thu, 09 Aug 2018 17:57:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727185AbeHJDXv (ORCPT + 99 others); Thu, 9 Aug 2018 23:23:51 -0400 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 Received: by fieldses.org (Postfix, from userid 2815) id 155CA3F4; Thu, 9 Aug 2018 20:56:26 -0400 (EDT) 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> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.