On Thu, 19 Dec 2019 13:42:33 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Thu, Dec 19, 2019 at 12:32 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > > While being at it: How would a driver cleanup properly cleanup gem > > objects created by userspace on hotunbind? Specifically a gem object > > pinned to vram? > > Two things: > - the mmap needs to be torn down and replaced by something which will > sigbus. Probably should have that as a helper (plus vram fault code > should use drm_dev_enter/exit to plug races). Hi, I assume SIGBUS is the traditional way to say "oops, the memory you mmapped and tried to access no longer exists". Is there nothing else for this? I'm asking, because SIGBUS is really hard to handle right in userspace. It can be caused by any number of wildly different reasons, yet being a signal means that a userspace process can only have a single global handler for it. That makes it almost impossible to use safely in libraries, because you would want to register independent handlers from multiple libraries in the same process. Some libraries may also be using threads. How to handle a SIGBUS completely depends on what triggered it. Almost always userspace wants it to be a non-fatal error. A Wayland compositor can hit SIGBUS on accessing wl_shm-based client buffers (regular mmapped files), and then it just wants to continue with garbage data as if nothing happened and possibly send a protocol error to the client provoking it. I would also imagine that Mesa, when it starts looking into supporting GPU hotunplug, needs to handle vanished mmaps. I don't think Mesa can ever install signal handlers, because that would mess with the applications that may already be using SIGBUS for handling disappearing mmapped files. It needs to start returning errors via API calls. I cannot imagine a way to reliably prevent such SIGBUS either by e.g. ensuring Mesa gets notified of removal before it actually starts failing. For now, I'm just looking for a simple "yes" or "no" here for the something else. If it's "no" like I expect, creating something else is probably in the order of years to get into a usable state. Does anyone already have plans towards that? Thanks, pq
Attachment:
pgpazckitDMl4.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
