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

drivers: hv: Turn off write permission on the hypercall page

2017-03-15T02:02:52+00:00

commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 upstream.

The hypercall page only needs to be executable but currently it is setup to
be writable as well. Fix the issue.

Signed-off-by: K. Y. Srinivasan 
Acked-by: Kees Cook 
Reported-by: Stephen Hemminger 
Tested-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: Backup: Fix a rescind processing issue

2017-03-12T05:41:50+00:00

commit d77044d142e960f7b5f814a91ecb8bcf86aa552c upstream.

VSS may use a char device to support the communication between
the user level daemon and the driver. When the VSS channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new VSS offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: Fcopy: Fix a rescind processing issue

2017-03-12T05:41:50+00:00

commit 20951c7535b5e6af46bc37b7142105f716df739c upstream.

Fcopy may use a char device to support the communication between
the user level daemon and the driver. When the Fcopy channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new Fcopy offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: kvp: Fix a rescind processing issue

2017-03-12T05:41:49+00:00

commit 5a66fecbf6aa528e375cbebccb1061cc58d80c84 upstream.

KVP may use a char device to support the communication between
the user level daemon and the driver. When the KVP channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new KVP offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Fix a rescind handling bug

2017-03-12T05:41:49+00:00

commit ccb61f8a99e6c29df4fb96a65dad4fad740d5be9 upstream.

The host can rescind a channel that has been offered to the
guest and once the channel is rescinded, the host does not
respond to any requests on that channel. Deal with the case where
the guest may be blocked waiting for a response from the host.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Prevent sending data on a rescinded channel

2017-03-12T05:41:49+00:00

commit e7e97dd8b77ee7366f2f8c70a033bf5fa05ec2e0 upstream.

After the channel is rescinded, the host does not read from the rescinded channel.
Fail writes to a channel that has already been rescinded. If we permit writes on a
rescinded channel, since the host will not respond we will have situations where
we will be unable to unload vmbus drivers that cannot have any outstanding requests
to the host at the point they are unoaded.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

hv: don't reset hv_context.tsc_page on crash

2017-03-12T05:41:49+00:00

commit 56ef6718a1d8d77745033c5291e025ce18504159 upstream.

It may happen that secondary CPUs are still alive and resetting
hv_context.tsc_page will cause a consequent crash in read_hv_clock_tsc()
as we don't check for it being not NULL there. It is safe as we're not
freeing this page anyways.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

hv: init percpu_list in hv_synic_alloc()

2017-03-12T05:41:49+00:00

commit 3c7630d35009e6635e5b58d62de554fd5b6db5df upstream.

Initializing hv_context.percpu_list in hv_synic_alloc() helps to prevent a
crash in percpu_channel_enq() when not all CPUs were online during
initialization and it naturally belongs there.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

hv: allocate synic pages for all present CPUs

2017-03-12T05:41:49+00:00

commit 421b8f20d3c381b215f988b42428f56fc3b82405 upstream.

It may happen that not all CPUs are online when we do hv_synic_alloc() and
in case more CPUs come online later we may try accessing these allocated
structures.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

2017-03-12T05:41:47+00:00

commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8 upstream.

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 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman