Hello Thomas, On 5/4/22 13:08, Thomas Zimmermann wrote: [snip] >>> So something similar to fb_file_fb_info() is needed to check if >>> the vm_private_data is still valid. I guess that could be done >>> by using the vmf->vma->vm_file and attempting the same trick that >>> fb_file_fb_info() does ? >> >> Yeah should work, except if the ptes are set up already there's kinda not >> much that this will prevent. We'd need to tear down mappings and SIGBUS or >> alternatively have something else in place there so userspace doesn't blow >> up in funny ways (which is what we're doing on the drm side, or at least >> trying to). >> >> I'm also not sure how much we should care, since ideally for drm drivers >> this is all taken care of by drm_dev_enter in the right places. It does >> mean though that fbdev mmap either needs to have it's own memory or be >> fully redirected to the drm gem mmap. >> >> And then we can afford to just not care to fix fbdev itself. > > While the problem has been there ever since, the bug didn't happen until > we fixed hot-unplugging for fbdev. Not doing anything is probably not > the right thing. > Actually, this issue shouldn't happen if the fbdev drivers are not buggy and do the proper cleanup at .fb_release() time rather than at .remove(). I'll post patches for simplefb and efifb which are the drivers that we mostly care at this point. So we should be good and not need more fixes. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
