[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7fd8146f9c758a8e16faeb371ca04a701e1a7b8.camel@kernel.org>
Date: Wed, 21 Jun 2023 07:05:12 -0400
From: Jeff Layton <jlayton@...nel.org>
To: stsp <stsp2@...dex.ru>, 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, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK
On Wed, 2023-06-21 at 15:42 +0500, stsp wrote:
> 21.06.2023 15:35, Jeff Layton пишет:
> > I don't think we can change this at this point.
> >
> > The bottom line (again) is that OFD locks are owned by the file
> > descriptor (much like with flock()), and since file descriptors can be
> > shared across multiple process it's impossible to say that some single
> > process owns it.
> What's the problem with 2 owners?
> Can't you get one of them, rather than
> meaningless -1?
> Compare this situation with read locks.
> They can overlap, so when you get an
> info about a read lock (except for the
> new F_UNLCK case), you get the info
> about *some* of the locks in that range.
> In the case of multiple owners, you
> likewise get the info about about some
> owner. If you iteratively send them a
> "please release this lock" message
> (eg in a form of SIGKILL), then you
> traverse all, and end up with the
> lock-free area.
> Is there really any problem here?
Yes. Ambiguous answers are worse than none at all.
What problem are you trying to solve by having F_OFD_GETLK report a pid?
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists