[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ddb48e05-ab26-ae5d-86d5-01e47f0f0cd2@yandex.ru>
Date: Tue, 20 Jun 2023 18:39:07 +0500
From: stsp <stsp2@...dex.ru>
To: Jeff Layton <jlayton@...nel.org>, linux-kernel@...r.kernel.org
Cc: Chuck Lever <chuck.lever@...cle.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK
20.06.2023 18:19, Jeff Layton пишет:
> The bottom line is that these locks are specifically not owned by a
> process, so returning the l_pid field is unreliable (at best). There is
> no guarantee that the pid returned will still represent the task that
> set the lock.
Though it will, for sure, represent the
task that _owns_ the lock.
> You may want to review this article. They're called "File-private" locks
> here, but the name was later changed to "Open file description" (OFD)
> locks:
>
> https://lwn.net/Articles/586904/
>
> The rationale for why -1 is reported is noted there.
Well, they point to fork() and SCM_RIGHTS.
Yes, these 2 beasts can make the same lock
owned by more than one process.
Yet l_pid returned, is going to be always valid:
it will still represent one of the valid owners.
So my call is to be brave and just re-consider
the conclusion of that article, made 10 years
ago! :)
Of course if returning just 1 of possibly multiple
owners is a problem, then oh well, I'll drop
this patch.
Powered by blists - more mailing lists