Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754072AbdFSMiC (ORCPT ); Mon, 19 Jun 2017 08:38:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57382 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753942AbdFSMiB (ORCPT ); Mon, 19 Jun 2017 08:38:01 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C80942564 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bcodding@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C80942564 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:37:53 -0400 Message-ID: <1F8A7C37-E1A9-4C15-B3D9-7B8299744B26@redhat.com> In-Reply-To: <1496835607.3703.1.camel@poochiereds.net> References: <1496835607.3703.1.camel@poochiereds.net> MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 19 Jun 2017 12:37:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1930 Lines: 61 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. > Also to make sure I understand: task->tgid will always represent the > task's pid in the init_pid_ns, right? Yes. (I was incorrect on IRC last week), as is seen in kernel/fork.c: 1748 if (pid != &init_struct_pid) { 1749 pid = alloc_pid(p->nsproxy->pid_ns_for_children); ... 1754 } ... 1785 p->pid = pid_nr(pid); 1786 if (clone_flags & CLONE_THREAD) { ... 1789 p->tgid = current->tgid; 1790 } else { ... 1796 p->tgid = p->pid; 1797 } .. and include/linux/pid.h: 153 /* 154 * the helpers to get the pid's id seen from different namespaces ... 156 * pid_nr() : global id, i.e. the id seen from the init namespace; ... 162 */ 163 164 static inline pid_t pid_nr(struct pid *pid) 165 { 166 pid_t nr = 0; 167 if (pid) 168 nr = pid->numbers[0].nr; 169 return nr; 170 } Ben