linux-kernel - RE: [PATCH 0/3] drivers/hv: make max_num_channels

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <MW2PR2101MB1052DC9416ABC1ECFE25E38DD7F01@MW2PR2101MB1052.namprd21.prod.outlook.com>
Date:   Sat, 5 Dec 2020 18:27:38 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Stefan Eschenbacher <stefan.eschenbacher@....de>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>
CC:     "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-kernel@...cs.fau.de" <linux-kernel@...cs.fau.de>,
        Max Stolze <max.stolze@....de>
Subject: RE: [PATCH 0/3] drivers/hv: make max_num_channels_supported
 configurable

From: Stefan Eschenbacher <stefan.eschenbacher@....de>
> 
> According to the TODO comment in hyperv_vmbus.h the value in macro
> MAX_NUM_CHANNELS_SUPPORTED should be configurable. The first patch
> accomplishes that by introducting uint max_num_channels_supported as
> module parameter.
> Also macro MAX_NUM_CHANNELS_SUPPORTED_DEFAULT is introduced with
> value 256, which is the currently used macro value.
> MAX_NUM_CHANNELS_SUPPORTED was found and replaced in two locations.
> 
> During module initialization sanity checks are applied which will result
> in EINVAL or ERANGE if the given value is no multiple of 32 or larger than
> MAX_NUM_CHANNELS.
> 
> While testing, we found a misleading typo in the comment for the macro
> MAX_NUM_CHANNELS which is fixed by the second patch.
> 
> The third patch makes the added default macro configurable by
> introduction and use of Kconfig parameter HYPERV_VMBUS_DEFAULT_CHANNELS.
> Default value remains at 256.
> 
> Two notes on these patches:
> 1) With above patches it is valid to configure max_num_channels_supported
> and MAX_NUM_CHANNELS_SUPPORTED_DEFAULT as 0. We simply don't know if that
> is a valid value. Doing so while testing still left us with a working
> Debian VM in Hyper-V on Windows 10.
> 2) To set the Kconfig parameter the user currently has to divide the
> desired default number of channels by 32 and enter the result of that
> calculation. This way both known constraints we got from the comments in
> the code are enforced. It feels a bit unintuitive though. We haven't found
> Kconfig options to ensure that the value is a multiple of 32. So if you'd
> like us to fix that we'd be happy for some input on how to settle it with
> Kconfig.
> 
> Signed-off-by: Stefan Eschenbacher <stefan.eschenbacher@....de>
> Co-developed-by: Max Stolze <max.stolze@....de>
> Signed-off-by: Max Stolze <max.stolze@....de>
> 
> Stefan Eschenbacher (3):
>   drivers/hv: make max_num_channels_supported configurable
>   drivers/hv: fix misleading typo in comment
>   drivers/hv: add default number of vmbus channels to Kconfig
> 
>  drivers/hv/Kconfig        | 13 +++++++++++++
>  drivers/hv/hyperv_vmbus.h |  8 ++++----
>  drivers/hv/vmbus_drv.c    | 20 +++++++++++++++++++-
>  3 files changed, 36 insertions(+), 5 deletions(-)
> 
> --
> 2.20.1

Stefan -- this cover letter email came through, but it doesn't look like
the individual patch emails did.  So you might want to check your
patch sending process.

Thanks for your interest in this old "TODO" item.  But let me provide some
additional background.  Starting in Windows 8 and Windows Server 2012,
Hyper-V revised the mechanism by which channel interrupt notifications
are made.  The MAX_NUM_CHANNELS_SUPPORTED value is only used
with Windows 7 and Windows Server 2008 R2, neither of which is officially
supported any longer.  See the code at the top of vmbus_chan_sched() where
the VMBus protocol version is checked, and MAX_NUM_CHANNELS_SUPPORTED
is used only when the protocol version indicates we're running on Windows 7
(or the equivalent Windows Server 2008 R2).

Because the old mechanism was superseded, making the value configurable
doesn't have any benefit.   At some point, we will remove this old code path
entirely, including the #define MAX_NUM_CHANNELS_SUPPORTED.  The
comment with the "TODO" could be removed, but other than that, I don't
think we want to make these changes.

Michael