* [PATCH] drm/msm/dsi: add protection against NULL dsi device @ 2019-03-07 1:28 Abhinav Kumar 2019-03-07 21:59 ` Sean Paul 0 siblings, 1 reply; 7+ messages in thread From: Abhinav Kumar @ 2019-03-07 1:28 UTC (permalink / raw) To: dri-devel Cc: jhugo, linux-arm-msm, Abhinav Kumar, seanpaul, hoegsberg, sean, chandanu When panel probe happens after DSI probe, the DSI probe is deferred as per current design. In the probe defer path dsi device is destroyed. This NULL dsi device could be deferenced by the panel probe in the mipi_dsi_attach path. Check for NULL dsi device before accessing it. Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c index 80aa634..cc2569d 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len) void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) { struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); - struct drm_device *dev = msm_dsi->dev; + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; struct msm_drm_private *priv; struct msm_kms *kms; struct drm_encoder *encoder; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device 2019-03-07 1:28 [PATCH] drm/msm/dsi: add protection against NULL dsi device Abhinav Kumar @ 2019-03-07 21:59 ` Sean Paul 2019-03-07 22:02 ` Abhinav Kumar 0 siblings, 1 reply; 7+ messages in thread From: Sean Paul @ 2019-03-07 21:59 UTC (permalink / raw) To: Abhinav Kumar Cc: jhugo, linux-arm-msm, dri-devel, seanpaul, hoegsberg, sean, chandanu On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote: > When panel probe happens after DSI probe, the DSI probe > is deferred as per current design. In the probe defer path > dsi device is destroyed. This NULL dsi device could be > deferenced by the panel probe in the mipi_dsi_attach path. > > Check for NULL dsi device before accessing it. It would be really nice to sort all of this out in a manner that's not sprinkling NULL checks around the driver. I spent 5 minutes looking around and couldn't really make sense of how all of these pieces interact, but this seems like it might be an architectural problem (perhaps since dpu was using its own panel stuff instead of drm_panel?). Anyways, it'd be nice to fix that. In the meantime, could you please add a big comment like the !dev check in this function explaining how this situation can come to pass? That way the knowledge isn't lost and whoever comes along to clean up all of these probe checks will have some clue as to what's going on. Sean > > Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> > Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> > Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> > --- > drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c > index 80aa634..cc2569d 100644 > --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c > +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c > @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len) > void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) > { > struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); > - struct drm_device *dev = msm_dsi->dev; > + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; > struct msm_drm_private *priv; > struct msm_kms *kms; > struct drm_encoder *encoder; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device 2019-03-07 21:59 ` Sean Paul @ 2019-03-07 22:02 ` Abhinav Kumar 2019-05-29 20:43 ` Jeffrey Hugo 0 siblings, 1 reply; 7+ messages in thread From: Abhinav Kumar @ 2019-03-07 22:02 UTC (permalink / raw) To: Sean Paul; +Cc: jhugo, linux-arm-msm, dri-devel, seanpaul, hoegsberg, chandanu On 2019-03-07 13:59, Sean Paul wrote: > On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote: >> When panel probe happens after DSI probe, the DSI probe >> is deferred as per current design. In the probe defer path >> dsi device is destroyed. This NULL dsi device could be >> deferenced by the panel probe in the mipi_dsi_attach path. >> >> Check for NULL dsi device before accessing it. > > It would be really nice to sort all of this out in a manner that's not > sprinkling NULL checks around the driver. I spent 5 minutes looking > around and > couldn't really make sense of how all of these pieces interact, but > this seems > like it might be an architectural problem (perhaps since dpu was using > its own > panel stuff instead of drm_panel?). > > Anyways, it'd be nice to fix that. > > In the meantime, could you please add a big comment like the !dev check > in this > function explaining how this situation can come to pass? That way the > knowledge > isn't lost and whoever comes along to clean up all of these probe > checks will > have some clue as to what's going on. > > Sean [Abhinav] Sure Sean, will add a detailed comment to explain the scenario > >> >> Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> >> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> >> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> >> --- >> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c >> b/drivers/gpu/drm/msm/dsi/dsi_manager.c >> index 80aa634..cc2569d 100644 >> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c >> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c >> @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 >> dma_base, u32 len) >> void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) >> { >> struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); >> - struct drm_device *dev = msm_dsi->dev; >> + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; >> struct msm_drm_private *priv; >> struct msm_kms *kms; >> struct drm_encoder *encoder; >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >> Forum, >> a Linux Foundation Collaborative Project >> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device 2019-03-07 22:02 ` Abhinav Kumar @ 2019-05-29 20:43 ` Jeffrey Hugo 0 siblings, 0 replies; 7+ messages in thread From: Jeffrey Hugo @ 2019-05-29 20:43 UTC (permalink / raw) To: Abhinav Kumar, Sean Paul Cc: dri-devel, linux-arm-msm, robdclark, jsanka, seanpaul, nganji, chandanu, hoegsberg On 3/7/2019 3:02 PM, Abhinav Kumar wrote: > On 2019-03-07 13:59, Sean Paul wrote: >> On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote: >>> When panel probe happens after DSI probe, the DSI probe >>> is deferred as per current design. In the probe defer path >>> dsi device is destroyed. This NULL dsi device could be >>> deferenced by the panel probe in the mipi_dsi_attach path. >>> >>> Check for NULL dsi device before accessing it. >> >> It would be really nice to sort all of this out in a manner that's not >> sprinkling NULL checks around the driver. I spent 5 minutes looking >> around and >> couldn't really make sense of how all of these pieces interact, but >> this seems >> like it might be an architectural problem (perhaps since dpu was using >> its own >> panel stuff instead of drm_panel?). >> >> Anyways, it'd be nice to fix that. >> >> In the meantime, could you please add a big comment like the !dev >> check in this >> function explaining how this situation can come to pass? That way the >> knowledge >> isn't lost and whoever comes along to clean up all of these probe >> checks will >> have some clue as to what's going on. >> >> Sean > [Abhinav] Sure Sean, will add a detailed comment to explain the scenario Abhinav, it looks like this may have dropped off your radar. Do you know when you'll come back to it? >> >>> >>> Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> >>> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> >>> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> >>> --- >>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> index 80aa634..cc2569d 100644 >>> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 >>> dma_base, u32 len) >>> void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) >>> { >>> struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); >>> - struct drm_device *dev = msm_dsi->dev; >>> + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; >>> struct msm_drm_private *priv; >>> struct msm_kms *kms; >>> struct drm_encoder *encoder; >>> -- >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >>> Forum, >>> a Linux Foundation Collaborative Project >>> -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device @ 2019-05-29 20:43 ` Jeffrey Hugo 0 siblings, 0 replies; 7+ messages in thread From: Jeffrey Hugo @ 2019-05-29 20:43 UTC (permalink / raw) To: Abhinav Kumar, Sean Paul Cc: linux-arm-msm, dri-devel, seanpaul, hoegsberg, chandanu On 3/7/2019 3:02 PM, Abhinav Kumar wrote: > On 2019-03-07 13:59, Sean Paul wrote: >> On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote: >>> When panel probe happens after DSI probe, the DSI probe >>> is deferred as per current design. In the probe defer path >>> dsi device is destroyed. This NULL dsi device could be >>> deferenced by the panel probe in the mipi_dsi_attach path. >>> >>> Check for NULL dsi device before accessing it. >> >> It would be really nice to sort all of this out in a manner that's not >> sprinkling NULL checks around the driver. I spent 5 minutes looking >> around and >> couldn't really make sense of how all of these pieces interact, but >> this seems >> like it might be an architectural problem (perhaps since dpu was using >> its own >> panel stuff instead of drm_panel?). >> >> Anyways, it'd be nice to fix that. >> >> In the meantime, could you please add a big comment like the !dev >> check in this >> function explaining how this situation can come to pass? That way the >> knowledge >> isn't lost and whoever comes along to clean up all of these probe >> checks will >> have some clue as to what's going on. >> >> Sean > [Abhinav] Sure Sean, will add a detailed comment to explain the scenario Abhinav, it looks like this may have dropped off your radar. Do you know when you'll come back to it? >> >>> >>> Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> >>> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> >>> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> >>> --- >>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> index 80aa634..cc2569d 100644 >>> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>> @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 >>> dma_base, u32 len) >>> void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) >>> { >>> struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); >>> - struct drm_device *dev = msm_dsi->dev; >>> + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; >>> struct msm_drm_private *priv; >>> struct msm_kms *kms; >>> struct drm_encoder *encoder; >>> -- >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >>> Forum, >>> a Linux Foundation Collaborative Project >>> -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device 2019-05-29 20:43 ` Jeffrey Hugo @ 2019-05-29 21:19 ` Abhinav Kumar -1 siblings, 0 replies; 7+ messages in thread From: Abhinav Kumar @ 2019-05-29 21:19 UTC (permalink / raw) To: Jeffrey Hugo Cc: Sean Paul, dri-devel, linux-arm-msm, robdclark, jsanka, seanpaul, nganji, chandanu, hoegsberg On 2019-05-29 13:43, Jeffrey Hugo wrote: > On 3/7/2019 3:02 PM, Abhinav Kumar wrote: >> On 2019-03-07 13:59, Sean Paul wrote: >>> On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote: >>>> When panel probe happens after DSI probe, the DSI probe >>>> is deferred as per current design. In the probe defer path >>>> dsi device is destroyed. This NULL dsi device could be >>>> deferenced by the panel probe in the mipi_dsi_attach path. >>>> >>>> Check for NULL dsi device before accessing it. >>> >>> It would be really nice to sort all of this out in a manner that's >>> not >>> sprinkling NULL checks around the driver. I spent 5 minutes looking >>> around and >>> couldn't really make sense of how all of these pieces interact, but >>> this seems >>> like it might be an architectural problem (perhaps since dpu was >>> using its own >>> panel stuff instead of drm_panel?). >>> >>> Anyways, it'd be nice to fix that. >>> >>> In the meantime, could you please add a big comment like the !dev >>> check in this >>> function explaining how this situation can come to pass? That way the >>> knowledge >>> isn't lost and whoever comes along to clean up all of these probe >>> checks will >>> have some clue as to what's going on. >>> >>> Sean >> [Abhinav] Sure Sean, will add a detailed comment to explain the >> scenario > > Abhinav, it looks like this may have dropped off your radar. Do you > know when you'll come back to it? Hi Jeff, Yes i will upload a v2 with a detailed comment as sean requested within this week. > >>> >>>> >>>> Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> >>>> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> >>>> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> >>>> --- >>>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> index 80aa634..cc2569d 100644 >>>> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, >>>> u32 dma_base, u32 len) >>>> void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) >>>> { >>>> struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); >>>> - struct drm_device *dev = msm_dsi->dev; >>>> + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; >>>> struct msm_drm_private *priv; >>>> struct msm_kms *kms; >>>> struct drm_encoder *encoder; >>>> -- The Qualcomm Innovation Center, Inc. is a member of the Code >>>> Aurora Forum, >>>> a Linux Foundation Collaborative Project >>>> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device @ 2019-05-29 21:19 ` Abhinav Kumar 0 siblings, 0 replies; 7+ messages in thread From: Abhinav Kumar @ 2019-05-29 21:19 UTC (permalink / raw) To: Jeffrey Hugo Cc: linux-arm-msm, dri-devel, seanpaul, hoegsberg, Sean Paul, chandanu On 2019-05-29 13:43, Jeffrey Hugo wrote: > On 3/7/2019 3:02 PM, Abhinav Kumar wrote: >> On 2019-03-07 13:59, Sean Paul wrote: >>> On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote: >>>> When panel probe happens after DSI probe, the DSI probe >>>> is deferred as per current design. In the probe defer path >>>> dsi device is destroyed. This NULL dsi device could be >>>> deferenced by the panel probe in the mipi_dsi_attach path. >>>> >>>> Check for NULL dsi device before accessing it. >>> >>> It would be really nice to sort all of this out in a manner that's >>> not >>> sprinkling NULL checks around the driver. I spent 5 minutes looking >>> around and >>> couldn't really make sense of how all of these pieces interact, but >>> this seems >>> like it might be an architectural problem (perhaps since dpu was >>> using its own >>> panel stuff instead of drm_panel?). >>> >>> Anyways, it'd be nice to fix that. >>> >>> In the meantime, could you please add a big comment like the !dev >>> check in this >>> function explaining how this situation can come to pass? That way the >>> knowledge >>> isn't lost and whoever comes along to clean up all of these probe >>> checks will >>> have some clue as to what's going on. >>> >>> Sean >> [Abhinav] Sure Sean, will add a detailed comment to explain the >> scenario > > Abhinav, it looks like this may have dropped off your radar. Do you > know when you'll come back to it? Hi Jeff, Yes i will upload a v2 with a detailed comment as sean requested within this week. > >>> >>>> >>>> Reported-by: Jeffrey Hugo <jhugo@codeaurora.org> >>>> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> >>>> Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> >>>> --- >>>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> index 80aa634..cc2569d 100644 >>>> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c >>>> @@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, >>>> u32 dma_base, u32 len) >>>> void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags) >>>> { >>>> struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id); >>>> - struct drm_device *dev = msm_dsi->dev; >>>> + struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL; >>>> struct msm_drm_private *priv; >>>> struct msm_kms *kms; >>>> struct drm_encoder *encoder; >>>> -- The Qualcomm Innovation Center, Inc. is a member of the Code >>>> Aurora Forum, >>>> a Linux Foundation Collaborative Project >>>> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-05-29 21:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-03-07 1:28 [PATCH] drm/msm/dsi: add protection against NULL dsi device Abhinav Kumar 2019-03-07 21:59 ` Sean Paul 2019-03-07 22:02 ` Abhinav Kumar 2019-05-29 20:43 ` Jeffrey Hugo 2019-05-29 20:43 ` Jeffrey Hugo 2019-05-29 21:19 ` Abhinav Kumar 2019-05-29 21:19 ` Abhinav Kumar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.