1. 24 7月, 2011 1 次提交
  2. 21 7月, 2011 1 次提交
    • J
      locks: rename lock-manager ops · 8fb47a4f
      J. Bruce Fields 提交于
      Both the filesystem and the lock manager can associate operations with a
      lock.  Confusingly, one of them (fl_release_private) actually has the
      same name in both operation structures.
      
      It would save some confusion to give the lock-manager ops different
      names.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8fb47a4f
  3. 16 7月, 2011 6 次提交
  4. 19 5月, 2011 1 次提交
  5. 30 4月, 2011 4 次提交
  6. 20 4月, 2011 1 次提交
  7. 19 4月, 2011 1 次提交
  8. 11 4月, 2011 1 次提交
    • J
      nfsd4: fix oops on lock failure · 23fcf2ec
      J. Bruce Fields 提交于
      Lock stateid's can have access_bmap 0 if they were only partially
      initialized (due to a failed lock request); handle that case in
      free_generic_stateid.
      
      ------------[ cut here ]------------
      kernel BUG at fs/nfsd/nfs4state.c:380!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/kernel/mm/ksm/run
      Modules linked in: nfs fscache md4 nls_utf8 cifs ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc nfsd lockd nfs_acl auth_rpcgss sunrpc ipv6 ppdev parport_pc parport pcnet32 mii pcspkr microcode i2c_piix4 BusLogic floppy [last unloaded: mperf]
      
      Pid: 1468, comm: nfsd Not tainted 2.6.38+ #120 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
      EIP: 0060:[<e24f180d>] EFLAGS: 00010297 CPU: 0
      EIP is at nfs4_access_to_omode+0x1c/0x29 [nfsd]
      EAX: ffffffff EBX: dd758120 ECX: 00000000 EDX: 00000004
      ESI: dd758120 EDI: ddfe657c EBP: dd54dde0 ESP: dd54dde0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process nfsd (pid: 1468, ti=dd54c000 task=ddc92580 task.ti=dd54c000)
      Stack:
       dd54ddf0 e24f19ca 00000000 ddfe6560 dd54de08 e24f1a5d dd758130 deee3a20
       ddfe6560 31270000 dd54df1c e24f52fd 0000000f dd758090 e2505dd0 0be304cf
       dbb51d68 0000000e ddfe657c ddcd8020 dd758130 dd758128 dd7580d8 dd54de68
      Call Trace:
       [<e24f19ca>] free_generic_stateid+0x1c/0x3e [nfsd]
       [<e24f1a5d>] release_lockowner+0x71/0x8a [nfsd]
       [<e24f52fd>] nfsd4_lock+0x617/0x66c [nfsd]
       [<e24e57b6>] ? nfsd_setuser+0x199/0x1bb [nfsd]
       [<e24e056c>] ? nfsd_setuser_and_check_port+0x65/0x81 [nfsd]
       [<c07a0052>] ? _cond_resched+0x8/0x1c
       [<c04ca61f>] ? slab_pre_alloc_hook.clone.33+0x23/0x27
       [<c04cac01>] ? kmem_cache_alloc+0x1a/0xd2
       [<c04835a0>] ? __call_rcu+0xd7/0xdd
       [<e24e0dfb>] ? fh_verify+0x401/0x452 [nfsd]
       [<e24f0b61>] ? nfsd4_encode_operation+0x52/0x117 [nfsd]
       [<e24ea0d7>] ? nfsd4_putfh+0x33/0x3b [nfsd]
       [<e24f4ce6>] ? nfsd4_delegreturn+0xd4/0xd4 [nfsd]
       [<e24ea2c9>] nfsd4_proc_compound+0x1ea/0x33e [nfsd]
       [<e24de6ee>] nfsd_dispatch+0xd1/0x1a5 [nfsd]
       [<e1d6e1c7>] svc_process_common+0x282/0x46f [sunrpc]
       [<e1d6e578>] svc_process+0xdc/0xfa [sunrpc]
       [<e24de0fa>] nfsd+0xd6/0x115 [nfsd]
       [<e24de024>] ? nfsd_shutdown+0x24/0x24 [nfsd]
       [<c0454322>] kthread+0x62/0x67
       [<c04542c0>] ? kthread_worker_fn+0x114/0x114
       [<c07a6ebe>] kernel_thread_helper+0x6/0x10
      Code: eb 05 b8 00 00 27 4f 8d 65 f4 5b 5e 5f 5d c3 83 e0 03 55 83 f8 02 89 e5 74 17 83 f8 03 74 05 48 75 09 eb 09 b8 02 00 00 00 eb 0b <0f> 0b 31 c0 eb 05 b8 01 00 00 00 5d c3 55 89 e5 57 56 89 d6 8d
      EIP: [<e24f180d>] nfs4_access_to_omode+0x1c/0x29 [nfsd] SS:ESP 0068:dd54dde0
      ---[ end trace 2b0bf6c6557cb284 ]---
      
      The trace route is:
      
       -> nfsd4_lock()
         -> if (lock->lk_is_new) {
           -> alloc_init_lock_stateid()
      
              3739: stp->st_access_bmap = 0;
      
         ->if (status && lock->lk_is_new && lock_sop)
           -> release_lockowner()
            -> free_generic_stateid()
             -> nfs4_access_bmap_to_omode()
                -> nfs4_access_to_omode()
      
              380: BUG();   *****
      
      This problem was introduced by 0997b173.
      Reported-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
      Tested-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      23fcf2ec
  9. 31 3月, 2011 1 次提交
  10. 16 3月, 2011 1 次提交
  11. 09 3月, 2011 2 次提交
  12. 08 3月, 2011 2 次提交
  13. 14 2月, 2011 7 次提交
  14. 12 1月, 2011 9 次提交
  15. 05 1月, 2011 2 次提交
    • T
      nfs4: set source address when callback is generated · 6f3d772f
      Takuma Umeya 提交于
      when callback is generated in NFSv4 server, it doesn't set the source
      address. When an alias IP is utilized on NFSv4 server and suppose the
      client is accessing via that alias IP (e.g. eth0:0), the client invokes
      the callback to the IP address that is set on the original device (e.g.
      eth0). This behavior results in timeout of xprt.
      The patch sets the IP address that the client should invoke callback to.
      Signed-off-by: NTakuma Umeya <tumeya@redhat.com>
      [bfields@redhat.com: Simplify gen_callback arguments, use helper function]
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      6f3d772f
    • J
      locks: eliminate fl_mylease callback · c45821d2
      J. Bruce Fields 提交于
      The nfs server only supports read delegations for now, so we don't care
      how conflicts are determined.  All we care is that unlocks are
      recognized as matching the leases they are meant to remove.  After the
      last patch, a comparison of struct files will work for that purpose.  So
      we no longer need this callback.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c45821d2