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] [day] [month] [year] [list]
Date:   Wed, 7 Aug 2019 07:44:31 +0200
From:   Christoph Hellwig <hch@....de>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Robin Murphy <robin.murphy@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Fugang Duan <fugang.duan@....com>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 5.2 073/131] dma-direct: correct the physical addr in
 dma_direct_sync_sg_for_cpu/device

On Tue, Aug 06, 2019 at 06:04:48PM -0400, Sasha Levin wrote:
> On Tue, Aug 06, 2019 at 01:57:56PM +0100, Robin Murphy wrote:
>> Given that the two commits touch entirely separate files I'm not sure what 
>> the imagined dependency could be :/
>
>> From the commit message of 3de433c5b38a ("drm/msm: Use the correct
> dma_sync calls in msm_gem"):
>
>    Fixes the combination of two patches:
>
>    Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
>    Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
>
>> 0036bc73ccbe is indeed not a fix (frankly I'm not convinced it's even a 
>> valid change at all) but even conceptually it bears no relation whatsoever 
>> to the genuine bug fixed by 449fa54d6815.
>
> Given that Rob Clark asked me to drop 0036bc73ccbe not because it's
> irrelevant but because it's potentially dangerous, I did not feel
> confident enough ignoring the statement in the commit message and
> dropped this patch instead.

449fa54d6815 fixes swiotlb misbehaving vs the API spec for the call,
something that real users on x86 cought.  Robs fix works around the
fact that msm is badly abusing dma API.  So even if both are genuine
bugs it is pretty clear we need to decide the match for the proper
users of the API and not the single abuser.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ