similar to: [PATCH v2] vhost: add vsock compat ioctl

On Wed, Mar 14, 2018 at 10:26:05AM -0700, Sonny Rao wrote: > This will allow usage of vsock from 32-bit binaries on a 64-bit > kernel. > > Signed-off-by: Sonny Rao <sonnyrao at chromium.org> I think you need to convert the pointer argument though. Something along the lines of: #ifdef CONFIG_COMPAT static long vhost_vsock_dev_compat_ioctl(struct file *f, unsigned int ioctl,

On Fri, Jan 06, 2017 at 10:22:56AM +0800, Peng Tao wrote: > On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote: > > On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote: > >> Currently, if a connect call fails on a signal or timeout (e.g., guest is still > >> in the process of starting up), we'll just return to caller and leave

This is a note to let you know that I've just added the patch titled vsock/virtio: Initialize core virtio vsock before registering the driver to the 5.0-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vsock-virtio-initialize-core-virtio-vsock-before-registering-the-driver.patch and

This is a note to let you know that I've just added the patch titled vsock/virtio: Initialize core virtio vsock before registering the driver to the 5.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vsock-virtio-initialize-core-virtio-vsock-before-registering-the-driver.patch and

This is a note to let you know that I've just added the patch titled vsock/virtio: Initialize core virtio vsock before registering the driver to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vsock-virtio-initialize-core-virtio-vsock-before-registering-the-driver.patch and

This is a note to let you know that I've just added the patch titled vsock/virtio: Initialize core virtio vsock before registering the driver to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vsock-virtio-initialize-core-virtio-vsock-before-registering-the-driver.patch and

This is a note to let you know that I've just added the patch titled vsock/virtio: Initialize core virtio vsock before registering the driver to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vsock-virtio-initialize-core-virtio-vsock-before-registering-the-driver.patch and

From: Stefan Hajnoczi <stefanha at redhat.com> The vsock_diag_test program directly included ../../../include/uapi/ headers from the source tree. Tests are supposed to use the usr/include/linux/ headers that have been prepared with make headers_install instead. Suggested-by: David S. Miller <davem at davemloft.net> Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com>

On Wed, Mar 06, 2019 at 12:13:53PM +0200, Adalbert Laz?r wrote: > Previous to commit 22b5c0b63f32 ("vsock/virtio: fix kernel panic > after device hot-unplug"), vsock_core_init() was called from > virtio_vsock_probe(). Now, virtio_transport_reset_no_sock() can be called > before vsock_core_init() has the chance to run. > > [Wed Feb 27 14:17:09 2019] BUG: unable to

On Thu, Nov 21, 2019 at 09:34:58AM +0000, Stefan Hajnoczi wrote: > On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: > > Ideas for long-term changes below. > > Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> > Thanks for reviewing! > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 760049454a23..c2a3dc3113ba 100644 > > ---

From: Stefan Hajnoczi <stefanha at redhat.com> The vsock_test.c program runs a test suite of AF_VSOCK test cases. Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- v2: * Drop unnecessary includes [Stefan] * Aligned with the current SPDX [Stefano] * Set MULTICONN_NFDS to 100 [Stefano] * Change (i % 1) in (i

Hi Stefan, I'm thinking about dividing this test into single applications, one for each test, do you think it makes sense? Or is it just a useless complication? Thanks, Stefano On Thu, Aug 1, 2019 at 5:27 PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > From: Stefan Hajnoczi <stefanha at redhat.com> > > The vsock_test.c program runs a test suite of AF_VSOCK

Hi Stefan, I'm thinking about dividing this test into single applications, one for each test, do you think it makes sense? Or is it just a useless complication? Thanks, Stefano On Thu, Aug 1, 2019 at 5:27 PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > From: Stefan Hajnoczi <stefanha at redhat.com> > > The vsock_test.c program runs a test suite of AF_VSOCK

Stefan Hajnoczi <stefanha at redhat.com> writes: > From: Asias He <asias at redhat.com> > > Enable virtio-vsock and vhost-vsock. > > Signed-off-by: Asias He <asias at redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > --- > v3: > * Don't put vhost vsock driver into staging > * Add missing Kconfig dependencies (Arnd

Stefan Hajnoczi <stefanha at redhat.com> writes: > From: Asias He <asias at redhat.com> > > Enable virtio-vsock and vhost-vsock. > > Signed-off-by: Asias He <asias at redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > --- > v3: > * Don't put vhost vsock driver into staging > * Add missing Kconfig dependencies (Arnd

On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote: > Currently, if a connect call fails on a signal or timeout (e.g., guest is still > in the process of starting up), we'll just return to caller and leave the connect > packet queued and they are sent even though the connection is considered a failure, > which can confuse applications with unwanted false connect attempt. >

On Thu, May 16, 2019 at 01:51:07PM -0700, Jorge E. Moreira wrote: > Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are > accessed (while handling interrupts) before they are initialized. > > [ 4.201410] BUG: unable to handle kernel paging request at ffffffffffffffe8 > [ 4.207829] IP: vsock_addr_equals_addr+0x3/0x20 > [ 4.211379] PGD 28210067 P4D

On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote: > On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote: >> Currently, if a connect call fails on a signal or timeout (e.g., guest is still >> in the process of starting up), we'll just return to caller and leave the connect >> packet queued and they are sent even though the connection

On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote: > On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote: >> Currently, if a connect call fails on a signal or timeout (e.g., guest is still >> in the process of starting up), we'll just return to caller and leave the connect >> packet queued and they are sent even though the connection

Stefan Hajnoczi <stefanha at redhat.com> writes: > From: Asias He <asias at redhat.com> > > VM sockets virtio transport implementation. This module runs in guest > kernel. checkpatch warns on a bunch of whitespace/tab issues. > > Signed-off-by: Asias He <asias at redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > --- > v2: