LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com> To: "K. Y. Srinivasan" <kys@microsoft.com>, devel@linuxdriverproject.org Cc: Haiyang Zhang <haiyangz@microsoft.com>, linux-kernel@vger.kernel.org, Dexuan Cui <decui@microsoft.com>, Radim Krcmar <rkrcmar@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-api@vger.kernel.org Subject: [PATCH RFCv2 09/21] Drivers: hv: kvp: switch to using the hvutil_device_state state machine Date: Wed, 11 Mar 2015 14:29:22 +0100 [thread overview] Message-ID: <1426080574-9011-10-git-send-email-vkuznets@redhat.com> (raw) In-Reply-To: <1426080574-9011-1-git-send-email-vkuznets@redhat.com> ... from using 2 different state variables: kvp_transaction.active and in_hand_shake. State transitions are: -> HVUTIL_DEVICE_INIT when driver loads or on device release -> HVUTIL_READY if the handshake was successful -> HVUTIL_HOSTMSG_RECEIVED when there is a non-negotiation message from the host -> HVUTIL_USERSPACE_REQ after we sent the message to the userspace daemon -> HVUTIL_USERSPACE_RECV after/if the userspace daemon has replied -> HVUTIL_READY after we respond to the host -> HVUTIL_DEVICE_DYING on driver unload In hv_kvp_onchannelcallback() process ICMSGTYPE_NEGOTIATE messages even when the userspace daemon is disconnected, otherwise we can make the host think we don't support KVP and disable the service completely. Unfortunately there is no good way we can figure out that the userspace daemon has died (unless we start treating all timeouts as such). In case the daemon restarts we skip the negotiation procedure (so the daemon is supposed to has the same version). This behavior is unchanged from in_handshake approach. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> --- drivers/hv/hv_kvp.c | 87 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 49 insertions(+), 38 deletions(-) diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c index 14c62e2..a70d202 100644 --- a/drivers/hv/hv_kvp.c +++ b/drivers/hv/hv_kvp.c @@ -46,16 +46,21 @@ #define WIN8_SRV_VERSION (WIN8_SRV_MAJOR << 16 | WIN8_SRV_MINOR) /* - * Global state maintained for transaction that is being processed. - * Note that only one transaction can be active at any point in time. + * Global state maintained for transaction that is being processed. For a class + * of integration services, including the "KVP service", the specified protocol + * is a "request/response" protocol which means that there can only be single + * outstanding transaction from the host at any given point in time. We use + * this to simplify memory management in this driver - we cache and process + * only one message at a time. * - * This state is set when we receive a request from the host; we - * cleanup this state when the transaction is completed - when we respond - * to the host with the key value. + * While the request/response protocol is guaranteed by the host, we further + * ensure this by serializing packet processing in this driver - we do not + * read additional packets from the VMBUs until the current packet is fully + * handled. */ static struct { - bool active; /* transaction status - active or not */ + int state; /* hvutil_device_state */ int recv_len; /* number of bytes received. */ struct hv_kvp_msg *kvp_msg; /* current message */ struct vmbus_channel *recv_channel; /* chn we got the request */ @@ -64,13 +69,6 @@ static struct { } kvp_transaction; /* - * Before we can accept KVP messages from the host, we need - * to handshake with the user level daemon. This state tracks - * if we are in the handshake phase. - */ -static bool in_hand_shake = true; - -/* * This state maintains the version number registered by the daemon. */ static int dm_reg_value; @@ -126,6 +124,13 @@ static void kvp_timeout_func(struct work_struct *dummy) * process the pending transaction. */ kvp_respond_to_host(NULL, HV_E_FAIL); + + /* Transaction is finished, reset the state. */ + if (kvp_transaction.state > HVUTIL_READY) + kvp_transaction.state = HVUTIL_READY; + + hv_poll_channel(kvp_transaction.kvp_context, + hv_kvp_onchannelcallback); } static int kvp_handle_handshake(struct hv_kvp_msg *msg) @@ -154,9 +159,7 @@ static int kvp_handle_handshake(struct hv_kvp_msg *msg) */ pr_info("KVP: user-mode registering done.\n"); kvp_register(dm_reg_value); - kvp_transaction.active = false; - hv_poll_channel(kvp_transaction.kvp_context, - hv_kvp_onchannelcallback); + kvp_transaction.state = HVUTIL_READY; } return ret; } @@ -180,12 +183,16 @@ kvp_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp) * with the daemon; handle that first. */ - if (in_hand_shake) { - if (kvp_handle_handshake(message)) - in_hand_shake = false; + if (kvp_transaction.state < HVUTIL_READY) { + kvp_handle_handshake(message); return; } + /* We didn't send anything to userspace so the reply is spurious */ + if (kvp_transaction.state < HVUTIL_USERSPACE_REQ) + return; + kvp_transaction.state = HVUTIL_USERSPACE_RECV; + /* * Based on the version of the daemon, we propagate errors from the * daemon differently. @@ -215,8 +222,12 @@ kvp_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp) * Complete the transaction by forwarding the key value * to the host. But first, cancel the timeout. */ - if (cancel_delayed_work_sync(&kvp_timeout_work)) + if (cancel_delayed_work_sync(&kvp_timeout_work)) { kvp_respond_to_host(message, error); + kvp_transaction.state = HVUTIL_READY; + hv_poll_channel(kvp_transaction.kvp_context, + hv_kvp_onchannelcallback); + } } @@ -342,6 +353,10 @@ kvp_send_key(struct work_struct *dummy) __u64 val64; int rc; + /* The transaction state is wrong. */ + if (kvp_transaction.state != HVUTIL_HOSTMSG_RECEIVED) + return; + msg = kzalloc(sizeof(*msg) + sizeof(struct hv_kvp_msg) , GFP_ATOMIC); if (!msg) return; @@ -437,11 +452,14 @@ kvp_send_key(struct work_struct *dummy) } msg->len = sizeof(struct hv_kvp_msg); + kvp_transaction.state = HVUTIL_USERSPACE_REQ; rc = cn_netlink_send(msg, 0, 0, GFP_ATOMIC); if (rc) { pr_debug("KVP: failed to communicate to the daemon: %d\n", rc); - if (cancel_delayed_work_sync(&kvp_timeout_work)) + if (cancel_delayed_work_sync(&kvp_timeout_work)) { kvp_respond_to_host(message, HV_E_FAIL); + kvp_transaction.state = HVUTIL_READY; + } } kfree(msg); @@ -469,17 +487,6 @@ kvp_respond_to_host(struct hv_kvp_msg *msg_to_host, int error) int ret; /* - * If a transaction is not active; log and return. - */ - - if (!kvp_transaction.active) { - /* - * This is a spurious call! - */ - pr_warn("KVP: Transaction not active\n"); - return; - } - /* * Copy the global state for completing the transaction. Note that * only one transaction can be active at a time. */ @@ -488,8 +495,6 @@ kvp_respond_to_host(struct hv_kvp_msg *msg_to_host, int error) channel = kvp_transaction.recv_channel; req_id = kvp_transaction.recv_req_id; - kvp_transaction.active = false; - icmsghdrp = (struct icmsg_hdr *) &recv_buffer[sizeof(struct vmbuspipe_hdr)]; @@ -576,7 +581,6 @@ response_done: vmbus_sendpacket(channel, recv_buffer, buf_len, req_id, VM_PKT_DATA_INBAND, 0); - hv_poll_channel(channel, hv_kvp_onchannelcallback); } /* @@ -602,7 +606,7 @@ void hv_kvp_onchannelcallback(void *context) int util_fw_version; int kvp_srv_version; - if (kvp_transaction.active) { + if (kvp_transaction.state > HVUTIL_READY) { /* * We will defer processing this callback once * the current transaction is complete. @@ -655,9 +659,15 @@ void hv_kvp_onchannelcallback(void *context) kvp_transaction.recv_len = recvlen; kvp_transaction.recv_channel = channel; kvp_transaction.recv_req_id = requestid; - kvp_transaction.active = true; kvp_transaction.kvp_msg = kvp_msg; + if (kvp_transaction.state < HVUTIL_READY) { + /* Userspace is not registered yet */ + kvp_respond_to_host(NULL, HV_E_FAIL); + return; + } + kvp_transaction.state = HVUTIL_HOSTMSG_RECEIVED; + /* * Get the information from the * user-mode component. @@ -700,13 +710,14 @@ hv_kvp_init(struct hv_util_service *srv) * Defer processing channel callbacks until the daemon * has registered. */ - kvp_transaction.active = true; + kvp_transaction.state = HVUTIL_DEVICE_INIT; return 0; } void hv_kvp_deinit(void) { + kvp_transaction.state = HVUTIL_DEVICE_DYING; cn_del_callback(&kvp_id); cancel_delayed_work_sync(&kvp_timeout_work); cancel_work_sync(&kvp_sendkey_work); -- 1.9.3
next prev parent reply other threads:[~2015-03-11 13:36 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-11 13:29 [PATCH RFCv2 00/21] Drivers: hv: utils: re-implement the kernel/userspace communication layer Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 01/21] Drivers: hv: util: move kvp/vss function declarations to hyperv_vmbus.h Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 02/21] Drivers: hv: kvp: reset kvp_context Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 03/21] Drivers: hv: kvp: move poll_channel() to hyperv_vmbus.h Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 04/21] Drivers: hv: fcopy: process deferred messages when we complete the transaction Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 05/21] Drivers: hv: vss: " Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 06/21] Drivers: hv: kvp: rename kvp_work -> kvp_timeout_work Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 07/21] Drivers: hv: fcopy: rename fcopy_work -> fcopy_timeout_work Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 08/21] Drivers: hv: util: introduce state machine for util drivers Vitaly Kuznetsov 2015-03-11 13:29 ` Vitaly Kuznetsov [this message] 2015-03-11 13:29 ` [PATCH RFCv2 10/21] Drivers: hv: vss: switch to using the hvutil_device_state state machine Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 11/21] Drivers: hv: fcopy: " Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 12/21] Drivers: hv: fcopy: set .owner reference for file operations Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 13/21] Drivers: hv: util: introduce hv_utils_transport abstraction Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 14/21] Drivers: hv: vss: convert to hv_utils_transport Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 15/21] Drivers: hv: fcopy: " Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 16/21] Drivers: hv: kvp: " Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 17/21] Tools: hv: kvp: use misc char device to communicate with kernel Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 18/21] Tools: hv: vss: " Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 19/21] Drivers: hv: vss: full handshake support Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 20/21] Drivers: hv: fcopy: " Vitaly Kuznetsov 2015-03-11 13:29 ` [PATCH RFCv2 21/21] Drivers: hv: utils: unify driver registration reporting Vitaly Kuznetsov 2015-03-16 18:15 ` [PATCH RFCv2 00/21] Drivers: hv: utils: re-implement the kernel/userspace communication layer KY Srinivasan 2015-04-08 16:00 ` Vitaly Kuznetsov 2015-04-08 16:15 ` KY Srinivasan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1426080574-9011-10-git-send-email-vkuznets@redhat.com \ --to=vkuznets@redhat.com \ --cc=decui@microsoft.com \ --cc=devel@linuxdriverproject.org \ --cc=gregkh@linuxfoundation.org \ --cc=haiyangz@microsoft.com \ --cc=kys@microsoft.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rkrcmar@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).