On Sat, 2020-10-10 at 12:46 +0800, 张游(游游) wrote: > Hello, recently, we are implementing the flock interface in our own file system, but we have some doubts about the implementation of flock in the kernel, so I would like to ask you whether the kernel does this and why? > > (1) Locks created by flock() are associated with an open file table entry. Two processes are generated by fork，parent process A and child process B share the same file descriptor and open file table entry. If A and B use file descriptor to lock, we find that both processes will succeed. > If only one process (assumed to be process A) is successfully unlocked, the corresponding lock record in inode will be deleted. This will result in another unrelated process (marked C) locking the inode successfully. At this time, there will be two processes (B and C) to obtain the lock. Two unrelated processes will operate on the same file, which will lead to conflicts. What is the purpose of the kernel? This phenomenon also occurs in the two file descriptor produced by dup(or dup2). > (2) Similarly, parent process A and child process B share the same open file table entry. Process A locks successfully. If process B fails to lock, the lock records in inode will be deleted. However, process A thinks that it still holds the lock, and the problem in (1) will occur. > This is all expected behavior since both processes are operating on the same file description. flock (and OFD) locks only provide exclusion between different file descriptions. You either need to give each process it's own file description (usually, via multiple open() calls), or use legacy POSIX locking which should work more like you seem to expect with processes (but not threads!). -- Jeff Layton <jlayton@xxxxxxxxxx>
