1. 07 Aug, 2018 1 commit
    • Cong Wang's avatar
      vsock: split dwork to avoid reinitializations · 455f05ec
      Cong Wang authored
      syzbot reported that we reinitialize an active delayed
      work in vsock_stream_connect():
      	ODEBUG: init active (active state 0) object type: timer_list hint:
      	delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:1414
      	WARNING: CPU: 1 PID: 11518 at lib/debugobjects.c:329
      	debug_print_object+0x16a/0x210 lib/debugobjects.c:326
      The pattern is apparently wrong, we should only initialize
      the dealyed work once and could repeatly schedule it. So we
      have to move out the initializations to allocation side.
      And to avoid confusion, we can split the shared dwork
      into two, instead of re-using the same one.
      Fixes: d021c344 ("VSOCK: Introduce VM Sockets")
      Reported-by: <syzbot+8a9b1bd330476a4f3db6@syzkaller.appspotmail.com>
      Cc: Andy king <acking@vmware.com>
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Cc: Jorgen Hansen <jhansen@vmware.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 06 Oct, 2017 3 commits
  3. 24 Apr, 2017 1 commit
  4. 21 Mar, 2017 1 commit
  5. 01 Aug, 2016 3 commits
  6. 09 Dec, 2015 1 commit
  7. 03 Dec, 2015 1 commit
  8. 01 Nov, 2015 1 commit
    • Stefan Hajnoczi's avatar
      VSOCK: define VSOCK_SS_LISTEN once only · ea3803c1
      Stefan Hajnoczi authored
      The SS_LISTEN socket state is defined by both af_vsock.c and
      vmci_transport.c.  This is risky since the value could be changed in one
      file and the other would be out of sync.
      Rename from SS_LISTEN to VSOCK_SS_LISTEN since the constant is not part
      of enum socket_state (SS_CONNECTED, ...).  This way it is clear that the
      constant is vsock-specific.
      The big text reflow in af_vsock.c was necessary to keep to the maximum
      line length.  Text is unchanged except for s/SS_LISTEN/VSOCK_SS_LISTEN/.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  9. 11 May, 2015 1 commit
  10. 02 Mar, 2015 1 commit
  11. 24 Nov, 2014 1 commit
  12. 05 May, 2014 1 commit
  13. 28 Jul, 2013 1 commit
  14. 11 Feb, 2013 1 commit
    • Andy King's avatar
      VSOCK: Introduce VM Sockets · d021c344
      Andy King authored
      VM Sockets allows communication between virtual machines and the hypervisor.
      User level applications both in a virtual machine and on the host can use the
      VM Sockets API, which facilitates fast and efficient communication between
      guest virtual machines and their host.  A socket address family, designed to be
      compatible with UDP and TCP at the interface level, is provided.
      Today, VM Sockets is used by various VMware Tools components inside the guest
      for zero-config, network-less access to VMware host services.  In addition to
      this, VMware's users are using VM Sockets for various applications, where
      network access of the virtual machine is restricted or non-existent.  Examples
      of this are VMs communicating with device proxies for proprietary hardware
      running as host applications and automated testing of applications running
      within virtual machines.
      The VMware VM Sockets are similar to other socket types, like Berkeley UNIX
      socket interface.  The VM Sockets module supports both connection-oriented
      stream sockets like TCP, and connectionless datagram sockets like UDP. The VM
      Sockets protocol family is defined as "AF_VSOCK" and the socket operations
      split for SOCK_DGRAM and SOCK_STREAM.
      For additional information about the use of VM Sockets, please refer to the
      VM Sockets Programming Guide available at:
      https://www.vmware.com/support/developer/vmci-sdk/Signed-off-by: default avatarGeorge Zhang <georgezhang@vmware.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: default avatarAndy king <acking@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>