Re: nlm svid changes from pid --> nlm_lockowner

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2013-01-11 at 13:54 -0500, Samuel Li wrote:
+AD4- A simple question with NLM svid implementation with after 2.6.16 or later.
+AD4- 
+AD4- In the old days when linux client request and NLM lock it submits a
+AD4- svid with the content of the client pid. However this appears to have
+AD4- changed a few year ago and I get an incremental number starting from 0.
+AD4- 
+AD4- from the NLM server side we only report the content of svid. I am trying 
+AD4- to find a way to identify the end user application request.
+AD4- 
+AD4- for example
+AD4- 
+AD4- +AFs-sli+AEA-fed16-vm nfs3+AF0AIw- ./gwaiting +ACY- ./gwaiting +ACY- ./gwaiting +ACY-  (excl lock 
+AD4- programs)
+AD4- +AFs-2+AF0- 977  +ADw---pid
+AD4- +AFs-3+AF0- 978
+AD4- +AFs-4+AF0- 979
+AD4- 
+AD4-     tshark -i eth0 -R +ACI-nlm+ACI- -V +AHw- grep -i svid
+AD4- OOPS: dissector table +ACI-sctp.ppi+ACI- doesn't exist
+AD4- Protocol being registered is +ACI-Datagram Transport Layer Security+ACI-
+AD4- Running as user +ACI-root+ACI- and group +ACI-root+ACI-. This could be dangerous.
+AD4- Capturing on eth0
+AD4-            svid: 4
+AD4-            svid: 3
+AD4-            svid: 5
+AD4-            svid: 3
+AD4-            svid: 4
+AD4-            svid: 4
+AD4-            svid: 4
+AD4-            svid: 5
+AD4-            svid: 5
+AD4- 
+AD4- How do I determine from the client side who owns these NLM processes?
+AD4- 
+AD4- The file lock in question was
+AD4- inode 4318756868 so I could determine the lock.
+AD4- 
+AD4- cat /proc/locks
+AD4- 1: POSIX  ADVISORY  WRITE 979 00:2a:4315692708 0 EOF
+AD4- 1: -+AD4- ACCESS ADVISORY  WRITE 978 00:2a:4315692708 0 EOF
+AD4- 2: POSIX  ADVISORY  WRITE 1778 00:10:16424 0 EOF
+AD4- 3: POSIX  ADVISORY  WRITE 1677 00:10:18376 0 EOF
+AD4- 
+AD4- Now assume I did not have the output of /proc/locks and only 
+AD4- nlm+AF8-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 +AF8-not+AF8- 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+AEA-netapp.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux