linux-kernel - Re: [PATCH 2/2] fs/locks: Remove fl_nspid and 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9AA05B58-8D17-4A03-88F8-0F44F346AE0F@redhat.com>
Date:   Tue, 20 Jun 2017 15:17:34 -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-nfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        "open list" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] fs/locks: Remove fl_nspid and use fs-specific l_pid
 for remote locks

On 20 Jun 2017, at 13:06, Jeff Layton wrote:
>
> Now that I think about it a bit more, I don't think we really need a
> flag here.
>
> Just have the ->lock operation set the fl_pid to a negative value. That
> will never be a valid pid anyway. Then flock_translate_pid could just
> return any negative value directly instead of trying to translate it.
>
> In practice we would always just set it to -1. Maybe even add something
> like this that the lock-> operation could set it to?
>
> #define    FILE_LOCK_OWNER_UNDEFINED       -1

So for filesystems that set a remote pid, they should negate the pid to mean
that the pid should not be translated?  Then when we return that pid, we
flip it back again, or display a negative number, or turn it into -1?

The flag, having a readable name, would make things a bit clearer as to what
the filesystems expect to happen to that pid value.

Ben