linux-toradex.git/net/vmw_vsock/af_vsock.c, branch v4.10

VSOCK: Don't dec ack backlog twice for rejected connections

2016-09-27T11:59:25+00:00

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

VSOCK: defer sock removal to transports

2016-08-01T23:57:28+00:00

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

VSOCK: transport-specific vsock_transport functions

2016-08-01T23:57:28+00:00

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

vsock: make listener child lock ordering explicit

2016-06-27T14:44:46+00:00

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

VSOCK: do not disconnect socket when peer has shutdown SEND only

2016-05-06T03:31:29+00:00

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

AF_VSOCK: Shrink the area influenced by prepare_to_wait

2016-03-22T20:18:41+00:00

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

Revert "vsock: Fix blocking ops call in prepare_to_wait"

2016-03-22T20:18:41+00:00

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

vsock: Fix blocking ops call in prepare_to_wait

2016-02-13T10:57:39+00:00

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

VSOCK: define VSOCK_SS_LISTEN once only

2015-11-01T17:14:47+00:00

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

vsock: fix missing cleanup when misc_register failed

2015-10-21T14:41:06+00:00

reset transport and unlock if misc_register failed.

Signed-off-by: Gao feng 
Signed-off-by: David S. Miller