similar to: [PATCH 0/4] virtio: console: fixes, SIGIO

Hey Rusty, This patchset is on top of the previous one. It sends a SIGIO signal to apps that request signals for host activity. SIGIO is sent on host connect, disconnect as well as hot-unplug (which can be seen as a special case of host disconnect). Tested using several testcases in the test-virtserial repo: http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Please apply.

Hey Rusty, This patchset is on top of the previous one. It sends a SIGIO signal to apps that request signals for host activity. SIGIO is sent on host connect, disconnect as well as hot-unplug (which can be seen as a special case of host disconnect). Tested using several testcases in the test-virtserial repo: http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Please apply.

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hi, Sorry for the late reply. On (Thu) 12 Jan 2012 [09:20:07], zanghongyong at huawei.com wrote: > From: Hongyong Zang <zanghongyong at huawei.com> > > Add setup_port_vq(). Create the io ports' vqs when add_port. Can you describe the changes in more detail, please? > Signed-off-by: Hongyong Zang <zanghongyong at huawei.com> > --- >

Hi, Sorry for the late reply. On (Thu) 12 Jan 2012 [09:20:07], zanghongyong at huawei.com wrote: > From: Hongyong Zang <zanghongyong at huawei.com> > > Add setup_port_vq(). Create the io ports' vqs when add_port. Can you describe the changes in more detail, please? > Signed-off-by: Hongyong Zang <zanghongyong at huawei.com> > --- >

On 07/19/2013 04:16 AM, Amit Shah wrote: > If a port gets unplugged while a user is blocked on read(), -ENODEV is > returned. However, subsequent read()s returned 0, indicating there's no > host-side connection (but not indicating the device went away). > > This also happened when a port was unplugged and the user didn't have > any blocking operation pending. If the

On 07/19/2013 04:16 AM, Amit Shah wrote: > If a port gets unplugged while a user is blocked on read(), -ENODEV is > returned. However, subsequent read()s returned 0, indicating there's no > host-side connection (but not indicating the device went away). > > This also happened when a port was unplugged and the user didn't have > any blocking operation pending. If the

SIGIO should be sent when a port gets unplugged. It should only be sent to prcesses that have the port opened, and have asked for SIGIO to be delivered. We were clearing out guest_connected before calling send_sigio_to_port(), resulting in a sigio not getting sent to processes. Fix by setting guest_connected to false after invoking the sigio function. CC: <stable at vger.kernel.org>

Hey Rusty, Here are a few fixes for virtio and virtio_console. The first patch ensures the data elements of vqs are properly initialised at allocation-time so that we don't trigger BUG_ONs. I found this when hot-unplugging ports and there was just one unused buffer. detach_unused_buffers() kept returning pointers that were invalid. I didn't catch this earlier as I had the in_vq filled

Hey Rusty, Here are a few fixes for virtio and virtio_console. The first patch ensures the data elements of vqs are properly initialised at allocation-time so that we don't trigger BUG_ONs. I found this when hot-unplugging ports and there was just one unused buffer. detach_unused_buffers() kept returning pointers that were invalid. I didn't catch this earlier as I had the in_vq filled

Hi folks, Today I noticed some strange behaviour when accessing a samba server (samba 3.0.25a) from windows: On our Debian fileserver I prepared a file testfile.txt being owned by user usera and group dpt-a. Then I "setfacl -m g:admins:rwx testfile.txt". User userb who is only in group admins, but not in dpt-a is thus permitted to access and change this file by its POSIX-ACL, which

When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\

When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\