1. 04 8月, 2010 2 次提交
  2. 15 5月, 2010 5 次提交
  3. 22 3月, 2010 1 次提交
  4. 10 2月, 2010 1 次提交
    • J
      sunrpc: parse and return errors reported by gssd · dc5ddce9
      Jeff Layton 提交于
      The kernel currently ignores any error code sent by gssd and always
      considers it to be -EACCES. In order to better handle the situation of
      an expired KRB5 TGT, the kernel needs to be able to parse and deal with
      the errors that gssd sends. Aside from -EACCES the only error we care
      about is -EKEYEXPIRED, which we're using to indicate that the upper
      layers should retry the call a little later.
      
      To maintain backward compatibility with older gssd's, any error other
      than -EKEYEXPIRED is interpreted as -EACCES.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      dc5ddce9
  5. 07 1月, 2010 1 次提交
  6. 19 12月, 2009 1 次提交
    • J
      sunrpc: on successful gss error pipe write, don't return error · 486bad2e
      Jeff Layton 提交于
      When handling the gssd downcall, the kernel should distinguish between a
      successful downcall that contains an error code and a failed downcall
      (i.e. where the parsing failed or some other sort of problem occurred).
      
      In the former case, gss_pipe_downcall should be returning the number of
      bytes written to the pipe instead of an error. In the event of other
      errors, we generally want the initiating task to retry the upcall so
      we set msg.errno to -EAGAIN. An unexpected error code here is a bug
      however, so BUG() in that case.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      486bad2e
  7. 10 12月, 2009 1 次提交
  8. 09 12月, 2009 1 次提交
  9. 10 8月, 2009 2 次提交
  10. 10 6月, 2009 1 次提交
  11. 24 12月, 2008 11 次提交
  12. 10 7月, 2008 3 次提交
  13. 12 6月, 2008 1 次提交
  14. 20 4月, 2008 5 次提交
  15. 15 3月, 2008 1 次提交
  16. 06 3月, 2008 1 次提交
  17. 29 2月, 2008 1 次提交
  18. 26 2月, 2008 1 次提交
    • T
      SUNRPC: Run rpc timeout functions as callbacks instead of in softirqs · 5d00837b
      Trond Myklebust 提交于
      An audit of the current RPC timeout functions shows that they don't really
      ever need to run in the softirq context. As long as the softirq is
      able to signal that the wakeup is due to a timeout (which it can do by
      setting task->tk_status to -ETIMEDOUT) then the callback functions can just
      run as standard task->tk_callback functions (in the rpciod/process
      context).
      
      The only possible border-line case would be xprt_timer() for the case of
      UDP, when the callback is used to reduce the size of the transport
      congestion window. In testing, however, the effect of moving that update
      to a callback would appear to be minor.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      5d00837b