1. 25 10月, 2010 1 次提交
    • 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
  2. 04 8月, 2010 4 次提交
  3. 18 5月, 2010 1 次提交
  4. 15 5月, 2010 1 次提交
  5. 22 3月, 2010 1 次提交
  6. 04 12月, 2009 5 次提交
    • C
      SUNRPC: soft connect semantics for UDP · 3a28becc
      Chuck Lever 提交于
      Introduce soft connect behavior for UDP transports.  In this case, a
      major timeout returns ETIMEDOUT instead of EIO.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      3a28becc
    • C
      SUNRPC: Use soft connect semantics when performing RPC ping · caabea8a
      Chuck Lever 提交于
      Currently, if a remote RPC service is unreachable, an RPC ping will
      hang until the underlying transport connect attempt times out.  A more
      desirable behavior might be to have the ping fail immediately so upper
      layers can recover appropriately.
      
      In the case of an NFS mount, for instance, this would mean the
      mount(2) system call could fail immediately if the server isn't
      listening, rather than hanging uninterruptibly for more than 3
      minutes.
      
      Change rpc_ping() so that it fails immediately for connection-oriented
      transports.  rpc_create() will then fail immediately for such
      transports if an RPC ping was requested.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      caabea8a
    • C
      SUNRPC: Use soft connects for autobinding over TCP · 012da158
      Chuck Lever 提交于
      Autobinding is handled by the rpciod process, not in user processes
      that are generating regular RPC requests.  Thus autobinding is usually
      not affected by signals targetting user processes, such as KILL or
      timer expiration events.
      
      In addition, an RPC request generated by a user process that has
      RPC_TASK_SOFTCONN set and needs to perform an autobind will hang if
      the remote rpcbind service is not available.
      
      For rpcbind queries on connection-oriented transports, let's use the
      new soft connect semantic to return control to the user's process
      quickly, if the kernel's rpcbind client can't connect to the remote
      rpcbind service.
      
      Logic is introduced in call_bind_status() to handle connection errors
      that occurred during an asynchronous rpcbind query.  The logic
      abandons the rpcbind query if the RPC request has SOFTCONN set, and
      retries after a few seconds in the normal case.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      012da158
    • C
      SUNRPC: Allow RPCs to fail quickly if the server is unreachable · 09a21c41
      Chuck Lever 提交于
      The kernel sometimes makes RPC calls to services that aren't running.
      Because the kernel's RPC client always assumes the hard retry semantic
      when reconnecting a connection-oriented RPC transport, the underlying
      reconnect logic takes a long while to time out, even though the remote
      may have responded immediately with ECONNREFUSED.
      
      In certain cases, like upcalls to our local rpcbind daemon, or for NFS
      mount requests, we'd like the kernel to fail immediately if the remote
      service isn't reachable.  This allows another transport to be tried
      immediately, or the pending request can be abandoned quickly.
      
      Introduce a per-request flag which controls how call_transmit_status()
      behaves when request transmission fails because the server cannot be
      reached.
      
      We don't want soft connection semantics to apply to other errors.  The
      default case of the switch statement in call_transmit_status() no
      longer falls through; the fall through code is copied to the default
      case, and a "break;" is added.
      
      The transport's connection re-establishment timeout is also ignored for
      such requests.  We want the request to fail immediately, so the
      reconnect delay is skipped.  Additionally, we don't want a connect
      failure here to further increase the reconnect timeout value, since
      this request will not be retried.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      09a21c41
    • C
      SUNRPC: Check explicitly for tk_status == 0 in call_transmit_status() · 206a134b
      Chuck Lever 提交于
      The success case, where task->tk_status == 0, is by far the most
      frequent case in call_transmit_status().
      
      The default: arm of the switch statement in call_transmit_status()
      handles the 0 case.  default: was moved close to the top of the switch
      statement in call_transmit_status() under the theory that the compiler
      places object code for the earliest arms of a switch statement first,
      making the CPU do less work.
      
      The default: arm of a switch statement, however, is executed only
      after all the other cases have been checked.  Even if the compiler
      rearranges the object code, the default: arm is the "last resort",
      meaning all of the other cases have been explicitly exhausted.  That
      makes the current arrangement about as inefficient as it gets for the
      common case.
      
      To fix this, add an explicit check for zero before the switch
      statement.  That forces the compiler to do the zero check first, no
      matter what optimizations it might try to do to the switch statement.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      206a134b
  7. 25 9月, 2009 2 次提交
  8. 14 9月, 2009 1 次提交
  9. 29 8月, 2009 1 次提交
  10. 10 8月, 2009 3 次提交
  11. 13 7月, 2009 1 次提交
  12. 18 6月, 2009 4 次提交
  13. 12 3月, 2009 3 次提交
  14. 24 12月, 2008 1 次提交
  15. 31 10月, 2008 1 次提交
  16. 30 10月, 2008 1 次提交
  17. 29 10月, 2008 1 次提交
  18. 08 10月, 2008 1 次提交
    • C
      sunrpc: fix oops in rpc_create when the mount namespace is unshared · 63ffc23d
      Cedric Le Goater 提交于
      On a system with nfs mounts, if a task unshares its mount namespace,
      a oops can occur when the system is rebooted if the task is the last
      to unreference the nfs mount. It will try to create a rpc request
      using utsname() which has been invalidated by free_nsproxy().
      
      The patch fixes the issue by using the global init_utsname() which is
      always valid. the capability of identifying rpc clients per uts namespace
      stills needs some extra work so this should not be a problem.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000004
      IP: [<c024c9ab>] rpc_create+0x332/0x42f
      Oops: 0000 [#1] DEBUG_PAGEALLOC
      
      Pid: 1857, comm: uts-oops Not tainted (2.6.27-rc5-00319-g7686ad56 #4)
      EIP: 0060:[<c024c9ab>] EFLAGS: 00210287 CPU: 0
      EIP is at rpc_create+0x332/0x42f
      EAX: 00000000 EBX: df26adf0 ECX: c0251887 EDX: 00000001
      ESI: df26ae58 EDI: c02f293c EBP: dda0fc9c ESP: dda0fc2c
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process uts-oops (pid: 1857, ti=dda0e000 task=dd9a0778 task.ti=dda0e000)
      Stack: c0104532 dda0fffc dda0fcac dda0e000 dda0e000 dd93b7f0 00000009 c02f2880
             df26aefc dda0fc68 c01096b7 00000000 c0266ee0 c039a070 c039a070 dda0fc74
             c012ca67 c039a064 dda0fc8c c012cb20 c03daf74 00000011 00000000 c0275c90
      Call Trace:
       [<c0104532>] ? dump_trace+0xc2/0xe2
       [<c01096b7>] ? save_stack_trace+0x1c/0x3a
       [<c012ca67>] ? save_trace+0x37/0x8c
       [<c012cb20>] ? add_lock_to_list+0x64/0x96
       [<c0256fc4>] ? rpcb_register_call+0x62/0xbb
       [<c02570c8>] ? rpcb_register+0xab/0xb3
       [<c0252f4d>] ? svc_register+0xb4/0x128
       [<c0253114>] ? svc_destroy+0xec/0x103
       [<c02531b2>] ? svc_exit_thread+0x87/0x8d
       [<c01a75cd>] ? lockd_down+0x61/0x81
       [<c01a577b>] ? nlmclnt_done+0xd/0xf
       [<c01941fe>] ? nfs_destroy_server+0x14/0x16
       [<c0194328>] ? nfs_free_server+0x4c/0xaa
       [<c019a066>] ? nfs_kill_super+0x23/0x27
       [<c0158585>] ? deactivate_super+0x3f/0x51
       [<c01695d1>] ? mntput_no_expire+0x95/0xb4
       [<c016965b>] ? release_mounts+0x6b/0x7a
       [<c01696cc>] ? __put_mnt_ns+0x62/0x70
       [<c0127501>] ? free_nsproxy+0x25/0x80
       [<c012759a>] ? switch_task_namespaces+0x3e/0x43
       [<c01275a9>] ? exit_task_namespaces+0xa/0xc
       [<c0117fed>] ? do_exit+0x4fd/0x666
       [<c01181b3>] ? do_group_exit+0x5d/0x83
       [<c011fa8c>] ? get_signal_to_deliver+0x2c8/0x2e0
       [<c0102630>] ? do_notify_resume+0x69/0x700
       [<c011d85a>] ? do_sigaction+0x134/0x145
       [<c0127205>] ? hrtimer_nanosleep+0x8f/0xce
       [<c0126d1a>] ? hrtimer_wakeup+0x0/0x1c
       [<c0103488>] ? work_notifysig+0x13/0x1b
       =======================
      Code: 70 20 68 cb c1 2c c0 e8 75 4e 01 00 8b 83 ac 00 00 00 59 3d 00 f0 ff ff 5f 77 63 eb 57 a1 00 80 2d c0 8b 80 a8 02 00 00 8d 73 68 <8b> 40 04 83 c0 45 e8 41 46 f7 ff ba 20 00 00 00 83 f8 21 0f 4c
      EIP: [<c024c9ab>] rpc_create+0x332/0x42f SS:ESP 0068:dda0fc2c
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: "Serge E. Hallyn" <serue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      63ffc23d
  19. 30 9月, 2008 1 次提交
  20. 10 7月, 2008 6 次提交
    • T
      SUNRPC: Ensure our task is notified when an rpcbind call is done · 381ba74a
      Trond Myklebust 提交于
      If another task is busy in rpcb_getport_async number, it is more efficient
      to have it wake us up when it has finished instead of arbitrarily sleeping
      for 5 seconds.
      
      Also ensure that rpcb_wake_rpcbind_waiters() is called regardless of
      whether or not rpcb_getport_done() gets called.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      381ba74a
    • O
      rpc: bring back cl_chatty · b6b6152c
      Olga Kornievskaia 提交于
      The cl_chatty flag alows us to control whether a given rpc client leaves
      
      	"server X not responding, timed out"
      
      messages in the syslog.  Such messages make sense for ordinary nfs
      clients (where an unresponsive server means applications on the
      mountpoint are probably hanging), but not for the callback client (which
      can fail more commonly, with the only result just of disabling some
      optimizations).
      
      Previously cl_chatty was removed, do to lack of users; reinstate it, and
      use it for the nfsd's callback client.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b6b6152c
    • C
      SUNRPC: Display some debugging information as text rather than numbers · cb3997b5
      Chuck Lever 提交于
      In rpc_show_tasks(), display the program name, version number, procedure
      name and tk_action as human-readable variable-length text fields rather
      than columnar numbers.
      
      Doing the symbol lookup here helps in cases where we have actual
      debugging output from a kernel log, but don't have access to the kernel
      image or RPC module that generated the output.
      
      Sample output:
      
       -pid- flgs status -client- --rqstp- -timeout ---ops--
        5608 0001    -11 eeb42690 f6d93710        0 f8fa1764 nfsv3 WRITE a:call_transmit_status q:none
        5609 0001    -11 eeb42690 f6d937e0        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5610 0001    -11 eeb42690 f6d93230        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5611 0001    -11 eeb42690 f6d93300        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5612 0001    -11 eeb42690 f6d93090        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5613 0001    -11 eeb42690 f6d933d0        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5614 0001    -11 eeb42690 f6d93cc0        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5615 0001    -11 eeb42690 f6d93a50        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5616 0001    -11 eeb42690 f6d93640        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5617 0001    -11 eeb42690 f6d93b20        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
        5618 0001    -11 eeb42690 f6d93160        0 f8fa1764 nfsv3 WRITE a:call_status q:xprt_sending
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      cb3997b5
    • C
      SUNRPC: Refactor rpc_show_tasks · 38e886e0
      Chuck Lever 提交于
      Clean up: move the logic that displays each task to its own function.
      This removes indentation and makes future changes easier.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      38e886e0
    • C
      SUNRPC: Don't display the rpc_show_tasks header if there are no tasks · 68a23ee9
      Chuck Lever 提交于
      Clean up: don't display the rpc_show_tasks column header unless there is at
      least one task to display.  As far as I can tell, it is safe to let the
      list_for_each_entry macro decide that each list is empty.
      
      scripts/checkpatch.pl also wants a KERN_FOO at the start of any newly added
      printk() calls, so this and subsequent patches will also add KERN_INFO.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      68a23ee9
    • C
      SUNRPC: Rename "call_" functions that are no longer FSM states · b0e1c57e
      Chuck Lever 提交于
      The RPC client uses a finite state machine to move RPC tasks through each
      step of an RPC request.  Each state is contained in a function in
      net/sunrpc/clnt.c, and named call_foo.
      
      Some of the functions named call_foo have changed over the past few years and
      are no longer states in the FSM.  These include: call_encode, call_header,
      and call_verify.  As a clean up, rename the functions that have changed.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b0e1c57e