On Tue, 2023-06-20 at 16:45 +0500, stsp wrote: > 20.06.2023 16:12, Jeff Layton пишет: > > Multithreaded processes are also a bit of a gray area here: Suppose I > > open a file and set an OFD lock on it in one task, and then let that > > task exit while the file is still open. What should l_pid say in that > > case? > > If by the "task" you mean a process, then > the result should be no lock at all. > If you mean the thread exit, then I would > expect l_pid to contain tgid, in which case > it will still point to the valid pid. > Or do you mean l_pid contains tid? > Checking... no, l_pid contains tgid. > So I don't really see the problem you are > pointing with the above example, could > you please clarify? > 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). Now, join the thread so that task 101 exits. Wait a while, and eventually pid 101 will be recycled, so that now there is a new task 101 that is unrelated to the process above. Another (unrelated) task then calls F_GETLK on the file and sees that lock. Its pid is now set to 101 and sends SIGKILL to it, killing an unrelated process. 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. -- Jeff Layton <jlayton@xxxxxxxxxx>
