linux-toradex.git/drivers/hv, branch v4.20

Merge tag 'hyperv-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux into char-misc-linus

2018-12-14T14:36:56+00:00

Sasha writes:

hyperv-fixes-4.20-rc6

* tag 'hyperv-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
  Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels
  x86, hyperv: remove PCI dependency

Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels

2018-12-13T19:58:27+00:00

Before 98f4c651762c, we returned zeros for unopened channels.
With 98f4c651762c, we started to return random on-stack values.

We'd better return -EINVAL instead.

Fixes: 98f4c651762c ("hv: move ringbuffer bus attributes to dev_groups")
Cc: stable@vger.kernel.org
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Signed-off-by: Dexuan Cui 
Signed-off-by: Sasha Levin

x86, hyperv: remove PCI dependency

2018-12-13T19:55:57+00:00

Need to be able to boot without PCI devices present.

Signed-off-by: Sinan Kaya 
Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-12-03T07:01:01+00:00

vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.

The above is also true for primary channels, if the related device
drivers use sync probing mode by default.

And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.

The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).

The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.

So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.

Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Signed-off-by: Dexuan Cui 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()

2018-11-26T19:33:56+00:00

This is a longstanding issue: if the vmbus upper-layer drivers try to
consume too many GPADLs, the host may return with an error
0xC0000044 (STATUS_QUOTA_EXCEEDED), but currently we forget to check
the creation_status, and hence we can pass an invalid GPADL handle
into the OPEN_CHANNEL message, and get an error code 0xc0000225 in
open_info->response.open_result.status, and finally we hang in
vmbus_open() -> "goto error_free_info" -> vmbus_teardown_gpadl().

With this patch, we can exit gracefully on STATUS_QUOTA_EXCEEDED.

Cc: Stephen Hemminger 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: stable@vger.kernel.org
Signed-off-by: Dexuan Cui 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-11-11T17:00:20+00:00

In kvp_send_key(), we do need call process_ib_ipinfo() if
message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
the userland hv_kvp_daemon needs the info of operation, adapter_id and
addr_family. With the incorrect fc62c3b1977d, the host can't get the
VM's IP via KVP.

And, fc62c3b1977d added a "break;", but actually forgot to initialize
the key_size/value in the case of KVP_OP_SET, so the default key_size of
0 is passed to the kvp daemon, and the pool files
/var/lib/hyperv/.kvp_pool_* can't be updated.

This patch effectively rolls back the previous fc62c3b1977d, and
correctly fixes the "this statement may fall through" warnings.

This patch is tested on WS 2012 R2 and 2016.

Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall through" warnings")
Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Stephen Hemminger 
Signed-off-by: Haiyang Zhang 
Cc: 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

hv_balloon: Replace spin_is_locked() with lockdep

2018-10-15T18:54:17+00:00

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Reviewed-by: Vitaly Kuznetsov 
Signed-off-by: Greg Kroah-Hartman

Merge 4.19-rc7 into char-misc-next

2018-10-08T13:33:21+00:00

We want the fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Use cpumask_var_t for on-stack cpu mask

2018-10-02T22:37:01+00:00

A cpumask structure on the stack can cause a warning with
CONFIG_NR_CPUS=8192 (e.g. Ubuntu 16.04 and 18.04 use this):

drivers/hv//channel_mgmt.c: In function ‘init_vp_index’:
drivers/hv//channel_mgmt.c:702:1: warning: the frame size of 1032 bytes
  is larger than 1024 bytes [-Wframe-larger-than=]

Nowadays it looks most distros enable CONFIG_CPUMASK_OFFSTACK=y, and
hence we can work around the warning by using cpumask_var_t.

Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: kvp: Fix two "this statement may fall through" warnings

2018-10-02T22:37:01+00:00

We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is
KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on
the op code from the host to the userspace; when the userspace returns
the info requested by the host, we pass the info on to the host in
kvp_respond_to_host() -> process_ob_ipinfo(). BTW, the current buggy code
actually doesn't cause any harm, because only message->kvp_hdr.operation
is used by the userspace, in the case of KVP_OP_GET_IP_INFO.

The patch also adds a missing "break;" in kvp_send_key(). BTW, the current
buggy code actually doesn't cause any harm, because in the case of
KVP_OP_SET, the unexpected fall-through corrupts
message->body.kvp_set.data.key_size, but that is not really used: see
the definition of struct hv_kvp_exchg_msg_value.

Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman