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>] [day] [month] [year] [list]
Message-ID: <TYAPR01MB6201716571D23E09CC436555922E9@TYAPR01MB6201.jpnprd01.prod.outlook.com>
Date:   Mon, 24 Oct 2022 04:27:26 +0000
From:   <yuji2.ishikawa@...hiba.co.jp>
To:     <posciak@...omium.org>, <paul.kocialkowski@...tlin.com>,
        <hverkuil-cisco@...all.nl>, <mchehab+samsung@...nel.org>,
        <linux-media@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Question for an accepted patch: use of DMA-BUF based videobuf2
 capture buffer with no-HW-cache-coherent HW

Hi,
I'm porting a V4L2 capture driver from 4.19.y to 5.10.y [1].
When I test the ported driver, I sometimes find a corruption on a captured image.
Because the corruption is exactly aligned with cacheline, I started investigation from map/unmap of DMA-BUF.

The capture driver uses DMA-BUF for videobuf2.
The capture hardware does not have HW-mantained cache coherency with CPU, that is, explicit map/unmap is essential on QBUF/DQBUF.
After some hours of struggle, I found a patch removing cache synchronizations on QBUF/DQBUF.

https://patchwork.kernel.org/project/linux-media/patch/20190124095156.21898-1-paul.kocialkowski@bootlin.com/

When I removed this patch from my 5.10.y working-tree, the driver yielded images without any defects.

***************
Sorry for a mention to a patch released 4 years ago.
The patch removes map/unmap on QBUF/DQBUF to improve the performance of V4L2 decoder device, by reusing previously decoded frames.
However, there seems no cares nor compensations for modifying lifecycle of DMA-BUF, especially on video capture devices.

Would you tell me some idea on this patch:
* Do well-implemented capture drivers work well even if this patch is applied?
* How should a video capture driver call V4L2/videobuf2 APIs, especially when the hardware does not support cache coherency?

***************
[1] FYI: the capture driver is not on mainline yet; the candidate is,
https://lore.kernel.org/all/20220810132822.32534-1-yuji2.ishikawa@toshiba.co.jp/

***************
Sorry for sending the same email message again. I wrongly posted previous one with HTML format.

Regards,
              Yuji Ishikawa

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ