Re: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK

[stsp]

23.06.2023 20:25, Christian Brauner пишет:
> On Wed, Jun 21, 2023 at 07:05:12AM -0400, Jeff Layton wrote:
> > 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.
> I agree.
>
> A few minor observations:
>
> SCM_RIGHTS have already been mentioned multiple times. But I'm not sure
> it's been mentioned explicitly but that trivially means it's possible to
> send an fd to a completely separate thread-group, then kill off the
> sending thread-group by killing their thread-group leader. Bad enough as
> the identifier is now useless. But it also means that at some later
> point that pid can be recycled.
Come on.
I never proposed anything like this.
Of course the returned pid should be
the pid of the current, actual owner,
or one of current owners.
If someone else proposed to return
stalled pids, then it wasn't me.