Prior to the fbdev being asynchronously configured on boot, the fb_helper->fb may be unset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101767 Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Thierry Reding treding@nvidia.com Cc: Daniel Vetter daniel.vetter@ffwll.ch --- This may not be necessary with the recent async rework? One hopes. --- drivers/gpu/drm/drm_fb_helper.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 42090fe00ef9..a44b6b434fa0 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1502,6 +1502,9 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var, if (var->pixclock != 0 || in_dbg_master()) return -EINVAL;
+ if (!fb) /* too early, fbdev is not yet setup */ + return -EINVAL; + /* * Changes struct fb_var_screeninfo are currently not pushed back * to KMS, hence fail if different settings are requested.
On Wed, Jul 19, 2017 at 04:24:50PM +0100, Chris Wilson wrote:
Prior to the fbdev being asynchronously configured on boot, the fb_helper->fb may be unset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101767 Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Thierry Reding treding@nvidia.com Cc: Daniel Vetter daniel.vetter@ffwll.ch
This may not be necessary with the recent async rework? One hopes.
It shouldn't be possible to call into check_var (or any other fb_ops callback) before we register the framebuffer, and we don't do that before the fb is real.
The bug description also says that after several suspend/resume cycles does it blow up like that, so very unlikely fbdev isn't set up yet. And the NULL pointer isn't really NULL.
There's something going wrong for sure, but I don't think it's this. -Daniel
drivers/gpu/drm/drm_fb_helper.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 42090fe00ef9..a44b6b434fa0 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1502,6 +1502,9 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var, if (var->pixclock != 0 || in_dbg_master()) return -EINVAL;
- if (!fb) /* too early, fbdev is not yet setup */
return -EINVAL;- /*
- Changes struct fb_var_screeninfo are currently not pushed back
- to KMS, hence fail if different settings are requested.
-- 2.13.3
Quoting Daniel Vetter (2017-07-20 09:26:32)
On Wed, Jul 19, 2017 at 04:24:50PM +0100, Chris Wilson wrote:
Prior to the fbdev being asynchronously configured on boot, the fb_helper->fb may be unset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101767 Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Thierry Reding treding@nvidia.com Cc: Daniel Vetter daniel.vetter@ffwll.ch
This may not be necessary with the recent async rework? One hopes.
It shouldn't be possible to call into check_var (or any other fb_ops callback) before we register the framebuffer, and we don't do that before the fb is real.
The bug description also says that after several suspend/resume cycles does it blow up like that, so very unlikely fbdev isn't set up yet. And the NULL pointer isn't really NULL.
There's something going wrong for sure, but I don't think it's this.
It was a stab in the dark as it looked like fb was the pointer behind the crash. (And I have an inherent distrust of this code running before everything is setup, and we know from experience that we can suspend before it is setup.) We can rule out *var, so use-after-free of fb? -Chris
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Daniel Vetter