Closed Bug 1624743 Opened 5 years ago Closed 5 years ago

Crash in radeonsi_dri.so — kcmp in amdgpu driver

Categories

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

Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- disabled
firefox75 --- disabled
firefox76 --- fixed

People

(Reporter: gsvelto, Assigned: jld)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-56c5bc83-28b4-47cb-bdbc-811680200320.

Top 10 frames of crashing thread:

0 libc-2.31.so libc-2.31.so@0xfc29d 
1 radeonsi_dri.so <name omitted> ../src/util/os_file.c:141
2 radeonsi_dri.so <name omitted> ../src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:383
3 radeonsi_dri.so radeonsi_dri.so@0x27e0ef 
4 radeonsi_dri.so _fini 
5 radeonsi_dri.so _fini 
6 radeonsi_dri.so <name omitted> ../src/gallium/drivers/radeonsi/si_pipe.c:1349
7 radeonsi_dri.so <name omitted> ../src/gallium/auxiliary/target-helpers/drm_helper.h:169
8 radeonsi_dri.so <name omitted> ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:128
9 radeonsi_dri.so dri2_init_screen ../src/gallium/state_trackers/dri/dri2.c:2069

This is a new crash coming from Fedora 32. Unfortunately we haven't better symbols for this - yet. This looks like a sandbox problem. The crash reason is SIGSYS with syscall number 0x138. That's the kcmp syscall if I'm not mistaken.

See also bug 1619585 comment #34 (and the crash reports in bug 1619585 comment #31). But I think that's not actually about VA-API — the reporter there mentions that it reproduces with a clean profile, and I think VA-API support is still preffed off by default? And the Mesa merge request that added this call doesn't look like it's inherently specific to VA-API (but there's a comment about the cause being two different subsystems in the same process both using the same GPU, so maybe it's related).

Assignee: nobody → jld
Priority: -- → P1
Summary: Crash in [@ libc-2.31.so@0xfc29d | <name omitted> | <name omitted> | radeonsi_dri.so@0x27e0ef] → Crash in radeonsi_dri.so — kcmp in amdgpu driver

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #1)

And [the Mesa merge request that added this call][3202] doesn't look like it's inherently specific to VA-API (but there's a comment about the cause being two different subsystems in the same process both using the same GPU, so maybe it's related).

You're right, it's not VA-API specific. Mesa needs kcmp(KCM_FILE) when it's asked to create multiple contexts for the same GPU using different DRM file descriptors in the same process, to determine if those file descriptors reference the same or different file descriptions. VA-API & GL is just probably the most common scenario where this happens.

Crash Signature: [@ libc-2.31.so@0xfc29d | <name omitted> | <name omitted> | radeonsi_dri.so@0x27e0ef] → [@ libc-2.31.so@0xfc29d | <name omitted> | <name omitted> | radeonsi_dri.so@0x27e0ef] [@ syscall ] [@ libc.so.6@0xf9f8d | libgallium_dri.so@0x47d6a8 ] [@ libc.so.6@0xf9f8d | libgallium_dri.so@0x8eebf8 ] [@ libc-2.31.so@0xfc29d | radeonsi_dri.so@0x845d…

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #1)

See also bug 1619585 comment #34 (and the crash reports in bug 1619585 comment #31). But I think that's not actually about VA-API — the reporter there mentions that it reproduces with a clean profile, and I think VA-API support is still preffed off by default? And [the Mesa merge request that added this call][3202] doesn't look like it's inherently specific to VA-API (but there's a comment about the cause being two different subsystems in the same process both using the same GPU, so maybe it's related).

I used a clean profile for avoid any conflicts with my settings, extensions etc... With this clean profile, the only settings manually enabled was the va-api related switches.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Crash Signature: radeonsi_dri.so@0x845d5a ] [@ libc-2.31.so@0xfc29d | <name omitted> | <name omitted> | radeonsi_dri.so@0x27e0bf ] [@ libc.so.6@0xfc29d | libgallium_dri.so@0x4602fa ] [@ libc.so.6@0xf9f8d | libgallium_dri.so@0x4c217c ] → radeonsi_dri.so@0x845d5a ] [@ libc-2.31.so@0xfc29d | <name omitted> | <name omitted> | radeonsi_dri.so@0x27e0bf ] [@ libc.so.6@0xfc29d | libgallium_dri.so@0x4602fa ] [@ libc.so.6@0xf9f8d | libgallium_dri.so@0x4c217c ] [@ syscall | std::vector<T>::ope…
Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d8f40a8e912d Allow intra-process kcmp with KCMP_FILE in Linux content sandbox for amdgpu. r=gcp
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: