linux-kernel - Re: [PATCH 3/3] fs/locks: Use fs-specific l

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D612272-7D47-4895-8293-9E7DB4B718B0@redhat.com>
Date:   Mon, 19 Jun 2017 08:53:06 -0400
From:   "Benjamin Coddington" <bcodding@...hat.com>
To:     "Jeff Layton" <jlayton@...chiereds.net>
Cc:     bfields@...ldses.org, "Alexander Viro" <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [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.

Ben