Searched hist:"8 d9560ebcc6448472b3afe8f36f37d6b0de8f5a4" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/drivers/hv/ |
H A D | hv_snapshot.c | diff 8d9560ebcc6448472b3afe8f36f37d6b0de8f5a4 Thu Nov 06 11:21:25 CST 2014 Vitaly Kuznetsov <vkuznets@redhat.com> Drivers: hv: kvp,vss: Fast propagation of userspace communication failure
If we fail to send a message to userspace daemon with cn_netlink_send() there is no need to wait for userspace to reply as it is not going to happen. This happens when kvp or vss daemon is stopped after a successful handshake. Report HV_E_FAIL immediately and cancel the timeout job so host won't receive two failures. Use pr_warn() for VSS and pr_debug() for KVP deliberately as VSS request are rare and result in a failed backup. KVP requests are much more frequent after a successful handshake so avoid flooding logs. It would be nice to have an ability to de-negotiate with the host in case userspace daemon gets disconnected so we won't receive new requests. But I'm not sure it is possible.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
H A D | hv_kvp.c | diff 8d9560ebcc6448472b3afe8f36f37d6b0de8f5a4 Thu Nov 06 11:21:25 CST 2014 Vitaly Kuznetsov <vkuznets@redhat.com> Drivers: hv: kvp,vss: Fast propagation of userspace communication failure
If we fail to send a message to userspace daemon with cn_netlink_send() there is no need to wait for userspace to reply as it is not going to happen. This happens when kvp or vss daemon is stopped after a successful handshake. Report HV_E_FAIL immediately and cancel the timeout job so host won't receive two failures. Use pr_warn() for VSS and pr_debug() for KVP deliberately as VSS request are rare and result in a failed backup. KVP requests are much more frequent after a successful handshake so avoid flooding logs. It would be nice to have an ability to de-negotiate with the host in case userspace daemon gets disconnected so we won't receive new requests. But I'm not sure it is possible.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|