linux-kernel - Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list

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, 14 Mar 2023 09:55:10 +0100
From:   Hans Verkuil <hverkuil-cisco@...all.nl>
To:     David Laight <David.Laight@...LAB.COM>,
        'Laurent Pinchart' <laurent.pinchart@...asonboard.com>,
        Benjamin Gaignard <benjamin.gaignard@...labora.com>
Cc:     "tfiga@...omium.org" <tfiga@...omium.org>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "ming.qian@....com" <ming.qian@....com>,
        "shijie.qin@....com" <shijie.qin@....com>,
        "eagle.zhou@....com" <eagle.zhou@....com>,
        "bin.liu@...iatek.com" <bin.liu@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "tiffany.lin@...iatek.com" <tiffany.lin@...iatek.com>,
        "andrew-ct.chen@...iatek.com" <andrew-ct.chen@...iatek.com>,
        "yunfei.dong@...iatek.com" <yunfei.dong@...iatek.com>,
        "stanimir.k.varbanov@...il.com" <stanimir.k.varbanov@...il.com>,
        "quic_vgarodia@...cinc.com" <quic_vgarodia@...cinc.com>,
        "agross@...nel.org" <agross@...nel.org>,
        "andersson@...nel.org" <andersson@...nel.org>,
        "konrad.dybcio@...aro.org" <konrad.dybcio@...aro.org>,
        "ezequiel@...guardiasur.com.ar" <ezequiel@...guardiasur.com.ar>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "daniel.almeida@...labora.com" <daniel.almeida@...labora.com>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-rockchip@...ts.infradead.org" 
        <linux-rockchip@...ts.infradead.org>,
        "kernel@...labora.com" <kernel@...labora.com>
Subject: Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list

On 14/03/2023 00:16, David Laight wrote:
> From: Laurent Pinchart
>> Sent: 13 March 2023 18:12
>>
>> Hi Benjamin,
>>
>> Thank you for the patch.
>>
>> On Mon, Mar 13, 2023 at 02:59:14PM +0100, Benjamin Gaignard wrote:
>>> Replacing bufs array by a list allows to remove the 32 buffers
>>> limit per queue.
> 
> Is the limit actually a problem?
> Arrays of pointers have locking and caching advantages over
> linked lists.

I'm not so keen on using a list either. Adding or deleting buffers will
be an infrequency operation, so using an array of pointers and reallocing
it if needed would be perfectly fine. Buffer lookup based on the index
should be really fast, though.

Why not start with a dynamically allocated array of 32 vb2_buffer pointers?
And keep doubling the size (reallocing) whenever more buffers are needed,
up to some maximum (1024 would be a good initial value for that, I think).
This max could be even a module option.

A simple spinlock is sufficient, I think, to regulate access to the
struct vb2_buffer **bufs pointer in vb2_queue. From what I can see it is
not needed in interrupt context (i.e. vb2_buffer_done).

Regards,

	Hans

> 
> ...
>>> @@ -1239,8 +1242,12 @@ static inline void vb2_clear_last_buffer_dequeued(struct vb2_queue *q)
>>>  static inline struct vb2_buffer *vb2_get_buffer(struct vb2_queue *q,
>>>  						unsigned int index)
>>>  {
>>> -	if (index < q->num_buffers)
>>> -		return q->bufs[index];
>>> +	struct vb2_buffer *vb;
>>> +
>>> +	list_for_each_entry(vb, &q->allocated_bufs, allocated_entry)
>>> +		if (vb->index == index)
>>> +			return vb;
>>> +
>>>  	return NULL;
> 
> You really don't want to be doing that....
> 
> There are schemes for unbounded arrays.
> Scanning a linked list isn't a very good one.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)