<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-obmc-linux/net/vmw_vsock, branch v5.0.1</title>
<subtitle>Talos™ II Linux sources for OpenBMC</subtitle>
<id>https://git.raptorcs.com/git/talos-obmc-linux/atom?h=v5.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-obmc-linux/atom?h=v5.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/'/>
<updated>2019-02-09T06:32:05+00:00</updated>
<entry>
<title>vsock: cope with memory allocation failure at socket creation time</title>
<updated>2019-02-09T06:32:05+00:00</updated>
<author>
<name>Paolo Abeni</name>
<email>pabeni@redhat.com</email>
</author>
<published>2019-02-07T13:13:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=225d9464268599a5b4d094d02ec17808e44c7553'/>
<id>urn:sha1:225d9464268599a5b4d094d02ec17808e44c7553</id>
<content type='text'>
In the unlikely event that the kmalloc call in vmci_transport_socket_init()
fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
and oopsing.

This change addresses the above explicitly checking for zero vmci_trans()
at destruction time.

Reported-by: Xiumei Mu &lt;xmu@redhat.com&gt;
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Reviewed-by: Stefano Garzarella &lt;sgarzare@redhat.com&gt;
Reviewed-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>vsock/virtio: reset connected sockets on device removal</title>
<updated>2019-02-03T19:06:25+00:00</updated>
<author>
<name>Stefano Garzarella</name>
<email>sgarzare@redhat.com</email>
</author>
<published>2019-02-01T11:42:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=85965487abc540368393a15491e6e7fcd230039d'/>
<id>urn:sha1:85965487abc540368393a15491e6e7fcd230039d</id>
<content type='text'>
When the virtio transport device disappear, we should reset all
connected sockets in order to inform the users.

Signed-off-by: Stefano Garzarella &lt;sgarzare@redhat.com&gt;
Reviewed-by: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>vsock/virtio: fix kernel panic after device hot-unplug</title>
<updated>2019-02-03T19:06:25+00:00</updated>
<author>
<name>Stefano Garzarella</name>
<email>sgarzare@redhat.com</email>
</author>
<published>2019-02-01T11:42:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=22b5c0b63f32568e130fa2df4ba23efce3eb495b'/>
<id>urn:sha1:22b5c0b63f32568e130fa2df4ba23efce3eb495b</id>
<content type='text'>
virtio_vsock_remove() invokes the vsock_core_exit() also if there
are opened sockets for the AF_VSOCK protocol family. In this way
the vsock "transport" pointer is set to NULL, triggering the
kernel panic at the first socket activity.

This patch move the vsock_core_init()/vsock_core_exit() in the
virtio_vsock respectively in module_init and module_exit functions,
that cannot be invoked until there are open sockets.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1609699
Reported-by: Yan Fu &lt;yafu@redhat.com&gt;
Signed-off-by: Stefano Garzarella &lt;sgarzare@redhat.com&gt;
Acked-by: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>VSOCK: Send reset control packet when socket is partially bound</title>
<updated>2018-12-18T19:53:42+00:00</updated>
<author>
<name>Jorgen Hansen</name>
<email>jhansen@vmware.com</email>
</author>
<published>2018-12-18T08:34:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=a915b982d8f5e4295f64b8dd37ce753874867e88'/>
<id>urn:sha1:a915b982d8f5e4295f64b8dd37ce753874867e88</id>
<content type='text'>
If a server side socket is bound to an address, but not in the listening
state yet, incoming connection requests should receive a reset control
packet in response. However, the function used to send the reset
silently drops the reset packet if the sending socket isn't bound
to a remote address (as is the case for a bound socket not yet in
the listening state). This change fixes this by using the src
of the incoming packet as destination for the reset packet in
this case.

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Adit Ranadive &lt;aditr@vmware.com&gt;
Reviewed-by: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Signed-off-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>VSOCK: bind to random port for VMADDR_PORT_ANY</title>
<updated>2018-12-14T22:40:19+00:00</updated>
<author>
<name>Lepton Wu</name>
<email>ytht.net@gmail.com</email>
</author>
<published>2018-12-11T19:12:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=8236b08cf50f85bbfaf48910a0b3ee68318b7c4b'/>
<id>urn:sha1:8236b08cf50f85bbfaf48910a0b3ee68318b7c4b</id>
<content type='text'>
The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.

Signed-off-by: Lepton Wu &lt;ytht.net@gmail.com&gt;
Reviewed-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>vsock: split dwork to avoid reinitializations</title>
<updated>2018-08-07T19:39:13+00:00</updated>
<author>
<name>Cong Wang</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2018-08-06T18:06:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=455f05ecd2b219e9a216050796d30c830d9bc393'/>
<id>urn:sha1:455f05ecd2b219e9a216050796d30c830d9bc393</id>
<content type='text'>
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: d021c344051a ("VSOCK: Introduce VM Sockets")
Reported-by: &lt;syzbot+8a9b1bd330476a4f3db6@syzkaller.appspotmail.com&gt;
Cc: Andy king &lt;acking@vmware.com&gt;
Cc: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Cc: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Revert changes to convert to -&gt;poll_mask() and aio IOCB_CMD_POLL</title>
<updated>2018-06-28T17:40:47+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-06-28T16:43:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=a11e1d432b51f63ba698d044441284a661f01144'/>
<id>urn:sha1:a11e1d432b51f63ba698d044441284a661f01144</id>
<content type='text'>
The poll() changes were not well thought out, and completely
unexplained.  They also caused a huge performance regression, because
"-&gt;poll()" was no longer a trivial file operation that just called down
to the underlying file operations, but instead did at least two indirect
calls.

Indirect calls are sadly slow now with the Spectre mitigation, but the
performance problem could at least be largely mitigated by changing the
"-&gt;get_poll_head()" operation to just have a per-file-descriptor pointer
to the poll head instead.  That gets rid of one of the new indirections.

But that doesn't fix the new complexity that is completely unwarranted
for the regular case.  The (undocumented) reason for the poll() changes
was some alleged AIO poll race fixing, but we don't make the common case
slower and more complex for some uncommon special case, so this all
really needs way more explanations and most likely a fundamental
redesign.

[ This revert is a revert of about 30 different commits, not reverted
  individually because that would just be unnecessarily messy  - Linus ]

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>VSOCK: fix loopback on big-endian systems</title>
<updated>2018-06-22T00:34:08+00:00</updated>
<author>
<name>Claudio Imbrenda</name>
<email>imbrenda@linux.vnet.ibm.com</email>
</author>
<published>2018-06-20T13:51:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=e5ab564c9ebee77794842ca7d7476147b83d6a27'/>
<id>urn:sha1:e5ab564c9ebee77794842ca7d7476147b83d6a27</id>
<content type='text'>
The dst_cid and src_cid are 64 bits, therefore 64 bit accessors should be
used, and in fact in virtio_transport_common.c only 64 bit accessors are
used. Using 32 bit accessors for 64 bit values breaks big endian systems.

This patch fixes a wrong use of le32_to_cpu in virtio_transport_send_pkt.

Fixes: b9116823189e85ccf384 ("VSOCK: add loopback to virtio_transport")

Signed-off-by: Claudio Imbrenda &lt;imbrenda@linux.vnet.ibm.com&gt;
Reviewed-by: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/vmw_vsock: convert to -&gt;poll_mask</title>
<updated>2018-05-26T07:16:44+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2017-12-31T15:35:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=31f50b557318d787474a28c3e075f518cdcb5278'/>
<id>urn:sha1:31f50b557318d787474a28c3e075f518cdcb5278</id>
<content type='text'>
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>VSOCK: make af_vsock.ko removable again</title>
<updated>2018-04-17T13:44:30+00:00</updated>
<author>
<name>Stefan Hajnoczi</name>
<email>stefanha@redhat.com</email>
</author>
<published>2018-04-17T06:25:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=05e489b1596f0aa1025a1fa572676631cd9665da'/>
<id>urn:sha1:05e489b1596f0aa1025a1fa572676631cd9665da</id>
<content type='text'>
Commit c1eef220c1760762753b602c382127bfccee226d ("vsock: always call
vsock_init_tables()") introduced a module_init() function without a
corresponding module_exit() function.

Modules with an init function can only be removed if they also have an
exit function.  Therefore the vsock module was considered "permanent"
and could not be removed.

This patch adds an empty module_exit() function so that "rmmod vsock"
works.  No explicit cleanup is required because:

1. Transports call vsock_core_exit() upon exit and cannot be removed
   while sockets are still alive.
2. vsock_diag.ko does not perform any action that requires cleanup by
   vsock.ko.

Fixes: c1eef220c176 ("vsock: always call vsock_init_tables()")
Reported-by: Xiumei Mu &lt;xmu@redhat.com&gt;
Cc: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Cc: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Signed-off-by: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Reviewed-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
