fio-ccw fixes for kernel stacktraces

The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we:
- wait for any interrupts
- flush all I/O in the workqueue
- retry cio_cancel_halt_clear

During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever.

Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device.

Suggested-by Eric Farman <[email protected]>

Signed-off-by Farhan Ali <[email protected]>

---
 drivers/s390/cio/vfio_ccw_drv.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

drivers/s390/cio/vfio_ccw_drv.c +1 -7

index 5aca475..4405f2a 100644
@@ -43,26 +43,23 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
 	if (ret != -EBUSY)
 		goto out_unlock;
 
+	iretry = 255;
 	do {
-		iretry = 255;
 
 		ret = cio_cancel_halt_clear(sch, &iretry);
-		while (ret == -EBUSY) {
-			/*
-			 * Flush all I/O and wait for
-			 * cancel/halt/clear completion.
-			 */
-			private->completion = &completion;

drivers/s390/cio/vfio_ccw_drv.c +3 -6

 			wait_for_completion_timeout(&completion, 3*HZ);
 
-			private->completion = NULL;
-			flush_workqueue(vfio_ccw_work_q);
-			spin_lock_irq(sch->lock);
-			ret = cio_cancel_halt_clear(sch, &iretry);
-		};
-
+		private->completion = NULL;
+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
 		ret = cio_disable_subchannel(sch);
 	} while (ret == -EBUSY);
 out_unlock:

When releasing the vfio-ccw mdev, we currently do not release any existing channel program and it's pinned pages. This can

lead to the following warning:

[1038876.561565] WARNING: CPU: 2 PID: 144727 at drivers/vfio/vfio_iommu_type1.c:1494 vfio_sanity_check_pfn_list+0x40/0x70 [vfio_iommu_type1]

....

1038876.561921] Call Trace:

[1038876.561935] ([<00000009897fb870>] 0x9897fb870)
[1038876.561949]  [<000003ff8013bf62>] vfio_iommu_type1_detach_group+0xda/0x2f0 [vfio_iommu_type1]
[1038876.561965]  [<000003ff8007b634>] __vfio_group_unset_container+0x64/0x190 [vfio]
[1038876.561978]  [<000003ff8007b87e>] vfio_group_put_external_user+0x26/0x38 [vfio]
[1038876.562024]  [<000003ff806fc608>] kvm_vfio_group_put_external_user+0x40/0x60 [kvm]
[1038876.562045]  [<000003ff806fcb9e>] kvm_vfio_destroy+0x5e/0xd0 [kvm]
[1038876.562065]  [<000003ff806f63fc>] kvm_put_kvm+0x2a4/0x3d0 [kvm]
[1038876.562083]  [<000003ff806f655e>] kvm_vm_release+0x36/0x48 [kvm]
[1038876.562098]  [<00000000003c2dc4>] __fput+0x144/0x228
[1038876.562113]  [<000000000016ee82>] task_work_run+0x8a/0xd8
[1038876.562125]  [<000000000014c7a8>] do_exit+0x5d8/0xd90
[1038876.562140]  [<000000000014d084>] do_group_exit+0xc4/0xc8
[1038876.562155]  [<000000000015c046>] get_signal+0x9ae/0xa68
[1038876.562169]  [<0000000000108d66>] do_signal+0x66/0x768
[1038876.562185]  [<0000000000b9e37e>] system_call+0x1ea/0x2d8
[1038876.562195] 2 locks held by qemu-system-s39/144727:
[1038876.562205]  #0: 00000000537abaf9 (&container->group_lock){++++}, at: __vfio_group_unset_container+0x3c/0x190 [vfio]
[1038876.562230]  #1: 00000000670008b5 (&iommu->lock){+.+.}, at: vfio_iommu_type1_detach_group+0x36/0x2f0 [vfio_iommu_type1]
[1038876.562250] Last Breaking-Event-Address:
[1038876.562262]  [<000003ff8013aa24>] vfio_sanity_check_pfn_list+0x3c/0x70 [vfio_iommu_type1]
[1038876.562272] irq event stamp: 4236481
[1038876.562287] hardirqs last  enabled at (4236489): [<00000000001cee7a>] console_unlock+0x6d2/0x740
[1038876.562299] hardirqs last disabled at (4236496): [<00000000001ce87e>] console_unlock+0xd6/0x740
[1038876.562311] softirqs last  enabled at (4234162): [<0000000000b9fa1e>] __do_softirq+0x556/0x598
[1038876.562325] softirqs last disabled at (4234153): [<000000000014e4cc>] irq_exit+0xac/0x108
[1038876.562337] ---[ end trace 6c96d467b1c3ca06 ]---

Similarly we do not free the channel program when we are removing the vfio-ccw device. Let's fix this by resetting the device and freeing the channel program and pinned pages in the release path. For the remove path we can just quiesce the device, since in the remove path the mediated device is going away for good and so we don't need to do a full reset.

Signed-off-by Farhan Ali <[email protected]>

---
 drivers/s390/cio/vfio_ccw_ops.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/s390/cio/vfio_ccw_ops.c +3 -1

index ec2f796c..aacd528 100644
@@ -133,11 +133,12 @@ static int vfio_ccw_mdev_remove(struct mdev_device *mdev)
 
 	if ((private->state != VFIO_CCW_STATE_NOT_OPER) &&
 	    (private->state != VFIO_CCW_STATE_STANDBY)) {
-		if (!vfio_ccw_mdev_reset(mdev))
+		if (!vfio_ccw_sch_quiesce(private->sch))
 			private->state = VFIO_CCW_STATE_STANDBY;
 		/* The state will be NOT_OPER on error. */
 	}
 
+	cp_free(&private->cp);
 	private->mdev = NULL;
 	atomic_inc(&private->avail);
 

@@ -171,6 +172,14 @@ static void vfio_ccw_mdev_release(struct mdev_device *mdev)
 		dev_get_drvdata(mdev_parent_dev(mdev));
 	int i;
 
+	if ((private->state != VFIO_CCW_STATE_NOT_OPER) &&

Quoted 49 lines · On Mon, 8 Apr 2019 17:05:32 -0400 Farhan Ali <[email protected]> wrote:

The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we:
- wait for any interrupts
- flush all I/O in the workqueue
- retry cio_cancel_halt_clear

During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever.

Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device.

Suggested-by Eric Farman <[email protected]>

Signed-off-by Farhan Ali <[email protected]>

---
  drivers/s390/cio/vfio_ccw_drv.c | 27 ++++++++++++---------------
  1 file changed, 12 insertions(+), 15 deletions(-)

drivers/s390/cio/vfio_ccw_drv.c +4 -9

index 5aca475..4405f2a 100644
@@ -43,26 +43,23 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
  	if (ret != -EBUSY)
  		goto out_unlock;
 
+	iretry = 255;
  	do {
-		iretry = 255;
 
  		ret = cio_cancel_halt_clear(sch, &iretry);
-		while (ret == -EBUSY) {
-			/*
-			 * Flush all I/O and wait for
-			 * cancel/halt/clear completion.
-			 */
-			private->completion = &completion;
-			spin_unlock_irq(sch->lock);
-
+		/*
+		 * Flush all I/O and wait for
+		 * cancel/halt/clear completion.

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 57

Quoted 5 lines

drivers/s390/cio/vfio_ccw_drv.c +5 -0

+		 */
+		private->completion = &completion;
+		spin_unlock_irq(sch->lock);
+
+		if (ret == -EBUSY)

I don't think you need to do the unlock/lock and change private->completion if you don't actually wait, no?

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

* -EBUSY -> we expect an interrupt (or a timeout), the loop looks fine for that
* 0 -> the one thing that might happen is that we get an unsolicited interrupt between the successful cancel_halt_clear and the disable; not even giving up the lock here might even be better here?

I think this loop will probably work as it is after this patch, but giving up the lock when not really needed makes me a bit queasy... what do others think?

Quoted 2 lines

drivers/s390/cio/vfio_ccw_drv.c +0 -0

  			wait_for_completion_timeout(&completion, 3*HZ);
 

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 60

Quoted 7 lines

drivers/s390/cio/vfio_ccw_drv.c +1 -6

-			private->completion = NULL;
-			flush_workqueue(vfio_ccw_work_q);
-			spin_lock_irq(sch->lock);
-			ret = cio_cancel_halt_clear(sch, &iretry);
-		};
-
+		private->completion = NULL;

Quoted 5 lines

drivers/s390/cio/vfio_ccw_drv.c +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
  		ret = cio_disable_subchannel(sch);
  	} while (ret == -EBUSY);
  out_unlock:

Quoted 2 lines · On Mon, 8 Apr 2019 17:05:33 -0400 Farhan Ali<[email protected]> wrote:

When releasing the vfio-ccw mdev, we currently do not release any existing channel program and it's pinned pages. This can

s/it's/its/

Quoted 52 lines · Cornelia Huck

Quoted 49 lines · On Mon, 8 Apr 2019 17:05:32 -0400 Farhan Ali <[email protected]> wrote:

The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we:
- wait for any interrupts
- flush all I/O in the workqueue
- retry cio_cancel_halt_clear

During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever.

Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device.

Suggested-by Eric Farman <[email protected]>

Signed-off-by Farhan Ali <[email protected]>

---
  drivers/s390/cio/vfio_ccw_drv.c | 27 ++++++++++++---------------
  1 file changed, 12 insertions(+), 15 deletions(-)

drivers/s390/cio/vfio_ccw_drv.c +4 -9

index 5aca475..4405f2a 100644
@@ -43,26 +43,23 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
  	if (ret != -EBUSY)
  		goto out_unlock;
 
+	iretry = 255;
  	do {
-		iretry = 255;
 
  		ret = cio_cancel_halt_clear(sch, &iretry);
-		while (ret == -EBUSY) {
-			/*
-			 * Flush all I/O and wait for
-			 * cancel/halt/clear completion.
-			 */
-			private->completion = &completion;
-			spin_unlock_irq(sch->lock);
-
+		/*
+		 * Flush all I/O and wait for
+		 * cancel/halt/clear completion.

Quoted 8 lines

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 57

Quoted 5 lines

drivers/s390/cio/vfio_ccw_drv.c +5 -0

+		 */
+		private->completion = &completion;
+		spin_unlock_irq(sch->lock);
+
+		if (ret == -EBUSY)  

I don't think you need to do the unlock/lock and change private->completion if you don't actually wait, no?

If we don't end up waiting, then changing private->completion would not be needed. But we would still need to release the spinlock due to [1].

Quoted 7 lines

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

We could break out of the loop early for these cases. My thinking was I wanted to depend on the result of trying to disable, because ultimately that's what we want.

I can add the cases to break out of the loop early.

Quoted 7 lines

* -EBUSY -> we expect an interrupt (or a timeout), the loop looks fine for that
* 0 -> the one thing that might happen is that we get an unsolicited interrupt between the successful cancel_halt_clear and the disable; not even giving up the lock here might even be better here?

I didn't think of this case, but if cancel_halt_clear succeeds with 0 then we should wait, no?

Quoted 8 lines

I think this loop will probably work as it is after this patch, but giving up the lock when not really needed makes me a bit queasy... what do others think?

Quoted 2 lines

drivers/s390/cio/vfio_ccw_drv.c +0 -0

  			wait_for_completion_timeout(&completion, 3*HZ);
 

Quoted 7 lines

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 60

Quoted 7 lines

drivers/s390/cio/vfio_ccw_drv.c +1 -6

-			private->completion = NULL;
-			flush_workqueue(vfio_ccw_work_q);
-			spin_lock_irq(sch->lock);
-			ret = cio_cancel_halt_clear(sch, &iretry);
-		};
-
+		private->completion = NULL;  

[1] flush_workqueue can go to sleep so we would still need to release spinlock and reacquire it again to try disabling the subchannel.

Quoted 8 lines

Quoted 6 lines

drivers/s390/cio/vfio_ccw_drv.c +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
  		ret = cio_disable_subchannel(sch);
  	} while (ret == -EBUSY);
  out_unlock:  

Quoted 3 lines · Cornelia Huck

On Mon, 8 Apr 2019 17:05:33 -0400
Farhan Ali<[email protected]> wrote:

Quoted 4 lines

Quoted 2 lines

When releasing the vfio-ccw mdev, we currently do not release any existing channel program and it's pinned pages. This can

s/it's/its/

Will fix.

Thanks for taking a look at the patches.

Quoted 9 lines · On Thu, 11 Apr 2019 16:39:32 -0400 Farhan Ali <[email protected]> wrote:

Quoted 7 lines · Cornelia Huck

Quoted 2 lines · On Mon, 8 Apr 2019 17:05:33 -0400 Farhan Ali<[email protected]> wrote:

When releasing the vfio-ccw mdev, we currently do not release any existing channel program and it's pinned pages. This can

s/it's/its/

Quoted 3 lines

Will fix.

Thanks for taking a look at the patches.

NP, I really want to queue them soon :)

Just give me a quick hint about dependencies: Do I need anything else before I can queue patch 1 and 3? I've lost track a bit...

Quoted 73 lines · On Thu, 11 Apr 2019 16:30:44 -0400 Farhan Ali <[email protected]> wrote:

Quoted 52 lines · Cornelia Huck

Quoted 49 lines · On Mon, 8 Apr 2019 17:05:32 -0400 Farhan Ali <[email protected]> wrote:

The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we:
- wait for any interrupts
- flush all I/O in the workqueue
- retry cio_cancel_halt_clear

During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever.

Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device.

Suggested-by Eric Farman <[email protected]>

Signed-off-by Farhan Ali <[email protected]>

---
   drivers/s390/cio/vfio_ccw_drv.c | 27 ++++++++++++---------------
   1 file changed, 12 insertions(+), 15 deletions(-)

drivers/s390/cio/vfio_ccw_drv.c +4 -9

index 5aca475..4405f2a 100644
@@ -43,26 +43,23 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
   	if (ret != -EBUSY)
   		goto out_unlock;
 
+	iretry = 255;
   	do {
-		iretry = 255;
 
   		ret = cio_cancel_halt_clear(sch, &iretry);
-		while (ret == -EBUSY) {
-			/*
-			 * Flush all I/O and wait for
-			 * cancel/halt/clear completion.
-			 */
-			private->completion = &completion;
-			spin_unlock_irq(sch->lock);
-
+		/*
+		 * Flush all I/O and wait for
+		 * cancel/halt/clear completion.

Quoted 8 lines

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 57

Quoted 5 lines

drivers/s390/cio/vfio_ccw_drv.c +5 -0

+		 */
+		private->completion = &completion;
+		spin_unlock_irq(sch->lock);
+
+		if (ret == -EBUSY)

I don't think you need to do the unlock/lock and change private->completion if you don't actually wait, no?

If we don't end up waiting, then changing private->completion would not be needed. But we would still need to release the spinlock due to [1].

Quoted 7 lines

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

Quoted 5 lines

We could break out of the loop early for these cases. My thinking was I wanted to depend on the result of trying to disable, because ultimately that's what we want.

I can add the cases to break out of the loop early.

The -ENODEV case does not really hurt, as it will get us out of the loop anyway. But for the -EIO case, I think we'll get -EBUSY from the disable and stay within the loop endlessly?

Quoted 10 lines

Quoted 7 lines

* -EBUSY -> we expect an interrupt (or a timeout), the loop looks fine for that
* 0 -> the one thing that might happen is that we get an unsolicited interrupt between the successful cancel_halt_clear and the disable; not even giving up the lock here might even be better here?

I didn't think of this case, but if cancel_halt_clear succeeds with 0 then we should wait, no?

For 0 I don't expect a solicited interrupt (documentation for the functions says that the subchannel is idle in that case); it's just the unsolicited interrupt that might get into the way.

Quoted 8 lines

Quoted 8 lines

I think this loop will probably work as it is after this patch, but giving up the lock when not really needed makes me a bit queasy... what do others think?

Quoted 2 lines

drivers/s390/cio/vfio_ccw_drv.c +0 -0

   			wait_for_completion_timeout(&completion, 3*HZ);
 

Quoted 10 lines

Quoted 7 lines

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 60

Quoted 7 lines

drivers/s390/cio/vfio_ccw_drv.c +1 -6

-			private->completion = NULL;
-			flush_workqueue(vfio_ccw_work_q);
-			spin_lock_irq(sch->lock);
-			ret = cio_cancel_halt_clear(sch, &iretry);
-		};
-
+		private->completion = NULL;

[1] flush_workqueue can go to sleep so we would still need to release spinlock and reacquire it again to try disabling the subchannel.

Grr, I thought we could skip the flush in the !-EBUSY case, but I think we can't due to the possibility of an unsolicited interrupt... what simply adding handling for -EIO (although I'm not sure what we can sensibly do in that case) and leave the other cases as they are now?

Quoted 9 lines

Quoted 8 lines

Quoted 6 lines

drivers/s390/cio/vfio_ccw_drv.c +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
   		ret = cio_disable_subchannel(sch);
   	} while (ret == -EBUSY);
   out_unlock:

When releasing the vfio-ccw mdev, we currently do not release any existing channel program and it's pinned pages. This can lead to the following warning:

[1038876.561565] WARNING: CPU: 2 PID: 144727 at drivers/vfio/vfio_iommu_type1.c:1494 vfio_sanity_check_pfn_list+0x40/0x70 [vfio_iommu_type1]

....

1038876.561921] Call Trace:

[1038876.561935] ([<00000009897fb870>] 0x9897fb870)
[1038876.561949]  [<000003ff8013bf62>] vfio_iommu_type1_detach_group+0xda/0x2f0 [vfio_iommu_type1]
[1038876.561965]  [<000003ff8007b634>] __vfio_group_unset_container+0x64/0x190 [vfio]
[1038876.561978]  [<000003ff8007b87e>] vfio_group_put_external_user+0x26/0x38 [vfio]
[1038876.562024]  [<000003ff806fc608>] kvm_vfio_group_put_external_user+0x40/0x60 [kvm]
[1038876.562045]  [<000003ff806fcb9e>] kvm_vfio_destroy+0x5e/0xd0 [kvm]
[1038876.562065]  [<000003ff806f63fc>] kvm_put_kvm+0x2a4/0x3d0 [kvm]
[1038876.562083]  [<000003ff806f655e>] kvm_vm_release+0x36/0x48 [kvm]
[1038876.562098]  [<00000000003c2dc4>] __fput+0x144/0x228
[1038876.562113]  [<000000000016ee82>] task_work_run+0x8a/0xd8
[1038876.562125]  [<000000000014c7a8>] do_exit+0x5d8/0xd90
[1038876.562140]  [<000000000014d084>] do_group_exit+0xc4/0xc8
[1038876.562155]  [<000000000015c046>] get_signal+0x9ae/0xa68
[1038876.562169]  [<0000000000108d66>] do_signal+0x66/0x768
[1038876.562185]  [<0000000000b9e37e>] system_call+0x1ea/0x2d8
[1038876.562195] 2 locks held by qemu-system-s39/144727:
[1038876.562205]  #0: 00000000537abaf9 (&container->group_lock){++++}, at: __vfio_group_unset_container+0x3c/0x190 [vfio]
[1038876.562230]  #1: 00000000670008b5 (&iommu->lock){+.+.}, at: vfio_iommu_type1_detach_group+0x36/0x2f0 [vfio_iommu_type1]
[1038876.562250] Last Breaking-Event-Address:
[1038876.562262]  [<000003ff8013aa24>] vfio_sanity_check_pfn_list+0x3c/0x70 [vfio_iommu_type1]
[1038876.562272] irq event stamp: 4236481
[1038876.562287] hardirqs last  enabled at (4236489): [<00000000001cee7a>] console_unlock+0x6d2/0x740
[1038876.562299] hardirqs last disabled at (4236496): [<00000000001ce87e>] console_unlock+0xd6/0x740
[1038876.562311] softirqs last  enabled at (4234162): [<0000000000b9fa1e>] __do_softirq+0x556/0x598
[1038876.562325] softirqs last disabled at (4234153): [<000000000014e4cc>] irq_exit+0xac/0x108
[1038876.562337] ---[ end trace 6c96d467b1c3ca06 ]---

Similarly we do not free the channel program when we are removing the vfio-ccw device. Let's fix this by resetting the device and freeing the channel program and pinned pages in the release path. For the remove path we can just quiesce the device, since in the remove path the mediated device is going away for good and so we don't need to do a full reset.

Signed-off-by Farhan Ali <[email protected]>

---
  drivers/s390/cio/vfio_ccw_ops.c | 11 ++++++++++-
  1 file changed, 10 insertions(+), 1 deletion(-)

drivers/s390/cio/vfio_ccw_ops.c +3 -1

index ec2f796c..aacd528 100644
@@ -133,11 +133,12 @@ static int vfio_ccw_mdev_remove(struct mdev_device *mdev)
 
  	if ((private->state != VFIO_CCW_STATE_NOT_OPER) &&
  	    (private->state != VFIO_CCW_STATE_STANDBY)) {
-		if (!vfio_ccw_mdev_reset(mdev))
+		if (!vfio_ccw_sch_quiesce(private->sch))
  			private->state = VFIO_CCW_STATE_STANDBY;
  		/* The state will be NOT_OPER on error. */
  	}
 
+	cp_free(&private->cp);
  	private->mdev = NULL;
  	atomic_inc(&private->avail);
 

@@ -171,6 +172,14 @@ static void vfio_ccw_mdev_release(struct mdev_device *mdev)
  		dev_get_drvdata(mdev_parent_dev(mdev));
  	int i;
 
+	if ((private->state != VFIO_CCW_STATE_NOT_OPER) &&

Quoted 16 lines · Cornelia Huck

Quoted 10 lines · On Thu, 11 Apr 2019 16:39:32 -0400 Farhan Ali <[email protected]> wrote:

Quoted 5 lines · Cornelia Huck

Quoted 2 lines · On Mon,  8 Apr 2019 17:05:33 -0400 Farhan Ali<[email protected]>  wrote:

When releasing the vfio-ccw mdev, we currently do not release any existing channel program and it's pinned pages. This can

s/it's/its/

Will fix.

Thanks for taking a look at the patches.

NP, I really want to queue them soon :)

Quoted 4 lines

Just give me a quick hint about dependencies: Do I need anything else before I can queue patch 1 and 3? I've lost track a bit...

Patch 1 can be queued without any problems and it has no dependencies.

Patch 3 would depend on your [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs. Since I want to call cp_free without any problems.

I know you are waiting for acks/r-bs for patch 3, so if no one has problems then we can go ahead and queue it.

Thanks
Farhan

Quoted 13 lines · Cornelia Huck

Quoted 10 lines · On Thu, 11 Apr 2019 16:30:44 -0400 Farhan Ali <[email protected]> wrote:

Quoted 9 lines · Cornelia Huck

On Mon, 8 Apr 2019 17:05:32 -0400
Farhan Ali <[email protected]> wrote:

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

Thinking a little bit more about EIO, if the return code is EIO then it means we have exhausted all our options with cancel_halt_clear and the subchannel/device is still status pending, right?

I think we should still continue to try and disable the subchannel, because if not then the subchannel/device could in some point of time come back and bite us. So we really should protect the system from this behavior.

I think for EIO we should log an error message, but still try to continue with disabling the subchannel. What do you or others think?

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 63

Quoted 8 lines

drivers/s390/cio/vfio_ccw_drv.c +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
   		ret = cio_disable_subchannel(sch);

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

   	} while (ret == -EBUSY);
   out_unlock:  

Quoted 14 lines · On Fri, 12 Apr 2019 10:38:50 -0400 Farhan Ali <[email protected]> wrote:

Quoted 13 lines · Cornelia Huck

Quoted 10 lines · On Thu, 11 Apr 2019 16:30:44 -0400 Farhan Ali <[email protected]> wrote:

Quoted 9 lines · Cornelia Huck

On Mon, 8 Apr 2019 17:05:32 -0400
Farhan Ali <[email protected]> wrote:

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

(...)

Quoted 3 lines

Thinking a little bit more about EIO, if the return code is EIO then it means we have exhausted all our options with cancel_halt_clear and the subchannel/device is still status pending, right?

Yes.

Quoted 5 lines

I think we should still continue to try and disable the subchannel, because if not then the subchannel/device could in some point of time come back and bite us. So we really should protect the system from this behavior.

I think trying to disable the subchannel does not really hurt, but I fear it won't succeed in that case...

Quoted 3 lines

I think for EIO we should log an error message, but still try to continue with disabling the subchannel. What do you or others think?

Logging an error may be useful (it's really fouled up at that time), but...

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

drivers/s390/cio/vfio_ccw_drv.c int vfio_ccw_sch_quiesce(struct subchannel *sch) · line 63

Quoted 3 lines

drivers/s390/cio/vfio_ccw_drv.c +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
    		ret = cio_disable_subchannel(sch);

...there's a good chance that we'd get -EBUSY here, which would keep us in the loop. We probably need to break out after we got -EIO from cancel_halt_clear, regardless of which return code we get from the disable.

(It will be "interesting" to see what happens with such a stuck subchannel in the calling code; but I don't really see many options. Panic seems way too strong; maybe mark the subchannel as "broken; no idea how to fix"? But that would be a follow-on patch; I think if we avoid the endless loop here, this patch is a real improvement and should just go in.)

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

    	} while (ret == -EBUSY);
    out_unlock:

Quoted 46 lines · Cornelia Huck

Quoted 14 lines · On Fri, 12 Apr 2019 10:38:50 -0400 Farhan Ali <[email protected]> wrote:

Quoted 13 lines · Cornelia Huck

Quoted 10 lines · On Thu, 11 Apr 2019 16:30:44 -0400 Farhan Ali <[email protected]> wrote:

Quoted 9 lines · Cornelia Huck

On Mon, 8 Apr 2019 17:05:32 -0400
Farhan Ali <[email protected]> wrote:

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

(...)

Quoted 3 lines

Thinking a little bit more about EIO, if the return code is EIO then it means we have exhausted all our options with cancel_halt_clear and the subchannel/device is still status pending, right?

Yes.

Quoted 5 lines

I think we should still continue to try and disable the subchannel, because if not then the subchannel/device could in some point of time come back and bite us. So we really should protect the system from this behavior.

I think trying to disable the subchannel does not really hurt, but I fear it won't succeed in that case...

Quoted 3 lines

I think for EIO we should log an error message, but still try to continue with disabling the subchannel. What do you or others think?

Logging an error may be useful (it's really fouled up at that time), but...

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Review

Quoted 3 lines

(quoted diff) +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
    		ret = cio_disable_subchannel(sch);  

...there's a good chance that we'd get -EBUSY here, which would keep us in the loop. We probably need to break out after we got -EIO from cancel_halt_clear, regardless of which return code we get from the disable.

Okay, for EIO we can log an error message and break out of the loop.

I will send a v3. Are you going to queue patch 1 or patch 3 soon? If you are then I will just send this patch separately.

Thanks
Farhan

Quoted 18 lines

(It will be "interesting" to see what happens with such a stuck subchannel in the calling code; but I don't really see many options. Panic seems way too strong; maybe mark the subchannel as "broken; no idea how to fix"? But that would be a follow-on patch; I think if we avoid the endless loop here, this patch is a real improvement and should just go in.)

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

    	} while (ret == -EBUSY);
    out_unlock:  

Quoted 56 lines · On Mon, 15 Apr 2019 09:38:37 -0400 Farhan Ali <[email protected]> wrote:

Quoted 54 lines · Cornelia Huck

Quoted 14 lines · On Fri, 12 Apr 2019 10:38:50 -0400 Farhan Ali <[email protected]> wrote:

Quoted 13 lines · Cornelia Huck

Quoted 10 lines · On Thu, 11 Apr 2019 16:30:44 -0400 Farhan Ali <[email protected]> wrote:

Quoted 9 lines · Cornelia Huck

On Mon, 8 Apr 2019 17:05:32 -0400
Farhan Ali <[email protected]> wrote:

Looking at the possible return codes:
* -ENODEV -> device is not operational anyway, in theory you should even not need to bother with disabling the subchannel
* -EIO -> we've run out of retries, and the subchannel still is not idle; I'm not sure if we could do anything here, as disable is unlikely to work, either

(...)

Quoted 3 lines

Thinking a little bit more about EIO, if the return code is EIO then it means we have exhausted all our options with cancel_halt_clear and the subchannel/device is still status pending, right?

Yes.

Quoted 5 lines

I think we should still continue to try and disable the subchannel, because if not then the subchannel/device could in some point of time come back and bite us. So we really should protect the system from this behavior.

I think trying to disable the subchannel does not really hurt, but I fear it won't succeed in that case...

Quoted 3 lines

I think for EIO we should log an error message, but still try to continue with disabling the subchannel. What do you or others think?

Logging an error may be useful (it's really fouled up at that time), but...

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Review

Quoted 8 lines

(quoted diff) +2 -0

+		flush_workqueue(vfio_ccw_work_q);
+		spin_lock_irq(sch->lock);
     		ret = cio_disable_subchannel(sch);

...there's a good chance that we'd get -EBUSY here, which would keep us in the loop. We probably need to break out after we got -EIO from cancel_halt_clear, regardless of which return code we get from the disable.

Quoted 4 lines

Okay, for EIO we can log an error message and break out of the loop.

I will send a v3. Are you going to queue patch 1 or patch 3 soon? If you are then I will just send this patch separately.

Yes, please do send it separately. I'm currently testing patch 1 and 3 on top of my patchset, will queue either with or without the halt/clear patches proper, depending on how soon I get acks/r-bs (hint, hint :)

Quoted 24 lines

Thanks
Farhan

Quoted 18 lines

(It will be "interesting" to see what happens with such a stuck subchannel in the calling code; but I don't really see many options. Panic seems way too strong; maybe mark the subchannel as "broken; no idea how to fix"? But that would be a follow-on patch; I think if we avoid the endless loop here, this patch is a real improvement and should just go in.)

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

     	} while (ret == -EBUSY);
     out_unlock:

Quoted 3 lines · Cornelia Huck

Yes, please do send it separately. I'm currently testing patch 1 and 3 on top of my patchset, will queue either with or without the halt/clear patches proper, depending on how soon I get acks/r-bs (hint, hint :)

I am going through your patches 4 and 6 and hopefully will get back to you by the end of the day :).

Hi,

I have recently seen some interesting kernel stacktraces while testing vfio-ccw mediated devices. These stack traces are seen when things don't go right, for example when a guest crashes or dies while still doing some I/O on the mediated device.

I have also come across an issue in the common vfio code as
well which I reported upstream (https://marc.info/?l=kvm&m=155369393523503&w=2)
and submitted a patch separately for it
(https://marc.info/?l=kvm&m=155414703613868&w=2).

I would appreciate any review or feedback on these patches.

Thanks
Farhan

ChangeLog
---------
v1 -> v2
- Use the return code from cio_cancel_halt_clear to prevent waiting unnecessarily (patch 2).

- No need to reset the device on the remove path (patch 3).

Farhan Ali (3):
vfio-ccw: Do not call flush_workqueue while holding the spinlock
vfio-ccw: Prevent quiesce function going into an infinite loop
vfio-ccw: Release any channel program when releasing/removing vfio-ccw
mdev

 drivers/s390/cio/vfio_ccw_drv.c | 27 ++++++++++++---------------
 drivers/s390/cio/vfio_ccw_ops.c | 11 ++++++++++-
 2 files changed, 22 insertions(+), 16 deletions(-)