I'm getting this crash during dmabuf init() due to disabled getpwuid_r access:

#0  0x00007f496d7d567d in __GI___nss_lookup_function (fct_name=0x7f496d8587dc "getpwuid_r", ni=<optimized out>) at nsswitch.c:136
#1  __GI___nss_lookup (ni=ni@entry=0x7f4948296f68, fct_name=fct_name@entry=0x7f496d8587dc "getpwuid_r", fct2_name=fct2_name@entry=0x0, fctp=fctp@entry=0x7f4948296f70) at nsswitch.c:68
#2  0x00007f496d7d6927 in __GI___nss_passwd_lookup2
    (ni=ni@entry=0x7f4948296f68, fct_name=fct_name@entry=0x7f496d8587dc "getpwuid_r", fct2_name=fct2_name@entry=0x0, fctp=fctp@entry=0x7f4948296f70)
    at /usr/src/debug/glibc-2.34-12.fc35.x86_64/nss/XXX-lookup.c:58
#3  0x00007f496d776655 in __getpwuid_r
    (uid=1000, resbuf=resbuf@entry=0x7f4948296ff0, buffer=buffer@entry=0x7f493fc2f130 '\344' <repeats 199 times>, <incomplete sequence \344>..., buflen=buflen@entry=1024, result=result@entry=0x7f4948296fe8) at ../nss/getXXbyYY_r.c:265
#4  0x00007f494606375f in disk_cache_generate_cache_dir
    (mem_ctx=0x7f493fc14910, gpu_name=0x7f49471c7462 "DIMGREY_CAVEFISH", driver_id=0x7f4948297210 "35ce1a9f39e7eb63fad8b9baa8509357ea7a14e0") at ../src/util/disk_cache_os.c:817
#5  0x00007f4946061f69 in disk_cache_create
    (gpu_name=0x7f49471c7462 "DIMGREY_CAVEFISH", driver_id=driver_id@entry=0x7f4948297210 "35ce1a9f39e7eb63fad8b9baa8509357ea7a14e0", driver_flags=4294934528)
    at ../src/util/disk_cache.c:106
#6  0x00007f4946848d88 in si_disk_cache_create (sscreen=sscreen@entry=0x7f493fc2b000) at ../src/gallium/drivers/radeonsi/si_pipe.c:1041
#7  0x00007f494684ad36 in radeonsi_screen_create_impl (ws=ws@entry=0x7f496d47cc90, config=config@entry=0x7f4948297400) at ../src/gallium/drivers/radeonsi/si_pipe.c:1162
#8  0x00007f49468c9956 in amdgpu_winsys_create (fd=fd@entry=17, config=config@entry=0x7f4948297400, screen_create=screen_create@entry=0x7f494684a870 <radeonsi_screen_create_impl>)
    at ../src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:555
#9  0x00007f494684ba82 in radeonsi_screen_create (fd=17, config=0x7f4948297400) at ../src/gallium/drivers/radeonsi/si_pipe.c:1456
#10 0x00007f4946059c0b in pipe_radeonsi_create_screen (fd=<optimized out>, config=<optimized out>) at ../src/gallium/auxiliary/target-helpers/drm_helper.h:223
#11 0x00007f494668621f in pipe_loader_create_screen_vk (dev=0x7f494e286a60, sw_vk=sw_vk@entry=false) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:173
#12 0x00007f494668625b in pipe_loader_create_screen (dev=<optimized out>) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:179
#13 0x00007f494605b754 in dri2_init_screen (sPriv=0x7f494e2a39d0) at ../src/gallium/frontends/dri/dri2.c:2342
#14 0x00007f4946580be4 in driCreateNewScreen2 (scrn=0, fd=20, extensions=<optimized out>, driver_extensions=<optimized out>, driver_configs=0x7f496d4a6e88, data=0x7f496d4a6d40)
    at ../src/mesa/drivers/dri/common/dri_util.c:160
#15 0x00007f494e5363a6 in dri_screen_create_dri2 (dri=dri@entry=0x7f496d4a6d40, driver_name=<optimized out>) at ../src/gbm/backends/dri/gbm_dri.c:425
#16 0x00007f494e536ac9 in dri_screen_create (dri=0x7f496d4a6d40) at ../src/gbm/backends/dri/gbm_dri.c:502
#17 dri_device_create (fd=20, gbm_backend_version=1) at ../src/gbm/backends/dri/gbm_dri.c:1450
#18 0x00007f494e534b35 in backend_create_device (fd=20, bd=0x7f494e5408d0 <builtin_backends>) at ../src/gbm/main/backend.c:101
#19 find_backend (name=name@entry=0x0, fd=fd@entry=20) at ../src/gbm/main/backend.c:159
#20 0x00007f494e534c03 in _gbm_create_device (fd=fd@entry=20) at ../src/gbm/main/backend.c:225
#21 0x00007f494e534c88 in gbm_create_device (fd=20) at ../src/gbm/main/gbm.c:135
#22 gbm_create_device (fd=20) at ../src/gbm/main/gbm.c:125

Mesa seems to check some env variables before doing that, so maybe something like https://searchfox.org/mozilla-central/rev/02bd3e02b72d431f2c600a7328697a521f87d9b6/ipc/glue/GeckoChildProcessHost.cpp#1122 is the cleanest fix.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)

Mesa seems to check some env variables before doing that, so maybe something like https://searchfox.org/mozilla-central/rev/02bd3e02b72d431f2c600a7328697a521f87d9b6/ipc/glue/GeckoChildProcessHost.cpp#1122 is the cleanest fix.

Specifically, this is where we set up the “content temp dir”, which is later used to set MESA_GLSL_CACHE_DIR (in the link above). We'll also need this sandbox rule factored out along with the other known Mesa dependencies.

98 is affected as per the crashes, please don't set crashers as disabled otherwise we don't see these bugs during crash triage, thanks!

We should consider backing out bug 1751710 as the volume of crashes and affected installs is high on Nightly.
.

98 is affected as per the crashes, please don't set crashers as disabled otherwise we don't see these bugs during crash triage, thanks!

Do any prefs or environment vars need to be set (differently from the defaults) to hit these though?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #5)

98 is affected as per the crashes, please don't set crashers as disabled otherwise we don't see these bugs during crash triage, thanks!

Do any prefs or environment vars need to be set (differently from the defaults) to hit these though?

If it is the case, we can mark it as disabled but it is not stated in this bug and the number of installs affected seems to indicate that it is probably not the case. About 20 affected installs crashing per build is a lot for nightly, especially given that we have few Linux users.

Set release status flags based on info from the regressing bug 1724385

media.ffmpeg.vaapi.enabled is off by default, so Nightly without user pref flips shouldn't be affected.

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

media.ffmpeg.vaapi.enabled is off by default, so Nightly without user pref flips shouldn't be affected.

Yeah, exactly. VA-API enabled by default is Bug 1752494.

Firefox 97 is unaffected based on regressing bug 1724385.

Linked webcompat issue above likely isn't relevant. I believe it's a compositor bug (see https://bugs.archlinux.org/task/74360 for additional info)

This is a Firefox issue, not really a WebCompat bug - removing the flag for now.

MESA shader cache code uses getpwuid_r call which is blocked by RDD sandbox.
As RDD process does not use shaders we can disable the shader cache for RDD process.

Fixed by Bug 1769182.