On 06-05 17:10, Dan Carpenter wrote: > My patch can't cause this. I'd be surprised if my patch has any > effect beyond silencing a static checker warning, honestly. > Yes, you are right. Your patch cannot be cause of it. Sorry for confusion. > I'm not sure this is a new bug. > Indeed, last time I used mplayer -vo fbdev2 was years ago, so bug could appear anywhere in this period, or it is a more a matter of my configuration. > The problem is we hold ->mmap_sem when we call fb_release() which > takes the info->lock. > > We take the info->lock in do_fb_ioctl() before we call fb_set_var() > which calls drm_fb_helper_set_par() which takes the > mode_config.mutex. > > In drm_mode_getresources() we take the mode_config.mutex() and call > put_user() which takes the ->mmap_sem. > > So on one CPU we are holding the ->mmap_sem and want the info->lock. > On another CPU we are holding the info->lock and want the > config.mutex. On the other CPU we hold the config.mutex and want > the ->mmap_sem. > > Deadlock. Temporary solution would be to break a cycle, and for example take info->lock first on first processor before taking ->mmap_sem and calling fb_release - it is just fb release, so performance doesn't matter so much. Other possibility is to protect this code paths by separate common lock, but it will increase memory and make it slower probably in this function and other ones. I do not know which subsystems use drm_mode_getresources, and if this is important performance wise. There is probably other possibilities, but only fbdev people can tell which is best. > > I'm not sure how to make this work with just two CPUs... Or how to > fix it. But I'm going to disclaim all responsibility and hope the > fbdev people can take a look. ;) > > regards, > dan carpenter > thanks for analysis, Regards, Witek -- Witold Baryluk -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
