[lkml]   [2017]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks
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.


 \ /
  Last update: 2017-06-19 14:54    [W:0.041 / U:9.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site