On Fri, 2023-06-23 at 22:18 +0500, stsp wrote: > 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. Beyond all of this, there is a long history of problems with the l_pid field as well with network filesystems, even with traditional POSIX locks. What should go into the l_pid when a traditional POSIX lock is held by a process on a separate host? While POSIX mandates it, the l_pid is really sort of a "legacy" field that is really just for informational purposes only nowadays. It might have been a reliable bit of information back in the 1980's, but even since the 90's it was suspect as a source of information. Even if you _know_ you hold a traditional POSIX lock, be careful trusting the information in that field. -- Jeff Layton <jlayton@xxxxxxxxxx>
