09 Jan, 2017

1 commit


27 Sep, 2016

1 commit

  • If a pending socket is marked as rejected, we will decrease the
    sk_ack_backlog twice. So don't decrement it for rejected sockets
    in vsock_pending_work().

    Testing of the rejected socket path was done through code
    modifications.

    Reported-by: Stefan Hajnoczi
    Signed-off-by: Jorgen Hansen
    Reviewed-by: Adit Ranadive
    Reviewed-by: Aditya Sarwade
    Signed-off-by: David S. Miller

    Jorgen Hansen
     

15 Aug, 2016

1 commit

  • Remove unnecessary use of enable/disable callback notifications
    and the incorrect more space available check.

    The virtio_transport_tx_work handles when the TX virtqueue
    has more buffers available.

    Signed-off-by: Gerard Garcia
    Acked-by: Stefan Hajnoczi
    Signed-off-by: Michael S. Tsirkin

    Gerard Garcia
     

02 Aug, 2016

5 commits

  • Enable virtio-vsock and vhost-vsock.

    Signed-off-by: Asias He
    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: Michael S. Tsirkin

    Asias He
     
  • VM sockets virtio transport implementation. This driver runs in the
    guest.

    Signed-off-by: Asias He
    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: Michael S. Tsirkin

    Asias He
     
  • This module contains the common code and header files for the following
    virtio_transporto and vhost_vsock kernel modules.

    Signed-off-by: Asias He
    Signed-off-by: Claudio Imbrenda
    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: Michael S. Tsirkin

    Asias He
     
  • The virtio transport will implement graceful shutdown and the related
    SO_LINGER socket option. This requires orphaning the sock but keeping
    it in the table of connections after .release().

    This patch adds the vsock_remove_sock() function and leaves it up to the
    transport when to remove the sock.

    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: Michael S. Tsirkin

    Stefan Hajnoczi
     
  • struct vsock_transport contains function pointers called by AF_VSOCK
    core code. The transport may want its own transport-specific function
    pointers and they can be added after struct vsock_transport.

    Allow the transport to fetch vsock_transport. It can downcast it to
    access transport-specific function pointers.

    The virtio transport will use this.

    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: Michael S. Tsirkin

    Stefan Hajnoczi
     

27 Jun, 2016

1 commit

  • There are several places where the listener and pending or accept queue
    child sockets are accessed at the same time. Lockdep is unhappy that
    two locks from the same class are held.

    Tell lockdep that it is safe and document the lock ordering.

    Originally Claudio Imbrenda sent a similar
    patch asking whether this is safe. I have audited the code and also
    covered the vsock_pending_work() function.

    Suggested-by: Claudio Imbrenda
    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: David S. Miller

    Stefan Hajnoczi
     

10 May, 2016

1 commit


06 May, 2016

1 commit

  • The peer may be expecting a reply having sent a request and then done a
    shutdown(SHUT_WR), so tearing down the whole socket at this point seems
    wrong and breaks for me with a client which does a SHUT_WR.

    Looking at other socket family's stream_recvmsg callbacks doing a shutdown
    here does not seem to be the norm and removing it does not seem to have
    had any adverse effects that I can see.

    I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
    on the vmci transport.

    Signed-off-by: Ian Campbell
    Cc: "David S. Miller"
    Cc: Stefan Hajnoczi
    Cc: Claudio Imbrenda
    Cc: Andy King
    Cc: Dmitry Torokhov
    Cc: Jorgen Hansen
    Cc: Adit Ranadive
    Cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller

    Ian Campbell
     

04 May, 2016

1 commit


20 Apr, 2016

1 commit


07 Apr, 2016

1 commit

  • The check in vmci_transport_peer_detach_cb should only allow a
    detach when the qp handle of the transport matches the one in
    the detach message.

    Testing: Before this change, a detach from a peer on a different
    socket would cause an active stream socket to register a detach.

    Reviewed-by: George Zhang
    Signed-off-by: Jorgen Hansen
    Signed-off-by: David S. Miller

    Jorgen Hansen
     

23 Mar, 2016

2 commits

  • When a thread is prepared for waiting by calling prepare_to_wait, sleeping
    is not allowed until either the wait has taken place or finish_wait has
    been called. The existing code in af_vsock imposed unnecessary no-sleep
    assumptions to a broad list of backend functions.
    This patch shrinks the influence of prepare_to_wait to the area where it
    is strictly needed, therefore relaxing the no-sleep restriction there.

    Signed-off-by: Claudio Imbrenda
    Signed-off-by: David S. Miller

    Claudio Imbrenda
     
  • This reverts commit 5988818008257ca42010d6b43a3e0e48afec9898 ("vsock: Fix
    blocking ops call in prepare_to_wait")

    The commit reverted with this patch caused us to potentially miss wakeups.
    Since the condition is not checked between the prepare_to_wait and the
    schedule(), if a wakeup happens after the condition is checked but before
    the sleep happens, we will miss it. ( A description of the problem can be
    found here: http://www.makelinux.net/ldd3/chp-6-sect-2 ).

    By reverting the patch, the behaviour is still incorrect (since we
    shouldn't sleep between the prepare_to_wait and the schedule) but at least
    it will not miss wakeups.

    The next patch in the series actually fixes the behaviour.

    Signed-off-by: Claudio Imbrenda
    Signed-off-by: David S. Miller

    Claudio Imbrenda
     

13 Feb, 2016

1 commit

  • We receoved a bug report from someone using vmware:

    WARNING: CPU: 3 PID: 660 at kernel/sched/core.c:7389
    __might_sleep+0x7d/0x90()
    do not call blocking ops when !TASK_RUNNING; state=1 set at
    [] prepare_to_wait+0x2d/0x90
    Modules linked in: vmw_vsock_vmci_transport vsock snd_seq_midi
    snd_seq_midi_event snd_ens1371 iosf_mbi gameport snd_rawmidi
    snd_ac97_codec ac97_bus snd_seq coretemp snd_seq_device snd_pcm
    snd_timer snd soundcore ppdev crct10dif_pclmul crc32_pclmul
    ghash_clmulni_intel vmw_vmci vmw_balloon i2c_piix4 shpchp parport_pc
    parport acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc btrfs
    xor raid6_pq 8021q garp stp llc mrp crc32c_intel serio_raw mptspi vmwgfx
    drm_kms_helper ttm drm scsi_transport_spi mptscsih e1000 ata_generic
    mptbase pata_acpi
    CPU: 3 PID: 660 Comm: vmtoolsd Not tainted
    4.2.0-0.rc1.git3.1.fc23.x86_64 #1
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
    Reference Platform, BIOS 6.00 05/20/2014
    0000000000000000 0000000049e617f3 ffff88006ac37ac8 ffffffff818641f5
    0000000000000000 ffff88006ac37b20 ffff88006ac37b08 ffffffff810ab446
    ffff880068009f40 ffffffff81c63bc0 0000000000000061 0000000000000000
    Call Trace:
    [] dump_stack+0x4c/0x65
    [] warn_slowpath_common+0x86/0xc0
    [] warn_slowpath_fmt+0x55/0x70
    [] ? debug_lockdep_rcu_enabled+0x1d/0x20
    [] ? prepare_to_wait+0x2d/0x90
    [] ? prepare_to_wait+0x2d/0x90
    [] __might_sleep+0x7d/0x90
    [] __might_fault+0x43/0xa0
    [] copy_from_iter+0x87/0x2a0
    [] __qp_memcpy_to_queue+0x9a/0x1b0 [vmw_vmci]
    [] ? qp_memcpy_to_queue+0x20/0x20 [vmw_vmci]
    [] qp_memcpy_to_queue_iov+0x17/0x20 [vmw_vmci]
    [] qp_enqueue_locked+0xa0/0x140 [vmw_vmci]
    [] vmci_qpair_enquev+0x4f/0xd0 [vmw_vmci]
    [] vmci_transport_stream_enqueue+0x1b/0x20
    [vmw_vsock_vmci_transport]
    [] vsock_stream_sendmsg+0x2c5/0x320 [vsock]
    [] ? wake_atomic_t_function+0x70/0x70
    [] sock_sendmsg+0x38/0x50
    [] SYSC_sendto+0x104/0x190
    [] ? vfs_read+0x8a/0x140
    [] SyS_sendto+0xe/0x10
    [] entry_SYSCALL_64_fastpath+0x12/0x76

    transport->stream_enqueue may call copy_to_user so it should
    not be called inside a prepare_to_wait. Narrow the scope of
    the prepare_to_wait to avoid the bad call. This also applies
    to vsock_stream_recvmsg as well.

    Reported-by: Vinson Lee
    Tested-by: Vinson Lee
    Signed-off-by: Laura Abbott
    Signed-off-by: David S. Miller

    Laura Abbott
     

09 Dec, 2015

1 commit

  • This reverts commit 0d76d6e8b2507983a2cae4c09880798079007421 and merge
    commit c402293bd76fbc93e52ef8c0947ab81eea3ae019, reversing changes made
    to c89359a42e2a49656451569c382eed63e781153c.

    The virtio-vsock device specification is not finalized yet. Michael
    Tsirkin voiced concerned about merging this code when the hardware
    interface (and possibly the userspace interface) could still change.

    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: David S. Miller

    Stefan Hajnoczi
     

04 Dec, 2015

4 commits


24 Nov, 2015

1 commit


05 Nov, 2015

1 commit

  • When a listen socket enqueues a connection for userspace to accept(),
    the sk->sk_data_ready() callback should be invoked. In-kernel socket
    users rely on this callback to detect when incoming connections are
    available.

    Currently the sk->sk_state_change() callback is invoked by
    vmci_transport.c. This happens to work for userspace applications since
    sk->sk_state_change = sock_def_wakeup() and sk->sk_data_ready =
    sock_def_readable() both wake up the accept() waiter. In-kernel socket
    users, on the other hand, fail to detect incoming connections.

    Signed-off-by: Stefan Hajnoczi
    Signed-off-by: David S. Miller

    Stefan Hajnoczi
     

02 Nov, 2015

1 commit

  • 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: Stefan Hajnoczi
    Signed-off-by: David S. Miller

    Stefan Hajnoczi
     

23 Oct, 2015

1 commit

  • The recent fix for the vsock sock_put issue used the wrong
    initializer for the transport spin_lock causing an issue when
    running with lockdep checking.

    Testing: Verified fix on kernel with lockdep enabled.

    Reviewed-by: Thomas Hellstrom
    Signed-off-by: Jorgen Hansen
    Signed-off-by: David S. Miller

    Jorgen Hansen
     

22 Oct, 2015

1 commit

  • In the vsock vmci_transport driver, sock_put wasn't safe to call
    in interrupt context, since that may call the vsock destructor
    which in turn calls several functions that should only be called
    from process context. This change defers the callling of these
    functions to a worker thread. All these functions were
    deallocation of resources related to the transport itself.

    Furthermore, an unused callback was removed to simplify the
    cleanup.

    Multiple customers have been hitting this issue when using
    VMware tools on vSphere 2015.

    Also added a version to the vmci transport module (starting from
    1.0.2.0-k since up until now it appears that this module was
    sharing version with vsock that is currently at 1.0.1.0-k).

    Reviewed-by: Aditya Asarwade
    Reviewed-by: Thomas Hellstrom
    Signed-off-by: Jorgen Hansen
    Signed-off-by: David S. Miller

    Jorgen Hansen
     

21 Oct, 2015

1 commit


11 May, 2015

1 commit


03 Mar, 2015

1 commit

  • After TIPC doesn't depend on iocb argument in its internal
    implementations of sendmsg() and recvmsg() hooks defined in proto
    structure, no any user is using iocb argument in them at all now.
    Then we can drop the redundant iocb argument completely from kinds of
    implementations of both sendmsg() and recvmsg() in the entire
    networking stack.

    Cc: Christoph Hellwig
    Suggested-by: Al Viro
    Signed-off-by: Ying Xue
    Signed-off-by: David S. Miller

    Ying Xue
     

04 Feb, 2015

1 commit


10 Dec, 2014

2 commits


24 Nov, 2014

1 commit


06 Nov, 2014

1 commit

  • This encapsulates all of the skb_copy_datagram_iovec() callers
    with call argument signature "skb, offset, msghdr->msg_iov, length".

    When we move to iov_iters in the networking, the iov_iter object will
    sit in the msghdr.

    Having a helper like this means there will be less places to touch
    during that transformation.

    Based upon descriptions and patch from Al Viro.

    Signed-off-by: David S. Miller

    David S. Miller
     

06 May, 2014

1 commit

  • Right now the core vsock module is the owner of the proto family. This
    means there's nothing preventing the transport module from unloading if
    there are open sockets, which results in a panic. Fix that by allowing
    the transport to be the owner, which will refcount it properly.

    Includes version bump to 1.0.1.0-k

    Passes checkpatch this time, I swear...

    Acked-by: Dmitry Torokhov
    Signed-off-by: Andy King
    Signed-off-by: David S. Miller

    Andy King
     

12 Apr, 2014

1 commit

  • Several spots in the kernel perform a sequence like:

    skb_queue_tail(&sk->s_receive_queue, skb);
    sk->sk_data_ready(sk, skb->len);

    But at the moment we place the SKB onto the socket receive queue it
    can be consumed and freed up. So this skb->len access is potentially
    to freed up memory.

    Furthermore, the skb->len can be modified by the consumer so it is
    possible that the value isn't accurate.

    And finally, no actual implementation of this callback actually uses
    the length argument. And since nobody actually cared about it's
    value, lots of call sites pass arbitrary values in such as '0' and
    even '1'.

    So just remove the length argument from the callback, that way there
    is no confusion whatsoever and all of these use-after-free cases get
    fixed as a side effect.

    Based upon a patch by Eric Dumazet and his suggestion to audit this
    issue tree-wide.

    Signed-off-by: David S. Miller

    David S. Miller
     

19 Jan, 2014

1 commit

  • This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
    handler msg_name and msg_namelen logic").

    DECLARE_SOCKADDR validates that the structure we use for writing the
    name information to is not larger than the buffer which is reserved
    for msg->msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
    consistently in sendmsg code paths.

    Signed-off-by: Steffen Hurrle
    Suggested-by: Hannes Frederic Sowa
    Acked-by: Hannes Frederic Sowa
    Signed-off-by: David S. Miller

    Steffen Hurrle
     

21 Nov, 2013

1 commit


14 Oct, 2013

1 commit