nlm svid changes from pid --> nlm_lockowner

nlm svid changes from pid --> nlm_lockowner

[Samuel Li]

A simple question with NLM svid implementation with after 2.6.16 or later.

In the old days when linux client request and NLM lock it submits a
svid with the content of the client pid. However this appears to have
changed a few year ago and I get an incremental number starting from 0.

from the NLM server side we only report the content of svid. I am trying 
to find a way to identify the end user application request.

for example

[sli@fed16-vm nfs3]# ./gwaiting & ./gwaiting & ./gwaiting &  (excl lock 
programs)
[2] 977  <--pid
[3] 978
[4] 979

    tshark -i eth0 -R "nlm" -V | grep -i svid
OOPS: dissector table "sctp.ppi" doesn't exist
Protocol being registered is "Datagram Transport Layer Security"
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
           svid: 4
           svid: 3
           svid: 5
           svid: 3
           svid: 4
           svid: 4
           svid: 4
           svid: 5
           svid: 5

How do I determine from the client side who owns these NLM processes?

The file lock in question was
inode 4318756868 so I could determine the lock.

cat /proc/locks
1: POSIX  ADVISORY  WRITE 979 00:2a:4315692708 0 EOF
1: -> ACCESS ADVISORY  WRITE 978 00:2a:4315692708 0 EOF
2: POSIX  ADVISORY  WRITE 1778 00:10:16424 0 EOF
3: POSIX  ADVISORY  WRITE 1677 00:10:18376 0 EOF

Now assume I did not have the output of /proc/locks and only 
nlm_lockowner number how would I debug this?

I found the change in

commit 7bab377fcb495ee2e5a1cd69d235f8d84c76e3af
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Mar 20 13:44:06 2006 -0500

      lockd: Don't expose the process pid to the NLM server

      Instead we use the nlm_lockowner->pid.

      Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>





-- 
Best regards,

Samuel Li
Escalation Engineer
EMC²| Isilon Storage Division
samuel.li@isilon.com

Re: nlm svid changes from pid --> nlm_lockowner

[Myklebust, Trond]

On Fri, 2013-01-11 at 13:54 -0500, Samuel Li wrote:
> A simple question with NLM svid implementation with after 2.6.16 or later.
> 
> In the old days when linux client request and NLM lock it submits a
> svid with the content of the client pid. However this appears to have
> changed a few year ago and I get an incremental number starting from 0.
> 
> from the NLM server side we only report the content of svid. I am trying 
> to find a way to identify the end user application request.
> 
> for example
> 
> [sli@fed16-vm nfs3]# ./gwaiting & ./gwaiting & ./gwaiting &  (excl lock 
> programs)
> [2] 977  <--pid
> [3] 978
> [4] 979
> 
>     tshark -i eth0 -R "nlm" -V | grep -i svid
> OOPS: dissector table "sctp.ppi" doesn't exist
> Protocol being registered is "Datagram Transport Layer Security"
> Running as user "root" and group "root". This could be dangerous.
> Capturing on eth0
>            svid: 4
>            svid: 3
>            svid: 5
>            svid: 3
>            svid: 4
>            svid: 4
>            svid: 4
>            svid: 5
>            svid: 5
> 
> How do I determine from the client side who owns these NLM processes?
> 
> The file lock in question was
> inode 4318756868 so I could determine the lock.
> 
> cat /proc/locks
> 1: POSIX  ADVISORY  WRITE 979 00:2a:4315692708 0 EOF
> 1: -> ACCESS ADVISORY  WRITE 978 00:2a:4315692708 0 EOF
> 2: POSIX  ADVISORY  WRITE 1778 00:10:16424 0 EOF
> 3: POSIX  ADVISORY  WRITE 1677 00:10:18376 0 EOF
> 
> Now assume I did not have the output of /proc/locks and only 
> nlm_lockowner number how would I debug this?

The POSIX lock inheritance rules under the clone() system call (where
POSIX locks must follow the file descriptor table and _not_ the pid
inheritance rules) mean that the svid does not map naturally into a pid.
So post-2.6.16 we no longer try to pretend that is the case.

The bottom line is that you can use the svid as a debugging tool for
figuring out which locks belong to the same lock owner, but you cannot
map it to a pid.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com