linux-kernel - RE: [PATCH] media: coda: avoid starvation on well-compressed data

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]

Date:   Fri, 21 Aug 2020 11:59:18 +0000
From:   Benjamin Bara - SKIDATA <Benjamin.Bara@...data.com>
To:     "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "mchehab@...nel.org" <mchehab@...nel.org>
CC:     "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Richard Leitner - SKIDATA" <Richard.Leitner@...data.com>
Subject: RE: [PATCH] media: coda: avoid starvation on well-compressed data

Hi!

Our CODA960 MPEG4 decoder (i.MX6) is starving with small "static" videos.
The problem seems to occur when an I frame of size > 512 is followed by
a P frame with size < 256, e.g. reproducible with a single-color video
(or any other video with little movement) and a GoP > 1.

When hunting the problem down, it seems to be related to commit
c3d996fb03c6539771ad778cd66ff5595bfc263a, concretely
the coda_bitstream_can_fetch_past [1] call in coda_fill_bitstream [2].
In the described case, the function returns true, since the I frame reaches
the 512 byte threshold, however the requirement seems to be 2x 256,
therefore the second period has not enough data with the following P frame,
which leads to a CODA PIC_RUN timeout [3] because of starvation.

The patch enqueues another buffer if the queue-tail is below the threshold.
This ensures that the second 256 byte period is filled up for the next run.

However, if the next frame(s) are also below the threshold, the same happens
in reverse order since multiple metas are required to fill the "current" period
(see failure log below).
Also in this case buffers are enqueued until the window is filled again.

This should cover all cases without looping through the active metas.

Best regards
Benjamin

[1] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/coda/coda.h#L340
[2] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/coda/coda-bit.c#L355
[3] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/coda/coda-common.c#L1540

*Failure Log*:
[   77.217862] coda 2040000.vpu: 0: active metas:
[   77.217872] coda 2040000.vpu: 0: - payload: 107
[   77.217877] coda 2040000.vpu: 0: - payload: 107
[   77.217882] coda 2040000.vpu: 0: - payload: 107
[   77.217887] coda 2040000.vpu: 0: - payload: 107
[   77.217892] coda 2040000.vpu: 0: - payload: 332
[   77.217896] coda 2040000.vpu: 0: want to queue: payload: 824
[   78.236142] coda 2040000.vpu: CODA PIC_RUN timeout