1. 14 Feb, 2012 1 commit
  2. 31 Jan, 2012 1 commit
  3. 12 Jan, 2012 1 commit
  4. 11 Dec, 2011 1 commit
  5. 16 Dec, 2010 4 commits
    • Chuck Lever's avatar
      lockd: Clean up nlmsvc_lookup_host() · 67216b94
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    • Chuck Lever's avatar
      lockd: Create client-side nlm_host cache · 8ea6ecc8
      Chuck Lever authored
      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
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    • Chuck Lever's avatar
      lockd: Split nlm_release_call() · 7db836d4
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    • Chuck Lever's avatar
      lockd: Move nlmdbg_cookie2a() to svclock.c · d8367c50
      Chuck Lever authored
      Clean up.  nlmdbg_cookie2a() is used only in svclock.c.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
  6. 15 Nov, 2010 1 commit
    • Trond Myklebust's avatar
      NLM: Fix a regression in lockd · 8e35f8e7
      Trond Myklebust authored
      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 (!
        nfsd: request from insecure port (!
        nfsd: request from insecure port (!
        nfsd: request from insecure port (!
        nfsd: request from insecure port (!
      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: default avatarNick Bowler <nbowler@elliptictech.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
  7. 22 Sep, 2009 1 commit
  8. 21 Aug, 2009 1 commit
  9. 17 Jun, 2009 1 commit
    • Chuck Lever's avatar
      lockd: Update NSM state from SM_MON replies · 6c9dc425
      Chuck Lever authored
      When rpc.statd starts up in user space at boot time, it attempts to
      write the latest NSM local state number into
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
  10. 18 Mar, 2009 1 commit
  11. 10 Mar, 2009 1 commit
  12. 06 Jan, 2009 20 commits
  13. 23 Dec, 2008 1 commit
  14. 04 Oct, 2008 1 commit
  15. 03 Oct, 2008 4 commits