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

[Corentin Chary]

On Wed, Oct 21, 2009 at 7:11 PM, Corentin Chary
<corentin.chary at gmail.com> wrote:
> On Wed, Oct 21, 2009 at 3:16 PM, Corentin Chary
> <corentin.chary at gmail.com> 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 =)

Reading more glusterfs code lead me to this conclusion:
- lock_owner can be used for fuse, but to use that we need to add
lock_owner to _call_stack_t or add lock_owner to gf_flock and use it
everywhere instead of struct flock. For libglusterfs_client and
booster we can probably use getpid() to fill lock_owner.
- glusterfs fs *need* the tgid for fd_create/fd_lookup

So, patch not comming tomorow, because I'm not sure what's the best
way to fix that.


-- 
Corentin Chary
http://xf.iksaif.net