[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f712a5551ebd4626acd17ac80fe51879@AcuMS.aculab.com>
Date: Fri, 23 Jun 2023 13:10:26 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Matthew Wilcox' <willy@...radead.org>, stsp <stsp2@...dex.ru>
CC: Jeff Layton <jlayton@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: RE: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK
From: Matthew Wilcox
> Sent: 20 June 2023 14:46
>
> On Tue, Jun 20, 2023 at 06:39:07PM +0500, stsp wrote:
> > Though it will, for sure, represent the
> > task that _owns_ the lock.
>
> No, it *DOESN'T*. I can open a file, SCM_RIGHTS pass it to another task
> and then exit. Now the only owner of that lock is the recipient ...
> who may not even have received the fd yet.
Do these locks persist across fork+exec?
What happens is a completely unrelated process opens /proc/<pid>/fd
while a lock is held and then the (nominally) lock-holding
process closes the fd (or exits).
While it might be a useful diagnostic to know the pid of the
process that acquired the lock it clearly has no relationship
with any process that currently has an fd[] table entry that
references the file.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists