Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754020AbcKASOv (ORCPT ); Tue, 1 Nov 2016 14:14:51 -0400 Received: from p3plsmtps2ded03.prod.phx3.secureserver.net ([208.109.80.60]:45542 "EHLO p3plsmtps2ded03.prod.phx3.secureserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753916AbcKASOh (ORCPT ); Tue, 1 Nov 2016 14:14:37 -0400 x-originating-ip: 72.167.245.219 From: kys@exchange.microsoft.com To: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com, jasowang@redhat.com, leann.ogasawara@canonical.com, sthemmin@microsoft.com Cc: "K. Y. Srinivasan" Subject: [PATCH V2 12/14] Drivers: hv: vmbus: Base host signaling strictly on the ring state Date: Tue, 1 Nov 2016 13:07:32 -0700 Message-Id: <1478030854-5970-12-git-send-email-kys@exchange.microsoft.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1478030854-5970-1-git-send-email-kys@exchange.microsoft.com> References: <1478030807-5915-1-git-send-email-kys@exchange.microsoft.com> <1478030854-5970-1-git-send-email-kys@exchange.microsoft.com> Reply-To: kys@microsoft.com X-CMAE-Envelope: MS4wfN5AcMVZof+iD1hBHqe1gsYl40Dp3wOfwxD7PF4Ny0axB7LtQV+BzVt39qWws+Q6Wl2WPUb5BFr2jCp5AqF2uzjTxbWZHUqIZkdKVUFRxgb8mAczdcC0 731mghbMK3rQZrIbweScx9deHbAdW+8ZtidsgDFG7EhdHGVgx0z3oMW4TSnt/bnKXkNOPNcqSEDUMepc0Cz+itBi2oGTknV/m1BwJimPtb1xbmP4RJYunQmw VG5V9mzEQ1R8QRI65Kn9+N/0kmUvgBhjjCe0W74NZVOW0BO5lGJWWY/LQCW1q5PCV/fakv3UwAn6blki4+uf/Fzwpnv47bDJwO2HBeCYtRT6qzg74IOwZ+nc 6c61Z8DpqOmB5aa5lx13+wlMUeCZYV6kRLEnvVPxpPEKTEkJqKAyT107KB5/PzqCbc4mMmuft+E7aXW+sRi8nZ4wxKB1qcoT55bbpOiSQCcNoAzfEUqzDOE2 Vojr3upRVTcHr81ITFVNOGBhu9aIdSZaGXm+xA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3640 Lines: 96 From: K. Y. Srinivasan One of the factors that can result in the host concluding that a given guest in mounting a DOS attack is if the guest generates interrupts to the host when the host is not expecting it. If these "spurious" interrupts reach a certain rate, the host can throttle the guest to minimize the impact. The host computation of the "expected number of interrupts" is strictly based on the ring transitions. Until the host logic is fixed, base the guest logic to interrupt solely on the ring state. Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c | 23 ++++++++++++++++++++--- drivers/hv/channel_mgmt.c | 2 -- drivers/hv/ring_buffer.c | 7 ------- 3 files changed, 20 insertions(+), 12 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 16f91c8..5e482d7 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -676,10 +676,18 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, * NOTE: in this case, the hvsock channel is an exception, because * it looks the host side's hvsock implementation has a throttling * mechanism which can hurt the performance otherwise. + * + * KYS: Oct. 30, 2016: + * It looks like Windows hosts have logic to deal with DOS attacks that + * can be triggered if it receives interrupts when it is not expecting + * the interrupt. The host expects interrupts only when the ring + * transitions from empty to non-empty (or full to non full on the guest + * to host ring). + * So, base the signaling decision solely on the ring state until the + * host logic is fixed. */ - if (((ret == 0) && kick_q && signal) || - (ret && !is_hvsock_channel(channel))) + if (((ret == 0) && signal)) vmbus_setevent(channel); return ret; @@ -786,9 +794,18 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel, * 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. + * + * KYS: Oct. 30, 2016: + * It looks like Windows hosts have logic to deal with DOS attacks that + * can be triggered if it receives interrupts when it is not expecting + * the interrupt. The host expects interrupts only when the ring + * transitions from empty to non-empty (or full to non full on the guest + * to host ring). + * So, base the signaling decision solely on the ring state until the + * host logic is fixed. */ - if (((ret == 0) && kick_q && signal) || (ret)) + if (((ret == 0) && signal)) vmbus_setevent(channel); return ret; diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 96a85cd..cbb96f2 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -447,8 +447,6 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel) } dev_type = hv_get_dev_type(newchannel); - if (dev_type == HV_NIC) - set_channel_signal_state(newchannel, HV_SIGNAL_POLICY_EXPLICIT); init_vp_index(newchannel, dev_type); diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 08043da..5d11d93 100644 --- a/drivers/hv/ring_buffer.c +++ b/drivers/hv/ring_buffer.c @@ -75,13 +75,6 @@ static bool hv_need_to_signal(u32 old_write, struct hv_ring_buffer_info *rbi, if (READ_ONCE(rbi->ring_buffer->interrupt_mask)) return false; - /* - * When the client wants to control signaling, - * we only honour the host interrupt mask. - */ - if (policy == HV_SIGNAL_POLICY_EXPLICIT) - return true; - /* check interrupt_mask before read_index */ virt_rmb(); /* -- 1.7.4.1