27.06.2023 21:00, Jeff Layton пишет:
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.
Thanks for info. Additional problem with multiple owners that I can think of, is that you don't know if more owners are present. And even if you use SIGKILL to "iterate", you still don't know if you got another owner of the prev lock, or maybe you got entirely different read lock with the same range from another owner. Still if you do "man fcntl" you'll see this: pid_t l_pid; /* PID of process blocking our lock (set by F_GETLK and F_OFD_GETLK) */ And no, its not my patch that did this. :) So unless properly documented, this would be treated as a bug. And it should _not_ be documented as "OFD locks has no owner by definition" or alike - no one buys that.
