20.06.2023 18:19, Jeff Layton пишет:
The bottom line is that these locks are specifically not owned by a
process, so returning the l_pid field is unreliable (at best). There is
no guarantee that the pid returned will still represent the task that
set the lock.
Though it will, for sure, represent the
task that _owns_ the lock.
You may want to review this article. They're called "File-private" locks
here, but the name was later changed to "Open file description" (OFD)
locks:
https://lwn.net/Articles/586904/
The rationale for why -1 is reported is noted there.
Well, they point to fork() and SCM_RIGHTS.
Yes, these 2 beasts can make the same lock
owned by more than one process.
Yet l_pid returned, is going to be always valid:
it will still represent one of the valid owners.
So my call is to be brave and just re-consider
the conclusion of that article, made 10 years
ago! :)
Of course if returning just 1 of possibly multiple
owners is a problem, then oh well, I'll drop
this patch.
