linux-toradex.git/drivers/hv/hv_utils_transport.c, branch v4.14

Drivers: hv: util: move waiting for release to hv_utils_transport itself

2017-03-16T07:42:00+00:00

Waiting for release_event in all three drivers introduced issues on release
as on_reset() hook is not always called. E.g. if the device was never
opened we will never get the completion.

Move the waiting code to hvutil_transport_destroy() and make sure it is
only called when the device is open. hvt->lock serialization should
guarantee the absence of races.

Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue")
Fixes: 20951c7535b5 ("Drivers: hv: util: Fcopy: Fix a rescind processing issue")
Fixes: d77044d142e9 ("Drivers: hv: util: Backup: Fix a rescind processing issue")

Reported-by: Dexuan Cui 
Tested-by: Dexuan Cui 
Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: utils: fix a race on userspace daemons registration

2016-08-31T11:05:41+00:00

Background: userspace daemons registration protocol for Hyper-V utilities
drivers has two steps:
1) daemon writes its own version to kernel
2) kernel reads it and replies with module version
at this point we consider the handshake procedure being completed and we
do hv_poll_channel() transitioning the utility device to HVUTIL_READY
state. At this point we're ready to handle messages from kernel.

When hvutil_transport is in HVUTIL_TRANSPORT_CHARDEV mode we have a
single buffer for outgoing message. hvutil_transport_send() puts to this
buffer and till the buffer is cleared with hvt_op_read() returns -EFAULT
to all consequent calls. Host<->guest protocol guarantees there is no more
than one request at a time and we will not get new requests till we reply
to the previous one so this single message buffer is enough.

Now to the race. When we finish negotiation procedure and send kernel
module version to userspace with hvutil_transport_send() it goes into the
above mentioned buffer and if the daemon is slow enough to read it from
there we can get a collision when a request from the host comes, we won't
be able to put anything to the buffer so the request will be lost. To
solve the issue we need to know when the negotiation is really done (when
the version message is read by the daemon) and transition to HVUTIL_READY
state after this happens. Implement a callback on read to support this.
Old style netlink communication is not affected by the change, we don't
really know when these messages are delivered but we don't have a single
message buffer there.

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

Drivers: hv: utils: Remove util transport handler from list if registration fails

2016-03-02T00:57:20+00:00

If util transport fails to initialize for any reason, the list of transport
handlers may become corrupted due to freeing the transport handler without
removing it from the list. Fix this by cleaning it up from the list.

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

Drivers: hv: utils: fix hvt_op_poll() return value on transport destroy

2015-12-21T21:14:56+00:00

The return type of hvt_op_poll() is unsigned int and -EBADF is
inappropriate, poll functions return POLL* statuses.

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

Drivers: hv: utils: fix crash when device is removed from host side

2015-12-15T03:27:30+00:00

The crash is observed when a service is being disabled host side while
userspace daemon is connected to the device:

[   90.244859] general protection fault: 0000 [#1] SMP
...
[   90.800082] Call Trace:
[   90.800082]  [] __fput+0xc8/0x1f0
[   90.800082]  [] ____fput+0xe/0x10
...
[   90.800082]  [] do_signal+0x28/0x580
[   90.800082]  [] ? finish_task_switch+0xa6/0x180
[   90.800082]  [] ? __schedule+0x28f/0x870
[   90.800082]  [] ? hvt_op_read+0x12a/0x140 [hv_utils]
...

The problem is that hvutil_transport_destroy() which does misc_deregister()
freeing the appropriate device is reachable by two paths: module unload
and from util_remove(). While module unload path is protected by .owner in
struct file_operations util_remove() path is not. Freeing the device while
someone holds an open fd for it is a show stopper.

In general, it is not possible to revoke an fd from all users so the only
way to solve the issue is to defer freeing the hvutil_transport structure.

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

Drivers: hv: utils: introduce HVUTIL_TRANSPORT_DESTROY mode

2015-12-15T03:27:30+00:00

When Hyper-V host asks us to remove some util driver by closing the
appropriate channel there is no easy way to force the current file
descriptor holder to hang up but we can start to respond -EBADF to all
operations asking it to exit gracefully.

As we're setting hvt->mode from two separate contexts now we need to use
a proper locking.

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

Drivers: hv: utils: rename outmsg_lock

2015-12-15T03:27:30+00:00

As a preparation to reusing outmsg_lock to protect test-and-set openrations
on 'mode' rename it the more general 'lock'.

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

Drivers: hv: utils: fix memory leak on on_msg() failure

2015-12-15T03:27:30+00:00

inmsg should be freed in case of on_msg() failure to avoid memory leak.
Preserve the error code from on_msg().

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

Drivers: hv: utils: use memdup_user in hvt_op_write

2015-12-15T03:12:21+00:00

Use memdup_user to handle OOM.

Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction')

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

Drivers: hv: util: catch allocation errors

2015-12-15T03:12:21+00:00

Catch allocation errors in hvutil_transport_send.

Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction')

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