On Wed, 2023-06-21 at 11:57 +0500, stsp wrote: > 20.06.2023 18:58, Jeff Layton пишет: > > 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. > > OK, in this case I'll just put a comments > into the code, summarizing the info I got > from you and Matthew. > Thanks guys for all the info, its very helpful. > > Now I only need to convert the current > "fundamental problem" attitude into a "not > implemented yet" via the code comment. > > > > > 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. > I am perfectly fine with leaving this thing > unimplemented. But what really bothers > me is the posix proposal, which I think was > done. Please tell me it allows fixing fl_pid > in the future (rather than to mandate -1), > and I am calm. 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. -- Jeff Layton <jlayton@xxxxxxxxxx>
