1. 07 Jan, 2016 1 commit
  2. 23 Oct, 2015 1 commit
    • Andrey Ryabinin's avatar
      lockd: get rid of reference-counted NSM RPC clients · 0d0f4aab
      Andrey Ryabinin authored
      Currently we have reference-counted per-net NSM RPC client
      which created on the first monitor request and destroyed
      after the last unmonitor request. It's needed because
      RPC client need to know 'utsname()->nodename', but utsname()
      might be NULL when nsm_unmonitor() called.
      So instead of holding the rpc client we could just save nodename
      in struct nlm_host and pass it to the rpc_create().
      Thus ther is no need in keeping rpc client until last
      unmonitor request. We could create separate RPC clients
      for each monitor/unmonitor requests.
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
  3. 12 Oct, 2015 1 commit
    • Andrey Ryabinin's avatar
      lockd: create NSM handles per net namespace · 0ad95472
      Andrey Ryabinin authored
      Commit cb7323ff ("lockd: create and use per-net NSM
       RPC clients on MON/UNMON requests") introduced per-net
      NSM RPC clients. Unfortunately this doesn't make any sense
      without per-net nsm_handle.
      E.g. the following scenario could happen
      Two hosts (X and Y) in different namespaces (A and B) share
      the same nsm struct.
      1. nsm_monitor(host_X) called => NSM rpc client created,
      	nsm->sm_monitored bit set.
      2. nsm_mointor(host-Y) called => nsm->sm_monitored already set,
      	we just exit. Thus in namespace B ln->nsm_clnt == NULL.
      3. host X destroyed => nsm->sm_count decremented to 1
      4. host Y destroyed => nsm_unmonitor() => nsm_mon_unmon() => NULL-ptr
      	dereference of *ln->nsm_clnt
      So this could be fixed by making per-net nsm_handles list,
      instead of global. Thus different net namespaces will not be able
      share the same nsm_handle.
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
  4. 24 Nov, 2014 1 commit
  5. 09 Sep, 2014 1 commit
    • Jeff Layton's avatar
      lockd: rip out deferred lock handling from testlock codepath · 09802fd2
      Jeff Layton authored
      As Kinglong points out, the nlm_block->b_fl field is no longer used at
      all. Also, vfs_test_lock in the generic locking code will only return
      FILE_LOCK_DEFERRED if FL_SLEEP is set, and it isn't here.
      The only other place that returns that value is the DLM lock code, but
      it only does that in dlm_posix_lock, never in dlm_posix_get.
      Remove all of the deferred locking code from the testlock codepath
      since it doesn't appear to ever be used anyway.
      I do have a small concern that this might cause a behavior change in the
      case where you have a block already sitting on the list when the
      testlock request comes in, but that looks like it doesn't really work
      properly anyway. I think it's best to just pass that down to
      vfs_test_lock and let the filesystem report that instead of trying to
      infer what's going on with the lock by looking at an existing block.
      Cc: cluster-devel@redhat.com
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Reviewed-by: default avatarKinglong Mee <kinglongmee@gmail.com>
  6. 06 May, 2014 1 commit
  7. 22 Feb, 2013 1 commit
  8. 15 Feb, 2013 1 commit
  9. 27 Jul, 2012 2 commits
  10. 11 Apr, 2012 1 commit
  11. 14 Feb, 2012 2 commits
  12. 31 Jan, 2012 1 commit
  13. 12 Jan, 2012 1 commit
  14. 11 Dec, 2011 1 commit
  15. 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>
  16. 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>
  17. 22 Sep, 2009 1 commit
  18. 21 Aug, 2009 1 commit
  19. 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>
  20. 18 Mar, 2009 1 commit
  21. 10 Mar, 2009 1 commit
  22. 06 Jan, 2009 14 commits