linux-kernel - Re: [PATCH v6 11/17] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT

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]

Message-ID: <763308daa3304ef3cf011b4ca7b9c5c006627c90.camel@collabora.com>
Date:   Wed, 01 Jun 2022 13:07:54 -0400
From:   Nicolas Dufresne <nicolas.dufresne@...labora.com>
To:     Jernej Škrabec <jernej.skrabec@...il.com>,
        mchehab@...nel.org, ezequiel@...guardiasur.com.ar,
        p.zabel@...gutronix.de, gregkh@...uxfoundation.org,
        mripard@...nel.org, paul.kocialkowski@...tlin.com, wens@...e.org,
        samuel@...lland.org, andrzej.p@...labora.com,
        Hans Verkuil <hverkuil@...all.nl>,
        Benjamin Gaignard <benjamin.gaignard@...labora.com>
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-rockchip@...ts.infradead.org, linux-staging@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        kernel@...labora.com
Subject: Re: [PATCH v6 11/17] media: uapi: Add
 V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS control

Le mercredi 01 juin 2022 à 18:35 +0200, Jernej Škrabec a écrit :
> > I believe its defined following "Table A.8 – General tier and level limits".
> > With the assumption there will never be a level 7 (which I think is fair).
> > If anyone saw other reasons for this limit, let me know.
> > 
> > This is a worse case scenario, this is quite unlikely in practice, so while
> > performance might be a disaster if your craft a stream for that case, I
> > don't think it will ever happen in real life.
> 
> But do we really need to cover worst case scenario? In theory, one driver can 
> set limit to (for example) max 100 slices and if there is a frame with 600 
> slices, userspace app would submit 6 decode requests. Basically the same way 
> it's done today. While not as performant, it would be good compromise between 
> resources and speed.

The limit here is to prevent userland from tricking the kernel into doing very
big allocation. But with dynamic array, you'll allocate just the right amount.

Nicolas