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:   Tue, 9 Feb 2021 07:58:35 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     hch@....de, m.szyprowski@...sung.com, robin.murphy@....com,
        iommu@...ts.linux-foundation.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        obayashi.yoshimasa@...ionext.com
Subject: Re: DMA direct mapping fix for 5.4 and earlier stable branches

On Tue, Feb 09, 2021 at 11:39:25AM +0530, Sumit Garg wrote:
> Hi Christoph, Greg,
> 
> Currently we are observing an incorrect address translation
> corresponding to DMA direct mapping methods on 5.4 stable kernel while
> sharing dmabuf from one device to another where both devices have
> their own coherent DMA memory pools.

What devices have this problem?  And why can't then just use 5.10 to
solve this issue as that problem has always been present for them,
right?

> I am able to root cause this issue which is caused by incorrect virt
> to phys translation for addresses belonging to vmalloc space using
> virt_to_page(). But while looking at the mainline kernel, this patch
> [1] changes address translation from virt->to->phys to dma->to->phys
> which fixes the issue observed on 5.4 stable kernel as well (minimal
> fix [2]).
> 
> So I would like to seek your suggestion for backport to stable kernels
> (5.4 or earlier) as to whether we should backport the complete
> mainline commit [1] or we should just apply the minimal fix [2]?

Whenever you try to create a "minimal" fix, 90% of the time it is wrong
and does not work and I end up having to deal with the mess.  What
prevents you from doing the real thing here?  Are the patches to big?

And again, why not just use 5.10 for this hardware?  What hardware is
it?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ