1. 12 4月, 2012 1 次提交
  2. 15 2月, 2012 2 次提交
  3. 01 2月, 2012 1 次提交
  4. 13 1月, 2012 1 次提交
  5. 12 12月, 2011 1 次提交
  6. 17 12月, 2010 4 次提交
    • C
      lockd: Clean up nlmsvc_lookup_host() · 67216b94
      Chuck Lever 提交于
      Clean up.
      
      Change nlmsvc_lookup_host() to be purpose-built for server-side
      nlm_host management.  This replaces the generic nlm_lookup_host()
      helper function, just like on the client side.  The lookup logic is
      specialized for server host lookups.
      
      The server side cache also gets its own specialized equivalent of the
      nlm_release_host() function.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      67216b94
    • C
      lockd: Create client-side nlm_host cache · 8ea6ecc8
      Chuck Lever 提交于
      NFS clients don't need the garbage collection processing that is
      performed on nlm_host structures.  The client picks up an nlm_host at
      mount time and holds a reference to it until the file system is
      unmounted.
      
      Servers, on the other hand, don't have a precise way to tell when an
      nlm_host is no longer being used, so zero refcount nlm_host entries
      are left to expire in the cache after a time.
      
      Basically there's nothing holding a reference to an nlm_host between
      individual server-side NLM requests, but we can't afford the expense
      of recreating them for every new NLM request from a client.  The
      nlm_host cache adds some lifetime hysteresis to entries in the cache
      so the next time a particular nlm_host is needed, it's likely to be
      discovered by a lookup rather than created from whole cloth.
      
      With the new implementation, client nlm_host cache items are no longer
      garbage collected, and are destroyed directly by a new release
      function specialized for client entries, nlmclnt_release_host().  They
      are cached in their own data structure, and have their own lookup
      logic, simplified and specialized for client nlm_host entries.
      
      However, the client nlm_host cache still shares reboot recovery logic
      with the server nlm_host cache.  The NSM "peer rebooted" downcall for
      clients and servers still come through the same RPC call.  This is a
      legacy formal API that would be difficult to alter, and besides, the
      user space NSM implementation can't tell the difference between peers
      that are clients or servers.
      
      For this reason, the client cache continues to share the
      nlm_host_mutex (and reboot recovery logic) with the server cache.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      8ea6ecc8
    • C
      lockd: Split nlm_release_call() · 7db836d4
      Chuck Lever 提交于
      The nlm_release_call() function is invoked from both the server and
      the client side.  We're about to introduce a distinct server- and
      client-side nlm_release_host(), so nlm_release_call() must first be
      split into a client-side and a server-side version.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      7db836d4
    • C
      lockd: Move nlmdbg_cookie2a() to svclock.c · d8367c50
      Chuck Lever 提交于
      Clean up.  nlmdbg_cookie2a() is used only in svclock.c.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Tested-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d8367c50
  7. 16 11月, 2010 1 次提交
    • T
      NLM: Fix a regression in lockd · 8e35f8e7
      Trond Myklebust 提交于
      Nick Bowler reports:
      There are no unusual messages on the client... but I just logged into
      the server and I see lots of messages of the following form:
      
        nfsd: request from insecure port (192.168.8.199:35766)!
        nfsd: request from insecure port (192.168.8.199:35766)!
        nfsd: request from insecure port (192.168.8.199:35766)!
        nfsd: request from insecure port (192.168.8.199:35766)!
        nfsd: request from insecure port (192.168.8.199:35766)!
      
      Bisected to commit 92476850 (SUNRPC:
      Properly initialize sock_xprt.srcaddr in all cases)
      
      Apparently, removing the 'transport->srcaddr.ss_family = family' from
      xs_create_sock() triggers this due to nlmclnt_lookup_host() incorrectly
      initialising the srcaddr family to AF_UNSPEC.
      Reported-by: NNick Bowler <nbowler@elliptictech.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      8e35f8e7
  8. 22 9月, 2009 1 次提交
  9. 21 8月, 2009 1 次提交
  10. 18 6月, 2009 1 次提交
    • C
      lockd: Update NSM state from SM_MON replies · 6c9dc425
      Chuck Lever 提交于
      When rpc.statd starts up in user space at boot time, it attempts to
      write the latest NSM local state number into
      /proc/sys/fs/nfs/nsm_local_state.
      
      If lockd.ko isn't loaded yet (as is the case in most configurations),
      that file doesn't exist, thus the kernel's NSM state remains set to
      its initial value of zero during lockd operation.
      
      This is a problem because rpc.statd and lockd use the NSM state number
      to prevent repeated lock recovery on rebooted hosts.  If lockd sends
      a zero NSM state, but then a delayed SM_NOTIFY with a real NSM state
      number is received, there is no way for lockd or rpc.statd to
      distinguish that stale SM_NOTIFY from an actual reboot.  Thus lock
      recovery could be performed after the rebooted host has already
      started reclaiming locks, and those locks will be lost.
      
      We could change /etc/init.d/nfslock so it always modprobes lockd.ko
      before starting rpc.statd.  However, if lockd.ko is ever unloaded
      and reloaded, we are back at square one, since the NSM state is not
      preserved across an unload/reload cycle.  This may happen frequently
      on clients that use automounter.  A period of NFS inactivity causes
      lockd.ko to be unloaded, and the kernel loses its NSM state setting.
      
      Instead, let's use the fact that rpc.statd plants the local system's
      NSM state in every SM_MON (and SM_UNMON) reply.  lockd performs a
      synchronous SM_MON upcall to the local rpc.statd _before_ sending its
      first NLM request to a new remote.  This would permit rpc.statd to
      provide the current NSM state to lockd, even after lockd.ko had been
      unloaded and reloaded.
      
      Note that NLMPROC_LOCK arguments are constructed before the
      nsm_monitor() call, so we have to rearrange argument construction very
      slightly to make this all work out.
      
      And, the kernel appears to treat NSM state as a u32 (see struct
      nlm_args and nsm_res).  Make nsm_local_state a u32 as well, to ensure
      we don't get bogus comparison results.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6c9dc425
  11. 19 3月, 2009 1 次提交
  12. 11 3月, 2009 1 次提交
  13. 07 1月, 2009 20 次提交
  14. 24 12月, 2008 1 次提交
  15. 05 10月, 2008 1 次提交
  16. 04 10月, 2008 2 次提交
    • C
      lockd: Remove unused fields in the nlm_reboot structure · 9a38a838
      Chuck Lever 提交于
      The nlm_reboot structure is used to store information provided by the
      NSM_NOTIFY procedure.  This procedure is not specified by the NLM or NSM
      protocols, other than to say that the procedure can be used to transmit
      information private to a particular NLM/NSM implementation.
      
      For Linux, the callback arguments include the name of the monitored host,
      the new NSM state of the host, and a 16-byte private opaque.
      
      As a clean up, remove the unused fields and the server-side XDR logic that
      decodes them.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      9a38a838
    • C
      lockd: Add helper to sanity check incoming NOTIFY requests · b85e4676
      Chuck Lever 提交于
      lockd accepts SM_NOTIFY calls only from a privileged process on the
      local system.  If lockd uses an AF_INET6 listener, the sender's address
      (ie the local rpc.statd) will be the IPv6 loopback address, not the
      IPv4 loopback address.
      
      Make sure the privilege test in nlmsvc_proc_sm_notify() and
      nlm4svc_proc_sm_notify() works for both AF_INET and AF_INET6 family
      addresses by refactoring the test into a helper and adding support for
      IPv6 addresses.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      b85e4676