linux-kernel - Re: [RFC PATCH v0] Add tw5864 driver

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:	Mon, 8 Feb 2016 11:29:14 +0100
From:	Hans Verkuil <hverkuil@...all.nl>
To:	Andrey Utkin <andrey.utkin@...p.bluecherry.net>
Cc:	Linux Media <linux-media@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kernel-mentors@...enic.com" <kernel-mentors@...enic.com>,
	devel@...verdev.osuosl.org,
	kernel-janitors <kernel-janitors@...r.kernel.org>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrey Utkin <andrey.od.utkin@...il.com>
Subject: Re: [RFC PATCH v0] Add tw5864 driver

On 02/08/2016 11:23 AM, Andrey Utkin wrote:
> On Mon, Feb 8, 2016 at 11:58 AM, Hans Verkuil <hverkuil@...all.nl> wrote:
>> Hi Andrey,
>>
>> Hmm, it looks like I forgot to reply. Sorry about that.
> 
> Thank you very much anyway.
> 
>> I wouldn't change the memcpy: in my experience it is very useful to get a
>> well-formed compressed stream out of the hardware. And the overhead of
>> having to do a memcpy is a small price to pay and on modern CPUs should
>> be barely noticeable for SDTV inputs.
> 
> So there's no usecase for scatter-gather approach, right?

The only advantage scatter-gather would bring is more efficient memory usage:
dma-contig requires physically contiguous memory, dma-sg doesn't. If you need
a lot of contiguous memory you can run into out-of-memory situations. The
alternative is to build a kernel with CMA enabled and reserve memory that way.

dma-sg doesn't have these problems, so that can be a good alternative, but it
comes at the price of higher complexity.

> 
>> I don't believe that the lockups you see are related to the memcpy as
>> such. The trace says that a cpu is stuck for 22s, no way that is related
>> to something like that. It looks more like a deadlock somewhere.
> 
> There was a locking issue (lack of _irqsave) and was fixed since then.
> 
>> Regarding the compliance tests: don't pass VB2_USERPTR (doesn't work well
>> with videobuf2-dma-contig). Also add vidioc_expbuf = vb2_ioctl_expbuf for
>> the DMABUF support. That should clear up some of the errors you see.
> 
> Thank you!
> 

Regards,

	Hans