linux-kernel - RE: [PATCH v2] Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BLUPR03MB14126592B2004E184E2B7106CAA10@BLUPR03MB1412.namprd03.prod.outlook.com>
Date:   Tue, 1 Nov 2016 14:57:18 +0000
From:   Haiyang Zhang <haiyangz@...rosoft.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "KY Srinivasan" <kys@...rosoft.com>,
        "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Subject: RE: [PATCH v2] Drivers: hv: vmbus: Raise retry/wait limits in
 vmbus_post_msg()



> -----Original Message-----
> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
> Sent: Tuesday, November 1, 2016 9:34 AM
> To: devel@...uxdriverproject.org
> Cc: linux-kernel@...r.kernel.org; KY Srinivasan <kys@...rosoft.com>;
> Haiyang Zhang <haiyangz@...rosoft.com>; Van De Ven, Arjan
> <arjan.van.de.ven@...el.com>
> Subject: [PATCH v2] Drivers: hv: vmbus: Raise retry/wait limits in
> vmbus_post_msg()
> 
> DoS protection conditions were altered in WS2016 and now it's easy to
> get
> -EAGAIN returned from vmbus_post_msg() (e.g. when we try changing MTU on
> a
> netvsc device in a loop). All vmbus_post_msg() callers don't retry the
> operation and we usually end up with a non-functional device or crash.
> 
> While host's DoS protection conditions are unknown to me my tests show
> that
> it can take up to 10 seconds before the message is sent so doing udelay()
> is not an option, we really need to sleep. Almost all vmbus_post_msg()
> callers are ready to sleep but there is one special case:
> vmbus_initiate_unload() which can be called from interrupt/NMI context
> and
> we can't sleep there. I'm also not sure about the lonely
> vmbus_send_tl_connect_request() which has no in-tree users but its
> external
> users are most likely waiting for the host to reply so sleeping there is
> also appropriate.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> ---
> - Changes since v1: keep microsecods delays and udelay() for first
> attempts
>   [KY Srinivasan, Arjan Van De Ven]
> ---
>  drivers/hv/channel.c      | 17 +++++++++--------
>  drivers/hv/channel_mgmt.c | 10 ++++++----
>  drivers/hv/connection.c   | 17 ++++++++++++-----
>  drivers/hv/hyperv_vmbus.h |  2 +-
>  4 files changed, 28 insertions(+), 18 deletions(-)
> 

Thank you.

Reviewed-by: Haiyang Zhang <haiyangz@...rosoft.com>