On Fri, Jan 17, 2020 at 01:58:25PM +0100, Gerd Hoffmann wrote: > > Should switching to bochsdrmfb be deferred until efifb gets properly > > destroyed? How? > > Should be in do_remove_conflicting_framebuffers, everyone might run into > this. So lets try wait for all (other) references went away:
Yes, this solves the problem. I guess the proper solution would be to replace it with some wait queue or such, right? Is there any guarantee that the process holding /dev/fb0 (plymouthd in this case) will eventually release it? If not, what could this (indefinite then) wait cause? Is there any lock held here that could hang other operations? > diff --git a/drivers/video/fbdev/core/fbmem.c > b/drivers/video/fbdev/core/fbmem.c > index d04554959ea7..2d4911cc7ec4 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1726,7 +1726,9 @@ static void do_unregister_framebuffer(struct fb_info > *fb_info) > fbcon_fb_unregistered(fb_info); > console_unlock(); > > - /* this may free fb info */ > + while (atomic_read(&fb_info->count) > 1) > + msleep(10); > + /* this will free fb info */ > put_fb_info(fb_info); > } > > -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
_______________________________________________ Virtualization mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
