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]
Date:   Thu, 15 Dec 2016 14:28:04 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Olaf Hering <olaf@...fle.de>
Cc:     kys@...rosoft.com, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, devel@...uxdriverproject.org
Subject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

Olaf Hering <olaf@...fle.de> writes:

> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
>> We actually need to read the reply and empty the message slot to make
>> unload happen. And reading on a different CPU may not work, see:
>> 
>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html
>
> Does the following sentences mean the vmbus_signal_eom in
> vmbus_wait_for_unload is a noop because the wrmsrl() is expected to
> happen on the other cpu instead of the current cpu?
>
> ...
> - When we read the message we need to clear the slot and signal the fact
>   to the hypervisor. In case there are more messages to this CPU pending
>   the hypervisor will deliver the next message. The signaling is done by
>   writing to an MSR so this can only be done on the appropriate CPU.
> ...
>

-> K. Y., but these words were written before I implemented
vmbus_wait_for_unload(), to me they just explain how we read messages.

vmbus_wait_for_unload() may be receiving a message (not necessarily the
CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same
CPU it runs and in this case wrmsrl() makes sense. In other cases it
does nothing (neither good nor bad).

-- 
  Vitaly

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ