1. 25 10月, 2010 5 次提交
    • R
      Revalidate caches on lock · 6b96724e
      Ricardo Labiaga 提交于
      Instead of blindly zapping the caches, attempt to revalidate them if
      the server has indicated that it uses high resolution timestamps.
      
      NFSv4 should be able to always revalidate the cache since the
      protocol requires the update of the change attribute on modification of
      the data.  In reality, there are servers (the Linux NFS server
      for example) that do not obey this requirement and use ctime as the
      basis for change attribute.  Long term, the server needs to be fixed.
      At this time, and to be on the safe side, continue zapping caches if
      the server indicates that it does not have a high resolution timestamp.
      Signed-off-by: NRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6b96724e
    • T
      SUNRPC: After calling xprt_release(), we must restart from call_reserve · 118df3d1
      Trond Myklebust 提交于
      Rob Leslie reports seeing the following Oops after his Kerberos session
      expired.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000058
      IP: [<e186ed94>] rpcauth_refreshcred+0x11/0x12c [sunrpc]
      *pde = 00000000
      Oops: 0000 [#1]
      last sysfs file: /sys/devices/platform/pc87360.26144/temp3_input
      Modules linked in: autofs4 authenc esp4 xfrm4_mode_transport ipt_LOG ipt_REJECT xt_limit xt_state ipt_REDIRECT xt_owner xt_HL xt_hl xt_tcpudp xt_mark cls_u32 cls_tcindex sch_sfq sch_htb sch_dsmark geodewdt deflate ctr twofish_generic twofish_i586 twofish_common camellia serpent blowfish cast5 cbc xcbc rmd160 sha512_generic sha1_generic hmac crypto_null af_key rpcsec_gss_krb5 nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip_gre sit tunnel4 dummy ext3 jbd nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pc8736x_gpio nsc_gpio pc87360 hwmon_vid loop aes_i586 aes_generic sha256_generic dm_crypt cs5535_gpio serio_raw cs5535_mfgpt hifn_795x des_generic geode_rng rng_core led_class ext4 mbcache jbd2 crc16 dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sd_mod crc_t10dif ide_pci_generic cs5536 amd74xx ide_core pata_cs5536 ata_generic libata usb_storage via_rhine mii scsi_mod btrfs zlib_deflate crc32c libcrc32c [last unloaded: scsi_wait_scan]
      
      Pid: 12875, comm: sudo Not tainted 2.6.36-net5501 #1 /
      EIP: 0060:[<e186ed94>] EFLAGS: 00010292 CPU: 0
      EIP is at rpcauth_refreshcred+0x11/0x12c [sunrpc]
      EAX: 00000000 EBX: defb13a0 ECX: 00000006 EDX: e18683b8
      ESI: defb13a0 EDI: 00000000 EBP: 00000000 ESP: de571d58
       DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      Process sudo (pid: 12875, ti=de570000 task=decd1430 task.ti=de570000)
      Stack:
       e186e008 00000000 defb13a0 0000000d deda6000 e1868f22 e196f12b defb13a0
      <0> defb13d8 00000000 00000000 e186e0aa 00000000 defb13a0 de571dac 00000000
      <0> e186956c de571e34 debea5c0 de571dc8 e186967a 00000000 debea5c0 de571e34
      Call Trace:
       [<e186e008>] ? rpc_wake_up_next+0x114/0x11b [sunrpc]
       [<e1868f22>] ? call_decode+0x24a/0x5af [sunrpc]
       [<e196f12b>] ? nfs4_xdr_dec_access+0x0/0xa2 [nfs]
       [<e186e0aa>] ? __rpc_execute+0x62/0x17b [sunrpc]
       [<e186956c>] ? rpc_run_task+0x91/0x97 [sunrpc]
       [<e186967a>] ? rpc_call_sync+0x40/0x5b [sunrpc]
       [<e1969ca2>] ? nfs4_proc_access+0x10a/0x176 [nfs]
       [<e19572fa>] ? nfs_do_access+0x2b1/0x2c0 [nfs]
       [<e186ed61>] ? rpcauth_lookupcred+0x62/0x84 [sunrpc]
       [<e19573b6>] ? nfs_permission+0xad/0x13b [nfs]
       [<c0177824>] ? exec_permission+0x15/0x4b
       [<c0177fbd>] ? link_path_walk+0x4f/0x456
       [<c017867d>] ? path_walk+0x4c/0xa8
       [<c0179678>] ? do_path_lookup+0x1f/0x68
       [<c017a3fb>] ? user_path_at+0x37/0x5f
       [<c016359c>] ? handle_mm_fault+0x229/0x55b
       [<c0170a2d>] ? sys_faccessat+0x93/0x146
       [<c0170aef>] ? sys_access+0xf/0x13
       [<c02cf615>] ? syscall_call+0x7/0xb
      Code: 0f 94 c2 84 d2 74 09 8b 44 24 0c e8 6a e9 8b de 83 c4 14 89 d8 5b 5e 5f 5d c3 55 57 56 53 83 ec 1c fc 89 c6 8b 40 10 89 44 24 04 <8b> 58 58 85 db 0f 85 d4 00 00 00 0f b7 46 70 8b 56 20 89 c5 83
      EIP: [<e186ed94>] rpcauth_refreshcred+0x11/0x12c [sunrpc] SS:ESP 0068:de571d58
      CR2: 0000000000000058
      
      This appears to be caused by the function rpc_verify_header() first
      calling xprt_release(), then doing a call_refresh. If we release the
      transport slot, we should _always_ jump back to call_reserve before
      calling anything else.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      118df3d1
    • T
      NFSv4: Fix up the 'dircount' hint in encode_readdir · 6f7a35bd
      Trond Myklebust 提交于
      Also ensure we only ask for either fileid or mounted_on_fileid in the
      readdirplus case too...
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6f7a35bd
    • T
      NFSv4: Clean up nfs4_decode_dirent · 9af8c222
      Trond Myklebust 提交于
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      9af8c222
    • T
      NFSv4: nfs4_decode_dirent must clear entry->fattr->valid · 4f082222
      Trond Myklebust 提交于
      Otherwise, we may end up reading uninitialised data from the resulting
      struct nfs_fattr.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4f082222
  2. 24 10月, 2010 18 次提交
  3. 20 10月, 2010 4 次提交
  4. 08 10月, 2010 1 次提交
    • B
      NFS: new idmapper · 955a857e
      Bryan Schumaker 提交于
      This patch creates a new idmapper system that uses the request-key function to
      place a call into userspace to map user and group ids to names.  The old
      idmapper was single threaded, which prevented more than one request from running
      at a single time.  This means that a user would have to wait for an upcall to
      finish before accessing a cached result.
      
      The upcall result is stored on a keyring of type id_resolver.  See the file
      Documentation/filesystems/nfs/idmapper.txt for instructions.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      [Trond: fix up the return value of nfs_idmap_lookup_name and clean up code]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      955a857e
  5. 30 9月, 2010 3 次提交
  6. 24 9月, 2010 3 次提交
  7. 23 9月, 2010 1 次提交
    • S
      nfs: introduce mount option '-olocal_lock' to make locks local · 5eebde23
      Suresh Jayaraman 提交于
      NFS clients since 2.6.12 support flock locks by emulating fcntl byte-range
      locks. Due to this, some windows applications which seem to use both flock
      (share mode lock mapped as flock by Samba) and fcntl locks sequentially on
      the same file, can't lock as they falsely assume the file is already locked.
      The problem was reported on a setup with windows clients accessing excel files
      on a Samba exported share which is originally a NFS mount from a NetApp filer.
      
      Older NFS clients (< 2.6.12) did not see this problem as flock locks were
      considered local. To support legacy flock behavior, this patch adds a mount
      option "-olocal_lock=" which can take the following values:
      
         'none'  		- Neither flock locks nor POSIX locks are local
         'flock' 		- flock locks are local
         'posix' 		- fcntl/POSIX locks are local
         'all'		- Both flock locks and POSIX locks are local
      
      Testing:
      
         - This patch was tested by using -olocal_lock option with different values
           and the NLM calls were noted from the network packet captured.
      
           'none'  - NLM calls were seen during both flock() and fcntl(), flock lock
         	       was granted, fcntl was denied
           'flock' - no NLM calls for flock(), NLM call was seen for fcntl(),
         	       granted
           'posix' - NLM call was seen for flock() - granted, no NLM call for fcntl()
           'all'   - no NLM calls were seen during both flock() and fcntl()
      
         - No bugs were seen during NFSv4 locking/unlocking in general and NFSv4
           reboot recovery.
      
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      5eebde23
  8. 22 9月, 2010 5 次提交