Re: [PATCH] media: dvb-core: add upper bound check in DMX_SET_BUFFER_SIZE ioctl

[Cen Zhang (Microsoft)]

Hi Mauro,

> Forgot to mention, but instead of returning -EINVAL, probably the best
> would be to setup the ringbuffer size to the maximum value, as
> otherwise this would break existing apps.

Thanks for pointing this out. I will revise this in v3.

> Having a limit is good, but why 64MB?
>
> Btw, what apps did you use to test it? Had you check what's the current
> limit on what apps?

I chose 64 MiB as a conservative upper bound based on a brief source
survey of DVB applications:

- The kernel DVR buffer defaults to approximately 1.84 MiB. In the
  upstream revisions I checked, TVheadend, MythTV and MuMuDVB do not
  actively call DMX_SET_BUFFER_SIZE and therefore retain this default:

https://github.com/torvalds/linux/blob/acb7500801e98639f6d8c2d796ed9f64cba83d3a/include/media/dmxdev.h#L189

- SATPI allows approximately 30 MiB:

https://github.com/Barracuda09/SATPI/blob/09df7402870b1dff2c7b2d7f4a085002a333045f/src/input/dvb/Frontend.cpp#L57

- DVBlast defaults to approximately 7.34 MiB:

https://github.com/videolan/dvblast/blob/ae6b24ae8cdf6eaa1ada8534a257258f3c906a77/dvb.c#L71

- dvbv5-zap uses approximately 5.88 MiB:

https://github.com/gjasny/v4l-utils/blob/95ad25f6a77a0a6650f5f657ac2c5046efcd04a0/utils/dvb/dvbv5-zap.c#L32

- minisatip defaults to approximately 5.51 MiB:

https://github.com/catalinii/minisatip/blob/d20136e23d47bd7f5de2967b34463f14bce6f988/src/adapter.h#L12

I have limited experience with DVB hardware and production workloads.
Do you have a recommended limit based on known hardware or application
requirements? I am happy to use the value you recommend in v3.

> Can you provide me more details about the test scenario: e.g. with
> what TV standards had you test it, and such.

The reproducer used the vidtv virtual DVB adapter
(dvb-vidtv-bridge) in a QEMU VM with approximately 3 GiB of RAM. The
root-only setup loaded the driver, made dvr0 accessible and set
oom_score_adj=-1000 for the process lineage to make the panic
deterministic. The ioctl itself was issued by an unprivileged process.

The test did not exercise a particular TV standard or transport stream,
since the failure occurs directly in the buffer-allocation ioctl path
before stream processing. I have not tested this on physical DVB
hardware.

I can share the reproducer package privately if that would be useful.

Best regards,
Cen