On Wed, Oct 21, 2009 at 3:16 PM, Corentin Chary <corentin.chary@xxxxxxxxx> wrote: > First, some background: > - getpid() returns current->tgid which is the pid of the first thread > - gettid() returns current->pid which is the pid of the current thread > For all threads, getpid() is the same. > > From fuse.h : >> For F_SETLK and F_SETLKW the l_pid field will be set to the pid >> of the process performing the locking operation. > Short: l_pid will always be equal to tgid > >> struct fuse_context >> /** Thread ID of the calling process */ >> pid_t pid; > Short: ctx->pid will always be thread id (current->pid / gettid()) > > posix_locks use this pid in same_owner(), but pl_forget will be called > with the pid (current->pid) from the thread who did the close. Locks > granted to other threads, won't be deleted. > > This can also affect some other translators. > > GlusterFS don't want the Thread ID (current->pid), it needs the Process ID > (current->tgid), at least for > > A quick hack to make it work with thread would be to getpgid(ctx->pid), > but this won't work in a lot of case (for example, daemonized process). > > You may also want to use the l_pid field in struct flock, but this > won't work because you don't know who will close > the fd and call pl_flush. > > Another way is to add a syscall to get the tgid from the pid, but I > don't think this will happens. > > The easiest way is to add a tgid field in fuse in order to use > ctx->tgid instead of ctx->pid. > > Finally, a quick&dirty fix can be made reading /proc/<ctx->pid>/status > in order to find the Tgid: line. > > -- > Corentin Chary > http://xf.iksaif.net > Reading the fuse source, I found the solution: fuse_file_info->lock_owner should be used to check ownership instead of pid. This way the pid/tgid thing is no more an issue. Patch comming tomorow =) -- Corentin Chary http://xf.iksaif.net
