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]
Message-ID: <87vaul2rgi.fsf@vitty.brq.redhat.com>
Date:   Thu, 15 Dec 2016 15:32:29 +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:
>
>> 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).
>
> If that other cpu has interrupts disabled it may not process a pending
> msg (the response may be stuck in the host queue?), and the loop can not
> kick the other cpus queue if a wrmsrl is just valid for the current cpu.
> If thats true, the response will not arrive in the loop.
>

In case interrupts get permanently disabled on the CPU which is supposed
to receive the CHANNELMSG_UNLOAD_RESPONSE message *and* there is some
other message pedning in the slot for that CPU we'll hang. We may try to
overcome this by sending NMIs but this is getting more and more
complicated...

I'd like to see a simple fix from Hyper-V host team: always deliver
CHANNELMSG_UNLOAD_RESPONSE reply to the cpu which sent CHANNELMSG_UNLOAD
request. This would allow us to remove all the craziness.

-- 
  Vitaly

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ