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: <DM5PR2101MB091875296619F1518C109E71D7340@DM5PR2101MB0918.namprd21.prod.outlook.com>
Date:   Thu, 2 May 2019 22:23:36 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Juliana Rodrigueiro <juliana.rodrigueiro@...ra2net.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Hyperv netvsc - regression for 32-PAE kernel

From: Juliana Rodrigueiro <juliana.rodrigueiro@...ra2net.com> Sent: Thursday, May 2, 2019 9:14 AM
> 
> So I got to the following commit:
> 
> commit 6ba34171bcbd10321c6cf554e0c1144d170f9d1a
> Author: Michael Kelley <mikelley@...rosoft.com>
> Date:   Thu Aug 2 03:08:24 2018 +0000
> 
>     Drivers: hv: vmbus: Remove use of slow_virt_to_phys()
> 
>     slow_virt_to_phys() is only implemented for arch/x86.
>     Remove its use in arch independent Hyper-V drivers, and
>     replace with test for vmalloc() address followed by
>     appropriate v-to-p function. This follows the typical
>     pattern of other drivers and avoids the need to implement
>     slow_virt_to_phys() for Hyper-V on ARM64.
> 
>     Signed-off-by: Michael Kelley <mikelley@...rosoft.com>
>     Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> The catch is that slow_virt_to_phys has a special trick implemented in order
> to keep specifically 32-PAE kernel working, it is explained in a comment
> inside the function.
> 
> Reverting this commit makes the kernel 4.19 32-bit PAE work again. However I
> believe a better solution might exist.
> 
> Comments are very much appreciated.
> 

Julie -- thanks for tracking down the cause of the issue.  I'll try to
look at this tomorrow and propose a solution.

Michael Kelley

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ