linux-kernel - Re: [PATCH v4 2/2] dma: add IOMMU static calls with clear default ops

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <181e06ff-35a3-434f-b505-672f430bd1cb@notapiano>
Date: Tue, 10 Sep 2024 15:01:05 -0400
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Robin Murphy <robin.murphy@....com>,
	Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Leon Romanovsky <leonro@...dia.com>,
	Easwar Hariharan <eahariha@...ux.microsoft.com>,
	linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
	Jason Gunthorpe <jgg@...dia.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	regressions@...ts.linux.dev, kernelci@...ts.linux.dev,
	kernel@...labora.com
Subject: Re: [PATCH v4 2/2] dma: add IOMMU static calls with clear default ops

On Wed, Jul 24, 2024 at 09:04:49PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@...dia.com>
> 
> Most of the arch DMA ops (which often, but not always, involve
> some sort of IOMMU) are using the same DMA operations, but for all
> modern platforms dma-iommu implementation is really matters.
> 
> So let's make sure to call them directly without need to perform
> function pointers dereference.
> 
> During system initialization, the arch can set its own DMA and in such
> case, the default DMA operations will be overridden.
> 
> Signed-off-by: Leon Romanovsky <leonro@...dia.com>
> Signed-off-by: Leon Romanovsky <leon@...nel.org>

Hi,

KernelCI has identified another regression originating from this patch. It
affects the same platforms:
* sc7180-trogdor-kingoftown
* sc7180-trogdor-lazor-limozeen

But this time the issue is that the venus video codecs are failing to probe as
indicated by the DT kselftest:

  not ok 184 /soc@...ideo-codec@...0000
  ok 185 /soc@...ideo-codec@...0000/opp-table # SKIP
  not ok 186 /soc@...ideo-codec@...0000/video-decoder
  not ok 187 /soc@...ideo-codec@...0000/video-encoder

The kernel logs show the error:

  qcom-venus aa00000.video-codec: probe with driver qcom-venus failed with error -5

A quick ftrace run showed that the error comes from dma_set_mask_and_coherent()
in venus_probe():

  7)               |  venus_probe() {
  ...
  7)               |    dma_set_mask() {
  7)               |      dma_supported() {
  7)   0.989 us    |        dma_direct_supported(); /* = 0x0 */
  7)   2.864 us    |      } /* dma_supported = 0x0 */
  7)   4.636 us    |    } /* dma_set_mask = -5 */

For comparison, here is the ftrace run with the commit reverted:

  7)               |  venus_probe() {
  ...
  7)   1.093 us    |    dma_set_mask(); /* = 0x0 */
  7)   1.041 us    |    dma_set_coherent_mask(); /* = 0x0 */

The issue is still present as of next-20240909 and reverting this commit fixes
it.

Happy to provide any other details necessary.

Please add
Reported-by: Nícolas F. R. A. Prado <nfraprado@...labora.com> #KernelCI
when fixing this.

#regzbot introduced: next-20240822..20240823
#regzbot title: Venus codec probe regression for sc7180 platforms in dma_set_mask_and_coherent()

Thanks,
Nícolas