Crash in radeonsi_dri.so — kcmp in amdgpu driver
Categories
(Core :: Security: Process Sandboxing, defect, P1)
Tracking
()
| 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.
|
Assignee | |
Comment 1•4 years ago
|
||
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).
|
||
Comment 2•4 years ago
|
||
(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.
|
||
Updated•4 years ago
|
|
|
||
Comment 6•4 years ago
|
||
(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.
|
||
Comment 8•4 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
|
Reporter | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 9•4 years ago
|
||
|
||
Comment 10•4 years ago
|
||
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
|
||
Comment 11•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
Description
•