Fix deadlock when using Client + Service over io.Pipe

Client + Server might deadlock while being connected via io.Pipe with
high request concurrency. The scenario is as follows:

  - Server is trying to send reply to a previous client's packet and is
    waiting on Pipe's condvar for the client to read it:

 3  0x0000000000460e39 in sync.(*Cond).Wait
    at /usr/lib/go/src/sync/cond.go:57
 4  0x0000000000464519 in io.(*pipe).write
    at /usr/lib/go/src/io/pipe.go:90
 5  0x0000000000464a4c in io.(*PipeWriter).Write
    at /usr/lib/go/src/io/pipe.go:157
 6  0x00000000007a0b66 in go.(*struct { io.Reader; io.WriteCloser }).Write
    at <autogenerated>:246
 7  0x0000000000790cf6 in github.com/pkg/sftp.(*conn).Write
    at <autogenerated>:3
 8  0x000000000073a68d in github.com/pkg/sftp.sendPacket
    at ./packet.go:130
 9  0x000000000073338c in github.com/pkg/sftp.(*conn).sendPacket
    at ./conn.go:31
10  0x00000000007374b4 in github.com/pkg/sftp.(*packetManager).maybeSendPackets
    at ./packet-manager.go:87

  - Client is sending a new packet and is waiting on Pipe's condvar for
    the server to read it, while holding clientConn mutex:

 5  0x0000000000464a4c in io.(*PipeWriter).Write
    at /usr/lib/go/src/io/pipe.go:157
 6  0x0000000000790cf6 in github.com/pkg/sftp.(*conn).Write
    at <autogenerated>:3
 7  0x000000000073a68d in github.com/pkg/sftp.sendPacket
    at ./packet.go:130
 8  0x000000000073338c in github.com/pkg/sftp.(*conn).sendPacket
    at ./conn.go:31
 9  0x0000000000733bfb in github.com/pkg/sftp.(*clientConn).dispatchRequest
    at ./conn.go:105
10  0x0000000000733a0b in github.com/pkg/sftp.(*clientConn).sendPacket
    at ./conn.go:97

  - Client's receive loop is processing a reply from the server and is
    trying to acquire clientConn mutex:

4  0x000000000046108d in sync.(*Mutex).Lock
   at /usr/lib/go/src/sync/mutex.go:87
5  0x00000000007336cb in github.com/pkg/sftp.(*clientConn).recv
   at ./conn.go:69
6  0x000000000073350d in github.com/pkg/sftp.(*clientConn).loop
   at ./conn.go:49
7  0x000000000045ab51 in runtime.goexit
   at /usr/lib/go/src/runtime/asm_amd64.s:2197

In this scenario neither server nor client can progress. Fix this by
releasing clienConn mutex *before* trying to send the packet.

Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
1 file changed
tree: 76dfc475ee5640e770c9883dbaf75d2ada5e3afe
  1. examples/
  2. server_standalone/
  3. .gitignore
  4. .travis.yml
  5. attrs.go
  6. attrs_stubs.go
  7. attrs_test.go
  8. attrs_unix.go
  9. client.go
  10. client_integration_darwin_test.go
  11. client_integration_linux_test.go
  12. client_integration_test.go
  13. client_test.go
  14. conn.go
  15. CONTRIBUTORS
  16. debug.go
  17. example_test.go
  18. LICENSE
  19. match.go
  20. other_test.go
  21. packet-manager.go
  22. packet-manager_go1.8.go
  23. packet-manager_legacy.go
  24. packet-manager_test.go
  25. packet-typing.go
  26. packet.go
  27. packet_test.go
  28. README.md
  29. release.go
  30. request-example.go
  31. request-interfaces.go
  32. request-readme.md
  33. request-server.go
  34. request-server_test.go
  35. request-unix.go
  36. request.go
  37. request_test.go
  38. request_windows.go
  39. server.go
  40. server_integration_test.go
  41. server_statvfs_darwin.go
  42. server_statvfs_impl.go
  43. server_statvfs_linux.go
  44. server_statvfs_stubs.go
  45. server_stubs.go
  46. server_test.go
  47. server_unix.go
  48. sftp.go
README.md

sftp

The sftp package provides support for file system operations on remote ssh servers using the SFTP subsystem. It also implements an SFTP server for serving files from the filesystem.

UNIX Build Status GoDoc

usage and examples

See godoc.org/github.com/pkg/sftp for examples and usage.

The basic operation of the package mirrors the facilities of the os package.

The Walker interface for directory traversal is heavily inspired by Keith Rarick's fs package.

roadmap

  • There is way too much duplication in the Client methods. If there was an unmarshal(interface{}) method this would reduce a heap of the duplication.

contributing

We welcome pull requests, bug fixes and issue reports.

Before proposing a large change, first please discuss your change by raising an issue.

For API/code bugs, please include a small, self contained code example to reproduce the issue. For pull requests, remember test coverage.

We handle issues and pull requests with a 0 open philosophy. That means we will try to address the submission as soon as possible and will work toward a resolution. If progress can no longer be made (eg. unreproducible bug) or stops (eg. unresponsive submitter), we will close the bug.

Please remember that we don't have infinite time and so it is a good guideline that the less time it takes us to work with you on your idea/issue the greater the chance we will have the time to do it.

Thanks.