similar to: [PATCH 1/1] virtio: console: replace EMFILE with EBUSY for already-open port

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This reverts commit 8078db789a92b10ff6e2d713231b5367e014c53b. The reverted patch caused opening of ports to fail for rproc_serial. In probe guest_connected was set to true, but port_fops_open() fails with -EMFILE if guest_connected already is true. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> --- Hi

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This reverts commit 8078db789a92b10ff6e2d713231b5367e014c53b. The reverted patch caused opening of ports to fail for rproc_serial. In probe guest_connected was set to true, but port_fops_open() fails with -EMFILE if guest_connected already is true. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> --- Hi

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

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

Amit Shah <amit.shah at redhat.com> writes: > Mateusz Guzik points out that we update the 'file' struct's private_data > field before we've successfully done all our checks. This means we can > return an error with the private_data field updated. This could lead to > problems. > > Fix by moving the assignment after all checks are done. No, this is a bit

Amit Shah <amit.shah at redhat.com> writes: > Mateusz Guzik points out that we update the 'file' struct's private_data > field before we've successfully done all our checks. This means we can > return an error with the private_data field updated. This could lead to > problems. > > Fix by moving the assignment after all checks are done. No, this is a bit

Mateusz Guzik points out that we update the 'file' struct's private_data field before we've successfully done all our checks. This means we can return an error with the private_data field updated. This could lead to problems. Fix by moving the assignment after all checks are done. CC: <stable at vger.kernel.org> Reported-by: Mateusz Guzik <mguzik at redhat.com>

My application runs a backgrond process and after running for a while I get this error in my logs: #<Errno::EMFILE: Too many open files Lasty, the ONLY code I have that does anything with files is: File.open(image_path, "wb") do |file| file.puts file_content end Any idea what this means? -- Posted via http://www.ruby-forum.com/.

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

I have a periodically_call_remote call in a partial running at 0.20 times a second. <%= periodically_call_remote(:update => ''ack_distance_output'', :frequency => 0.2, :url=>{:action => :ackAdjustDistance}) %> the action looks like this def ackAdjustDistance @calMessage = Calibration.getMessage

Amit Shah <amit.shah at redhat.com> writes: > There's a window between find_port_by_devt() returning a port and us > taking a kref on the port, where the port could get unplugged. Fix it > by taking the reference in find_port_by_devt() itself. > > Problem reported and analyzed by Mateusz Guzik. This fix is clearly correct, but what about the other find_port_by_*

Amit Shah <amit.shah at redhat.com> writes: > There's a window between find_port_by_devt() returning a port and us > taking a kref on the port, where the port could get unplugged. Fix it > by taking the reference in find_port_by_devt() itself. > > Problem reported and analyzed by Mateusz Guzik. This fix is clearly correct, but what about the other find_port_by_*

The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") deffered detaching of unused buffer to virtio device unplug time. This causes unplug/replug of single port in virtio device with an error "Error allocating inbufs\n". As we don't free the unused buffers attached with the port. Re-plug the same port tries to allocate new buffers in virtqueue

The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") deffered detaching of unused buffer to virtio device unplug time. This causes unplug/replug of single port in virtio device with an error "Error allocating inbufs\n". As we don't free the unused buffers attached with the port. Re-plug the same port tries to allocate new buffers in virtqueue

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