Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754070AbdFSMxJ (ORCPT ); Mon, 19 Jun 2017 08:53:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47110 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753591AbdFSMxI (ORCPT ); Mon, 19 Jun 2017 08:53:08 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1915581250 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bcodding@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1915581250 From: "Benjamin Coddington" To: "Jeff Layton" Cc: bfields@fieldses.org, "Alexander Viro" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks Date: Mon, 19 Jun 2017 08:53:06 -0400 Message-ID: <4D612272-7D47-4895-8293-9E7DB4B718B0@redhat.com> In-Reply-To: <1F8A7C37-E1A9-4C15-B3D9-7B8299744B26@redhat.com> References: <1496835607.3703.1.camel@poochiereds.net> <1F8A7C37-E1A9-4C15-B3D9-7B8299744B26@redhat.com> MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 19 Jun 2017 12:53:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1239 Lines: 31 On 19 Jun 2017, at 8:37, Benjamin Coddington wrote: > Apologies for the delayed response.. > > On 7 Jun 2017, at 7:40, Jeff Layton wrote: > >> On Tue, 2017-06-06 at 16:45 -0400, Benjamin Coddington wrote: >>> Now that we're translating fl_pid for F_GETLK and /proc/locks, we need to >>> handle the case where a remote filesystem directly sets fl_pid. In that >>> case, the fl_pid should not be translated into a local pid namespace. If >>> the filesystem implements the lock operation, set a flag to return the >>> lock's fl_pid value directly, rather translate it. >>> >> >> Actually, you're not translating anything for F_GETLK until we get to >> this patch. Patch #2 in this series removes the fl_nspid field, but the >> pid translation isn't fixed until here. That does mean a nominal >> regression here in how fl_pid is reported between the two. > > Good catch. > >> Would it be best to squash #2 and #3 together? Or maybe just go ahead >> and universally translate the fl_pid field until you add the flag in >> this patch? > > I'll send a v4 that universally translates the fl_pid field until this > patch. I think the first two patches should be separate. Ah, but /2 and 3/ should just be squashed, yes I agree with that. Ben