These redundant unlocks of visornic_devdata.priv_lock would result in
the RHEL 7.2 guests hanging during service partition recovery testing.
__Testing__
* An scp of a large file was started from a remote host TO the RHEL 7.2
Linux guest.
* During the scp transfer, s-Par service partition recovery was forced
twice. After each occasion, I verified that the guest recovered
completely (all s-Par guest devices), and that the file transfer
resumed.
* Within the RHEL 7.2 guest environment, copied the large file to
another location in the local filesystem.
* During the copy, s-Par service partition recovery was again forced
twice. After each occasion, I verified that the guest recovered
completely (all s-Par guest devices), and that the copy resumed.
* An scp of the new copy of the large file was started FROM the RHEL 7.2
guest to a remote host.
* During the scp transfer, s-Par service partition recovery was forced
twice. After each occasion, I verified that the guest recovered
completely (all s-Par guest devices), and that the file transfer
resumed.
* Used cmp to verify that the large file had successfully survived the
round-trip without becoming corrupted.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
if (devdata->enab_dis_acked)
break;
if (devdata->server_down || devdata->server_change_state) {
- spin_unlock_irqrestore(&devdata->priv_lock, flags);
dev_dbg(&netdev->dev, "%s server went away\n",
__func__);
break;
if (devdata->enab_dis_acked)
break;
if (devdata->server_down || devdata->server_change_state) {
- spin_unlock_irqrestore(&devdata->priv_lock, flags);
dev_dbg(&netdev->dev, "%s server went away\n",
__func__);
break;