“1fa7b51e0a1f5a9fe26b0bf78048f7ee65de84c8”上不存在“projects/shanmo/imports.yml”
  1. 10 12月, 2014 2 次提交
  2. 02 12月, 2014 1 次提交
  3. 25 11月, 2014 1 次提交
  4. 29 8月, 2014 1 次提交
    • J
      SUNRPC: Fix compile on non-x86 · ae89254d
      J. Bruce Fields 提交于
      current_task appears to be x86-only, oops.
      
      Let's just delete this check entirely:
      
      Any developer that adds a new user without setting rq_task will get a
      crash the first time they test it.  I also don't think there are
      normally any important locks held here, and I can't see any other reason
      why killing a server thread would bring the whole box down.
      
      So the effort to fail gracefully here looks like overkill.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Fixes: 983c6844 "SUNRPC: get rid of the request wait queue"
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ae89254d
  5. 18 8月, 2014 5 次提交
  6. 30 7月, 2014 2 次提交
  7. 31 5月, 2014 1 次提交
  8. 23 5月, 2014 2 次提交
  9. 28 3月, 2014 1 次提交
  10. 10 2月, 2014 1 次提交
  11. 17 2月, 2013 2 次提交
  12. 24 1月, 2013 1 次提交
  13. 05 11月, 2012 3 次提交
  14. 22 8月, 2012 7 次提交
  15. 21 8月, 2012 2 次提交
    • J
      svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping · d10f27a7
      J. Bruce Fields 提交于
      The rpc server tries to ensure that there will be room to send a reply
      before it receives a request.
      
      It does this by tracking, in xpt_reserved, an upper bound on the total
      size of the replies that is has already committed to for the socket.
      
      Currently it is adding in the estimate for a new reply *before* it
      checks whether there is space available.  If it finds that there is not
      space, it then subtracts the estimate back out.
      
      This may lead the subsequent svc_xprt_enqueue to decide that there is
      space after all.
      
      The results is a svc_recv() that will repeatedly return -EAGAIN, causing
      server threads to loop without doing any actual work.
      
      Cc: stable@vger.kernel.org
      Reported-by: NMichael Tokarev <mjt@tls.msk.ru>
      Tested-by: NMichael Tokarev <mjt@tls.msk.ru>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d10f27a7
    • J
      svcrpc: sends on closed socket should stop immediately · f06f00a2
      J. Bruce Fields 提交于
      svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply.
      However, the XPT_CLOSE won't be acted on immediately.  Meanwhile other
      threads could send further replies before the socket is really shut
      down.  This can manifest as data corruption: for example, if a truncated
      read reply is followed by another rpc reply, that second reply will look
      to the client like further read data.
      
      Symptoms were data corruption preceded by svc_tcp_sendto logging
      something like
      
      	kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket
      
      Cc: stable@vger.kernel.org
      Reported-by: NMalahal Naineni <malahal@us.ibm.com>
      Tested-by: NMalahal Naineni <malahal@us.ibm.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f06f00a2
  16. 01 6月, 2012 2 次提交
  17. 16 5月, 2012 1 次提交
  18. 15 2月, 2012 3 次提交
  19. 01 2月, 2012 1 次提交
  20. 12 12月, 2011 1 次提交