stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RESEND 23/27] Drivers: hv: vmbus: Fix a Host signaling bug
       [not found] ` <1449894107-3389-1-git-send-email-kys@microsoft.com>
@ 2015-12-12  4:21   ` K. Y. Srinivasan
  2015-12-12  4:21   ` [PATCH 27/27] tools: hv: vss: fix the write()'s argument: error -> vss_msg K. Y. Srinivasan
  1 sibling, 0 replies; 2+ messages in thread
From: K. Y. Srinivasan @ 2015-12-12  4:21 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, olaf, apw, vkuznets, jasowang
  Cc: K. Y. Srinivasan, stable, #, v4.2+

Currently we have two policies for deciding when to signal the host:
One based on the ring buffer state and the other based on what the
VMBUS client driver wants to do. Consider the case when the client
wants to explicitly control when to signal the host. In this case,
if the client were to defer signaling, we will not be able to signal
the host subsequently when the client does want to signal since the
ring buffer state will prevent the signaling. Implement logic to
have only one signaling policy in force for a given channel.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Tested-by: Haiyang Zhang <haiyangz@microsoft.com>
Cc: <stable@vger.kernel.org> # v4.2+
---
 drivers/hv/channel.c   |   18 ++++++++++++++++++
 include/linux/hyperv.h |   18 ++++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 77d2579..2889d97 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -653,10 +653,19 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer,
 	 *    on the ring. We will not signal if more data is
 	 *    to be placed.
 	 *
+	 * Based on the channel signal state, we will decide
+	 * which signaling policy will be applied.
+	 *
 	 * If we cannot write to the ring-buffer; signal the host
 	 * even if we may not have written anything. This is a rare
 	 * enough condition that it should not matter.
 	 */
+
+	if (channel->signal_policy)
+		signal = true;
+	else
+		kick_q = true;
+
 	if (((ret == 0) && kick_q && signal) || (ret))
 		vmbus_setevent(channel);
 
@@ -756,10 +765,19 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel,
 	 *    on the ring. We will not signal if more data is
 	 *    to be placed.
 	 *
+	 * Based on the channel signal state, we will decide
+	 * which signaling policy will be applied.
+	 *
 	 * If we cannot write to the ring-buffer; signal the host
 	 * even if we may not have written anything. This is a rare
 	 * enough condition that it should not matter.
 	 */
+
+	if (channel->signal_policy)
+		signal = true;
+	else
+		kick_q = true;
+
 	if (((ret == 0) && kick_q && signal) || (ret))
 		vmbus_setevent(channel);
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index f773a68..acd995b 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -630,6 +630,11 @@ struct hv_input_signal_event_buffer {
 	struct hv_input_signal_event event;
 };
 
+enum hv_signal_policy {
+	HV_SIGNAL_POLICY_DEFAULT = 0,
+	HV_SIGNAL_POLICY_EXPLICIT,
+};
+
 struct vmbus_channel {
 	/* Unique channel id */
 	int id;
@@ -757,8 +762,21 @@ struct vmbus_channel {
 	 * link up channels based on their CPU affinity.
 	 */
 	struct list_head percpu_list;
+	/*
+	 * Host signaling policy: The default policy will be
+	 * based on the ring buffer state. We will also support
+	 * a policy where the client driver can have explicit
+	 * signaling control.
+	 */
+	enum hv_signal_policy  signal_policy;
 };
 
+static inline void set_channel_signal_state(struct vmbus_channel *c,
+					    enum hv_signal_policy policy)
+{
+	c->signal_policy = policy;
+}
+
 static inline void set_channel_read_state(struct vmbus_channel *c, bool state)
 {
 	c->batched_reading = state;
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [PATCH 27/27] tools: hv: vss: fix the write()'s argument: error -> vss_msg
       [not found] ` <1449894107-3389-1-git-send-email-kys@microsoft.com>
  2015-12-12  4:21   ` [PATCH RESEND 23/27] Drivers: hv: vmbus: Fix a Host signaling bug K. Y. Srinivasan
@ 2015-12-12  4:21   ` K. Y. Srinivasan
  1 sibling, 0 replies; 2+ messages in thread
From: K. Y. Srinivasan @ 2015-12-12  4:21 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, olaf, apw, vkuznets, jasowang
  Cc: Dexuan Cui, K. Y. Srinivasan, stable

From: Dexuan Cui <decui@microsoft.com>

Fix the write()'s argument in the daemon code.

Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 tools/hv/hv_vss_daemon.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 96234b6..5d51d6f 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -254,7 +254,7 @@ int main(int argc, char *argv[])
 			syslog(LOG_ERR, "Illegal op:%d\n", op);
 		}
 		vss_msg->error = error;
-		len = write(vss_fd, &error, sizeof(struct hv_vss_msg));
+		len = write(vss_fd, vss_msg, sizeof(struct hv_vss_msg));
 		if (len != sizeof(struct hv_vss_msg)) {
 			syslog(LOG_ERR, "write failed; error: %d %s", errno,
 			       strerror(errno));
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-12-12  4:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1449894084-3348-1-git-send-email-kys@microsoft.com>
     [not found] ` <1449894107-3389-1-git-send-email-kys@microsoft.com>
2015-12-12  4:21   ` [PATCH RESEND 23/27] Drivers: hv: vmbus: Fix a Host signaling bug K. Y. Srinivasan
2015-12-12  4:21   ` [PATCH 27/27] tools: hv: vss: fix the write()'s argument: error -> vss_msg K. Y. Srinivasan

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).