search for: wait_for_completion_interruptible

Displaying 18 results from an estimated 18 matches for "wait_for_completion_interruptible".

2011 Apr 06
20
[RESEND][PATCH 00/22] Staging: hv: Cleanup storage drivers - Phase IV
The latest upstream merge changed struct block_device_operations: This merge got rid of blkvsc_media_changed and introduced the function blkvsc_check_events. This broke all the patches that were sent after the tree was closed the last time. This is a resend of this patch-set to account for this change in the kernel. More cleanup. In this patch-set we deal with the following issues: 1) While a
2011 Apr 06
20
[RESEND][PATCH 00/22] Staging: hv: Cleanup storage drivers - Phase IV
The latest upstream merge changed struct block_device_operations: This merge got rid of blkvsc_media_changed and introduced the function blkvsc_check_events. This broke all the patches that were sent after the tree was closed the last time. This is a resend of this patch-set to account for this change in the kernel. More cleanup. In this patch-set we deal with the following issues: 1) While a
2017 Jun 28
0
[PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.
...mic_helper_swap_state(struct drm_atomic_state *state, if (!commit) continue; - ret = wait_for_completion_timeout(&commit->hw_done, - 10*HZ); - if (ret == 0) - DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n", - crtc->base.id, crtc->name); + ret = wait_for_completion_interruptible(&commit->hw_done); drm_crtc_commit_put(commit); + + if (ret) + return ret; } } -- 2.11.0
2011 Mar 28
22
[PATCH 00/22] Staging: hv: Cleanup-storage-drivers-phase-III
This patch-set deals with some of the style isues in blkvsc_drv.c. We also get rid most of the "dead code" in this file: 1) Get rid of most of the forward declarations in this file. The only remaining forward declarations are to deal with circular dependencies. 2) Get rid of most of the dead code in the file. Some of the functions in this file are place holders - they
2011 Mar 28
22
[PATCH 00/22] Staging: hv: Cleanup-storage-drivers-phase-III
This patch-set deals with some of the style isues in blkvsc_drv.c. We also get rid most of the "dead code" in this file: 1) Get rid of most of the forward declarations in this file. The only remaining forward declarations are to deal with circular dependencies. 2) Get rid of most of the dead code in the file. Some of the functions in this file are place holders - they
2011 Apr 22
13
[RESEND] [PATCH 00/18] Staging: hv: Cleanup-storage-drivers-phase-III
This is a resend of a previously sent patch-set. This patch-set deals with some of the style isues in blkvsc_drv.c. We also get rid most of the "dead code" in this file: 1) Get rid of most of the forward declarations in this file. The only remaining forward declarations are to deal with circular dependencies. 2) Get rid of most of the dead code in the file. Some of the
2011 Apr 22
13
[RESEND] [PATCH 00/18] Staging: hv: Cleanup-storage-drivers-phase-III
This is a resend of a previously sent patch-set. This patch-set deals with some of the style isues in blkvsc_drv.c. We also get rid most of the "dead code" in this file: 1) Get rid of most of the forward declarations in this file. The only remaining forward declarations are to deal with circular dependencies. 2) Get rid of most of the dead code in the file. Some of the
2011 Apr 04
18
[PATCH 00/22] Staging: hv: Cleanup storage drivers - Phase IV
More cleanup. In this patch-set we deal with the following issues: 1) While a Linux guest on Hyper-V can be assigned removable media devices (DVD, floppy etc), these devices are not handled by the Hyper-V block driver. So, we cleanup all the dead code dealing with removable media devices. 2) There were multiple functions to retrieve information about the device. Since much of
2011 Apr 04
18
[PATCH 00/22] Staging: hv: Cleanup storage drivers - Phase IV
More cleanup. In this patch-set we deal with the following issues: 1) While a Linux guest on Hyper-V can be assigned removable media devices (DVD, floppy etc), these devices are not handled by the Hyper-V block driver. So, we cleanup all the dead code dealing with removable media devices. 2) There were multiple functions to retrieve information about the device. Since much of
2015 Dec 31
4
[PATCH RFC] vhost: basic device IOTLB support
...ding->iova = iova & PAGE_MASK; + pending->flags.type = VHOST_IOTLB_MISS; + + if (copy_to_user(vq->dev->iotlb_request, pending, + sizeof(struct vhost_iotlb_entry))) { + goto err; + } + + mutex_unlock(&vq->dev->iotlb_req_mutex); + + eventfd_signal(vq->iotlb_ctx, 1); + wait_for_completion_interruptible(c); + + mutex_lock(&vq->dev->iotlb_req_mutex); + entry = vq->dev->pending_request; + mutex_unlock(&vq->dev->iotlb_req_mutex); + + return entry; +err: + mutex_unlock(&vq->dev->iotlb_req_mutex); + return entry; +} + +static int translate_iotlb(struct vhost_virtqueu...
2015 Dec 31
4
[PATCH RFC] vhost: basic device IOTLB support
...ding->iova = iova & PAGE_MASK; + pending->flags.type = VHOST_IOTLB_MISS; + + if (copy_to_user(vq->dev->iotlb_request, pending, + sizeof(struct vhost_iotlb_entry))) { + goto err; + } + + mutex_unlock(&vq->dev->iotlb_req_mutex); + + eventfd_signal(vq->iotlb_ctx, 1); + wait_for_completion_interruptible(c); + + mutex_lock(&vq->dev->iotlb_req_mutex); + entry = vq->dev->pending_request; + mutex_unlock(&vq->dev->iotlb_req_mutex); + + return entry; +err: + mutex_unlock(&vq->dev->iotlb_req_mutex); + return entry; +} + +static int translate_iotlb(struct vhost_virtqueu...
2015 Dec 31
0
[PATCH RFC] vhost: basic device IOTLB support
...t;flags.type = VHOST_IOTLB_MISS; > + > + if (copy_to_user(vq->dev->iotlb_request, pending, > + sizeof(struct vhost_iotlb_entry))) { > + goto err; > + } > + > + mutex_unlock(&vq->dev->iotlb_req_mutex); > + > + eventfd_signal(vq->iotlb_ctx, 1); > + wait_for_completion_interruptible(c); This can still be under vq lock, can it not? Looks like this can cause deadlocks. > + > + mutex_lock(&vq->dev->iotlb_req_mutex); > + entry = vq->dev->pending_request; > + mutex_unlock(&vq->dev->iotlb_req_mutex); > + > + return entry; > +err: >...
2017 Jun 28
5
[PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.
We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. All drivers have changes to deal with the clean up. In order to allow easy reverting, the commit that changes behavior is separate so someone only has to revert that for testing. Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
2009 Jul 03
1
[RFC PATCH v3] virito-serial: A guest <-> host interface
Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.
2009 Jul 03
1
[RFC PATCH v3] virito-serial: A guest <-> host interface
Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.
2009 Jul 27
3
virtio-serial: An interface for host-guest communication
Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this
2009 Jul 27
3
virtio-serial: An interface for host-guest communication
Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this
2006 Jul 18
33
Paravirtualised drivers for fully virtualised domains
(The list appears to have eaten my previous attempt to send this. Apologies if you receive multiple copies.) The attached patches allow you to use paravirtualised network and block interfaces from fully virtualised domains, based on Intel''s patches from a few months ago. These are significantly faster than the equivalent ioemu devices, sometimes by more than an order of magnitude.