linux-kernel - [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-next>] [day] [month] [year] [list]

Date:   Sat,  5 Dec 2020 18:26:47 +0100
From:   Stefan Eschenbacher <stefan.eschenbacher@....de>
To:     "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>
Cc:     Stefan Eschenbacher <stefan.eschenbacher@....de>,
        linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kernel@...cs.fau.de, Max Stolze <max.stolze@....de>
Subject: [PATCH 0/3] drivers/hv: make max_num_channels_supported configurable

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