1. 25 11月, 2014 1 次提交
  2. 10 9月, 2014 1 次提交
    • J
      lockd: rip out deferred lock handling from testlock codepath · 09802fd2
      Jeff Layton 提交于
      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: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NKinglong Mee <kinglongmee@gmail.com>
      09802fd2
  3. 07 5月, 2014 1 次提交
  4. 23 2月, 2013 1 次提交
  5. 16 2月, 2013 1 次提交
  6. 28 7月, 2012 2 次提交
  7. 12 4月, 2012 1 次提交
  8. 15 2月, 2012 2 次提交
  9. 01 2月, 2012 1 次提交
  10. 13 1月, 2012 1 次提交
  11. 12 12月, 2011 1 次提交
  12. 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
  13. 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
  14. 22 9月, 2009 1 次提交
  15. 21 8月, 2009 1 次提交
  16. 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
  17. 19 3月, 2009 1 次提交
  18. 11 3月, 2009 1 次提交
  19. 07 1月, 2009 17 次提交
新手
引导
客服 返回
顶部