Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1669035 > unrolled thread

Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks "Benjamin Coddington" <bcodding@redhat.com> - 2017-06-19 14:40 +0200
    Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks "Benjamin Coddington" <bcodding@redhat.com> - 2017-06-19 15:00 +0200

#1669035 — Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks

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

[toc] | [next] | [standalone]

#1669043

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web