Closed Bug 1743928 Opened 3 years ago Closed 3 years ago

[VA-API] The RDD process needs to use dma-buf ioctls

Categories

(Core :: Security: Process Sandboxing, defect, P1)

Product:
Core
Component:
Security: Process Sandboxing
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
97 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox94 --- unaffected
firefox95 --- unaffected
firefox96 --- disabled
firefox97 --- fixed

People

(Reporter: jld, Assigned: jld)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Bug 1743928 - Allow DMA-Buf ioctls for RDD.
48 bytes, text/x-phabricator-request
Details | Review

Found in crash-stats: a lot of crashes while trying to use DMA_BUF_IOCTL_SYNC, in the RDD process, with references to FFmpeg in the stack. I didn't observe that while testing RDD VA-API locally, and when I asked for feedback from volunteers with newer Intel GPUs I don't think any of them ran into it, but it's happening somehow. Maybe this only happens in the case of using dma-buf with a CPU-side codec?

In any case, it seems fairly obvious that we should allow the 'b' ioctls in processes that use dma-buf.

(I am not a developer, but I can mention some aspects I remember.)
bug 1629788 comment 24 implemented media.ffmpeg.dmabuf-textures as alternative upload path for software decoded video.
media.ffmpeg.dmabuf-textures.disabled is false by default (=enabled), but since some patch it has only effect when media.ffmpeg.vaapi.enabled is true.
Non-VAAPI codecs might be uploaded via dmabuf-textures then.
bug 1713276 comment 16 has an overview of decoding paths. There is an open question whether dmabuf-textures are still useful at all. It might be useful when using the operating systems' compositor (gfx.webrender.compositor.force-enabled=true disables WebRender's internal draw compositor), but I don't know.

(In reply to Darkspirit from comment #1)

(I am not a developer, but I can mention some aspects I remember.)
bug 1629788 comment 24 implemented media.ffmpeg.dmabuf-textures as alternative upload path for software decoded video.
media.ffmpeg.dmabuf-textures.disabled is false by default (=enabled), but since some patch it has only effect when media.ffmpeg.vaapi.enabled is true.
Non-VAAPI codecs might be uploaded via dmabuf-textures then.
bug 1713276 comment 16 has an overview of decoding paths. There is an open question whether dmabuf-textures are still useful at all. It might be useful when using the operating systems' compositor (gfx.webrender.compositor.force-enabled=true disables WebRender's internal draw compositor), but I don't know.

That's correct. When VA-API decode path is enabled we use VA-API directly for supported formats and SW decode + dmabuf texture upload for unsupported formats. This does not apply to AV1 which is decoded by DAV1DDecoder. So you will see SW decode + dmabuf texture upload on hardware which does not support VP8/9 like AMD gpu.

To test dmabuf without VA-API you need to set mUseDMABufSurfaces to true at:
https://searchfox.org/mozilla-central/rev/3d03a3ca09f03f06ef46a511446537563f62a0c6/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#342

Alternative STR:

  1. Enable media.ffmpeg.vaapi.enabled
  2. Uninstall the VAAPI driver:
    $ ls /usr/lib/x86_64-linux-gnu/dri/*drv*
    $ sudo apt remove intel-media-va-driver i965-va-driver mesa-va-drivers
  3. Restart Nightly and watch a video
$ firefox/firefox
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
Sandbox: seccomp sandbox violation: pid 28914, tid 29017, syscall 16, args 6 1074291200 140478228689592 140478720195120 0 0.  Killing process.
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
Sandbox: seccomp sandbox violation: pid 29036, tid 29054, syscall 16, args 8 1074291200 140490616283832 140491108079664 0 0.  Killing process.
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
[Child 28786, MediaDecoderStateMachine #1] WARNING: Decoder=7fdd5321c200 Decode error: NS_ERROR_OUT_OF_MEMORY (0x8007000e): file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:3568
[Child 28786, MediaDecoderStateMachine #1] WARNING: Decoder=7fdd5321c200 Decode error: NS_ERROR_OUT_OF_MEMORY (0x8007000e): file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:3568
[Child 28786, MediaDecoderStateMachine #1] WARNING: Decoder=7fdd5321c200 Decode error: NS_ERROR_OUT_OF_MEMORY (0x8007000e): file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:3568
Crash Signature: [@ __GI___ioctl_time64 ] [@ __ioctl ] → [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ]
Keywords: crash
Crash Signature: [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ] → [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ] [@ mozilla::PRDDChild::OtherPid ]

This signature is 95% of all Linux crashes in the December 8th Nightlies.

In some cases (doing video decode on the CPU and uploading the result
with dmabuf) we'll need to use DMA_BUF_IOCTL_SYNC in the RDD process.
This patch allows that ioctl type ('b', used only by dmabuf and Android
binder; the latter doesn't apply on Desktop), for forward compatibility
with any future usage of dmabuf ioctls.

See Also: → 1746232

The severity field is not set for this bug.
:gcp, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gpascutto)
Severity: -- → S2
Flags: needinfo?(gpascutto)
Priority: -- → P1
Crash Signature: [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ] [@ mozilla::PRDDChild::OtherPid ] → [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ] [@ libc.so.6@0xfe2c7 | DMABufSurface::MapInternal ] [@ libc.so.6@0xf5e6b | DMABufSurface::MapInternal ] [@ mozilla::PRDDChild::OtherPid ]
Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d92b2e2b96e8 Allow DMA-Buf ioctls for RDD. r=stransky,alwu

https://hg.mozilla.org/mozilla-central/rev/d92b2e2b96e8

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox97: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Crash Signature: [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ] [@ libc.so.6@0xfe2c7 | DMABufSurface::MapInternal ] [@ libc.so.6@0xf5e6b | DMABufSurface::MapInternal ] [@ mozilla::PRDDChild::OtherPid ] → [@ __GI___ioctl_time64 ] [@ __ioctl ] [@ libc.so.6@0xf1b77 | DMABufSurface::MapInternal ] [@ libc.so.6@0xfe2c7 | DMABufSurface::MapInternal ] [@ libc.so.6@0xf5e6b | DMABufSurface::MapInternal ] [@ libc.so.6@0xf51b7 | DMABufSurface::MapInternal ] [@ …

:stransky, the crash with signature mozilla::PRDDChild::OtherPid has reappeared recently.

Flags: needinfo?(stransky)

(In reply to Calixte Denizet (:calixte) from comment #9)

:stransky, the crash with signature mozilla::PRDDChild::OtherPid has reappeared recently.

Dupe of Bug 1751709?

Flags: needinfo?(stransky)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: