Re: [PATCH fs/locks 2 of 3] Use proper tgid in locks_remove_posix

[Peter Staubach <staubach@redhat.com>]

Olaf Kirch wrote:

>On Mon, Jul 11, 2005 at 09:02:21AM -0400, Trond Myklebust wrote:
>  
>
>>For posix locks we should pretty much be ignoring the value of fl_pid.
>>It gets returned to the user in a F_GETLK call, but all the low-level
>>functions (such as posix_same_owner) should be testing the value of
>>fl_owner instead.
>>
>>The exception here is nlmsvc_same_owner(), which has to follow the NLM
>>byte range spec but doesn't rely on locks_remove_posix.
>>    
>>
>
>Let me try to explain this a little better. What I believe is happening
>is that on the client, thread A with tgid 0xA establishes a lock,
>and when thread B closes the file. locks_remove_posix sends an unlock request
>to the server with tgid 0xB.
>
>On the server, posix_lock_file walks the list of all existing locks,
>comparing the lock owner via nlmsvc_same_owner - and since the fl_pid
>value of the request is 0xB, this misses the established lock with
>fl_pid == 0xA.
>

I am not particularly following this logic.  It sounds reasonable, but I 
would
feel better if you had some way of reproducing and showing the problem.

    Thanx...

       ps


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs