Den 17.04.2019 15.26, skrev Daniel Vetter: > On Wed, Apr 17, 2019 at 03:24:00PM +0200, Daniel Vetter wrote: >> On Tue, Apr 16, 2019 at 08:46:24PM +0200, Noralf Trønnes wrote: >>> >>> >>> Den 16.04.2019 09.59, skrev Daniel Vetter: >>>> On Sun, Apr 07, 2019 at 06:52:33PM +0200, Noralf Trønnes wrote: >>>>> drm_fb_helper_is_bound() is used to check if DRM userspace is in control. >>>>> This is done by looking at the fb on the primary plane. By the time >>>>> fb-helper gets around to committing, it's possible that the facts have >>>>> changed. >>>>> >>>>> Avoid this race by holding the drm_device->master_mutex lock while >>>>> committing. When DRM userspace does its first open, it will now wait >>>>> until fb-helper is done. The helper will stay away if there's a master. >>>>> >>>>> Locking rule: Always take the fb-helper lock first. >>>>> >>>>> v2: >>>>> - Remove drm_fb_helper_is_bound() (Daniel Vetter) >>>>> - No need to check fb_helper->dev->master in >>>>> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check. >>>>> >>>>> Suggested-by: Daniel Vetter <daniel.vetter@xxxxxxxx> >>>>> Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx> >>>>> --- <snip> > Ok, I read the later patches and you already have a commit() and a > commit_force(). Count me convinced on all points. > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > as-is on this patch. > Thanks. I want to apply this after the for-5.2 cutoff so we can get some testing on this before it hits the world. I know from the timeline chart that the cutoff is some time after -rc5, but I don't know _excatly_ when that is. I looked at dim, but all I could glean from it was that it had something to do with the state of a -fixes branch. Noralf. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx