On Tue, 2023-06-20 at 18:39 +0500, stsp wrote: > 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. No, it won't. The l_pid field is populated from the file_lock->fl_pid. That field is set when the lock is set, and never updated. So it's quite possible for F_GETLK to return the pid of a process that no longer exists. In principle, we could try to address that by changing how we track lock ownership, but that's a fairly major overhaul, and I'm not clear on any use-cases where that matters. > So my call is to be brave and just re-consider > the conclusion of that article, made 10 years > ago! :) > I think my foot has too many bullet wounds for that sort of bravery. > Of course if returning just 1 of possibly multiple > owners is a problem, then oh well, I'll drop > this patch. -- Jeff Layton <jlayton@xxxxxxxxxx>
