> Date: Sat, 4 Jul 2020 21:38:46 +1000 > From: Jonathan Gray <[email protected]> > > On Sat, Jul 04, 2020 at 12:22:41PM +0200, Landry Breuil wrote: > > On Sat, Jul 04, 2020 at 05:58:07PM +1000, Jonathan Gray wrote: > > > On Fri, Jul 03, 2020 at 11:14:02PM -0400, Joe Gidi wrote: > > > > Hello, > > > > > > > > > > firefox seems to be doing a dlopen after it has unveil'd and can't > > > open libLLVM. unveil removes visibility of parts of the filesystem, > > > but it has to be done in the right place. > > > > i dont think firefox itself is doing this dlopen, rather MESA ? > > https://searchfox.org/mozilla-central/search?q=libllvm > > firefox would be dlopen'ing libGL.so > the Mesa loader opens the dri driver which I suspect happens when > the GL context is created. > > /usr/X11R6/lib/modules/dri/radeonsi_dri.so for amdgpu > > in the case of radeonsi and swrast these are linked against > libLLVM (and libelf for amdgpu) > > dlopen: loading: libGL.so > dlopen: libGL.so: done (success). > dlopen: loading: /usr/X11R6/lib/modules/dri/radeonsi_dri.so > flags /usr/X11R6/lib/modules/dri/radeonsi_dri.so = 0x0 > head /usr/X11R6/lib/modules/dri/radeonsi_dri.so > obj /usr/X11R6/lib/modules/dri/radeonsi_dri.so has > /usr/X11R6/lib/modules/dri/radeonsi_dri.so as head > linking /usr/X11R6/lib/modules/dri/radeonsi_dri.so as dlopen()ed > head [/usr/X11R6/lib/modules/dri/radeonsi_dri.so] > examining: '/usr/X11R6/lib/modules/dri/radeonsi_dri.so' > loading: libelf.so.3.0 required by /usr/X11R6/lib/modules/dri/radeonsi_dri.so > dlopen: failed to open libelf.so.3.0 > unload_shlib called on /usr/X11R6/lib/modules/dri/radeonsi_dri.so > unload_shlib unloading on /usr/X11R6/lib/modules/dri/radeonsi_dri.so > dlopen: /usr/X11R6/lib/modules/dri/radeonsi_dri.so: done (failed). > libGL error: MESA-LOADER: failed to open radeonsi (search paths > /usr/X11R6/lib/modules/dri) > > It works if I disable unveil in the kernel and permit DRM_IOCTL_GET_CLIENT > in pledge_ioctl_drm(), which was discussed at some point but apparently > didn't go in. This should only be required if trying to create a > context after pledge, occurs in libdrm amdgpu init.
Because that ioctl really shouldn't be used by a modern DRM client. You must be hitting the DRM_IOCTL_GET_CLIENT usage in lib/libdrm/amdgpu/amdgpu_device.c, but that path shouldn't be hit when we're using a render node. So the real question becomes why we we end up with a "classic" primary node instead of a render node.
