On Tue, 2023-06-20 at 17:34 +0500, stsp wrote:
> 20.06.2023 17:02, Jeff Layton пишет:
> > Suppose I start a process (call it pid 100), and then spawn a thread
> > (101). I then have 101 open a file and set an OFD lock on it (such that
> > the resulting fl_pid field in the file_lock is set to 101).
>
> How come?
> There are multiple places in locks.c
> with this line:
> fl->fl_pid = current->tgid;
>
> And I've yet to see the line like:
> fl->fl_pid = current->pid;
> Its simply not there.
>
> No, we put tgid into l_pid!
> tgid will still be 100, no matter how
> many threads you spawn or destroy.
> Or what am I misseng?
>
>
> > That's just one example, of course. The underlying problem is that OFD
> > locks are not owned by processes in the same way that traditional POSIX
> > locks are, so reporting a pid there is unreliable, at best.
> But we report tgid.
> It doesn't depend on threads.
> I don't understand. :)
Good point. I had forgotten that we stuffed the l_pid in there. So in
principle, that example would be OK. But...there is still the problem of
passing file descriptors via unix sockets.
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.
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.
--
Jeff Layton <jlayton@xxxxxxxxxx>
