Re: [fuse-devel] Threads and locks: tgid vs pid

[Corentin C. <cor...@gm...>]

On Wed, Oct 21, 2009 at 3:16 PM, Corentin Chary
<cor...@gm...> 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