On Tue, 2015-01-20 at 01:37 +0100, Samuel Thibault wrote: > Hello, > > Thanks for reviving this, it'll definitely be useful! > > Svante Signell, le Thu 08 Jan 2015 12:28:05 +0100, a écrit : > > 1) l_pid of struct flock is not set. According to the manpage (and > > posix) the PID of the process blocking the lock should be reported. Can > > maybe be solved by a shared memory solution in glibc or as indicated in > > task 1022. > > We can not trust a shared memory solution, we need an io_reidentify > round through the proc server.
Can you give more information about how to implement this? > > 2) fork(2) does not create a process without the locks set for the > > child. > > > (This is probably the main cause tdbtorture in tdb does not work well > > with the current file record locking patches.) > > I don't think tdbtorture forks with locks held: AIUI it just starts > several processes and let them play at will with locks, without creating > or terminating them. Looking at the code of tdbtorture.c it forks a lot of processes (and assumes the locks are not kept) while the current implementation does not release them. With num_procs=1 tdbtorture works fine. Is the correct solution to add a hook in fork.c code to release these locks?
