All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Peter Rosin <peda@axentia.se>
Cc: linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	linux-rockchip@lists.infradead.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	dri-devel@lists.freedesktop.org,
	Vincent Abriou <vincent.abriou@st.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
Date: Mon, 7 May 2018 15:39:29 +0200	[thread overview]
Message-ID: <20180507133929.GG12521@phenom.ffwll.local> (raw)
In-Reply-To: <bd8d12f7-0c71-c96b-80fa-54de7de39511@axentia.se>

On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> On 2018-05-03 11:06, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >> The more natural approach would perhaps be to add an drm_bridge_add,
> >> but there are several other bridges that never call drm_bridge_add.
> >> Just removing the drm_bridge_remove is the easier fix.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> > 
> > This mess is much bigger. There's 2 pairs of bridge functions:
> > 
> > - drm_bridge_attach/detach. Those are meant to be called by the overall
> >   drm driver to connect/disconnect a drm_bridge.
> > 
> > - drm_bridge_add/remove. These are supposed to be called by the bridge
> >   driver itself to register/unregister itself. Maybe we should rename
> >   them, since the same issue happens with drm_panel, with the same
> >   confusion.
> > 
> > I thought someone was working on a cleanup series to fix this mess, but I
> > didn't find anything.
> 
> Ok, I just spotted the imbalance and didn't really dig into what
> actually happens in these error paths. Now that I have done so I
> believe that the removed drm_bridge_remove calls causes NULL
> dereferences if/when the error paths are triggered.
> 
> So, I don't think this can wait for some bigger cleanup.
> 
> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> __list_del with NULL in both prev and next since the list member
> is never initialized. prev and next are dereferenced by __list_del
> and you have *boom*
> 
> I recommend adding the tag
> 
> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> 
> so that stable picks this one up.

I just wanted to correct your commit message text - the correct solution
is definitely _not_ for sti here to call drm_bridge_add. It should call
drm_bridge_attach/detach only, as a pair.

I didn't check whether you instead have a _detach call missing or what's
going on here.
-Daniel
> 
> Cheers,
> Peter
> 
> > -Daniel
> > 
> >> ---
> >>  drivers/gpu/drm/sti/sti_hda.c  | 1 -
> >>  drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >>  2 files changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >> index 67bbdb49fffc..199db13f565c 100644
> >> --- a/drivers/gpu/drm/sti/sti_hda.c
> >> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >>  	return 0;
> >>  
> >>  err_sysfs:
> >> -	drm_bridge_remove(bridge);
> >>  	return -EINVAL;
> >>  }
> >>  
> >> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >> index 58f431102512..932724784942 100644
> >> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>  	return 0;
> >>  
> >>  err_sysfs:
> >> -	drm_bridge_remove(bridge);
> >>  	hdmi->drm_connector = NULL;
> >>  	return -EINVAL;
> >>  }
> >> -- 
> >> 2.11.0
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Peter Rosin <peda@axentia.se>
Cc: linux-samsung-soc@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	linux-kernel@vger.kernel.org,
	Krzysztof Kozlowski <krzk@kernel.org>,
	linux-rockchip@lists.infradead.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	dri-devel@lists.freedesktop.org,
	Vincent Abriou <vincent.abriou@st.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
Date: Mon, 7 May 2018 15:39:29 +0200	[thread overview]
Message-ID: <20180507133929.GG12521@phenom.ffwll.local> (raw)
In-Reply-To: <bd8d12f7-0c71-c96b-80fa-54de7de39511@axentia.se>

On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> On 2018-05-03 11:06, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >> The more natural approach would perhaps be to add an drm_bridge_add,
> >> but there are several other bridges that never call drm_bridge_add.
> >> Just removing the drm_bridge_remove is the easier fix.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> > 
> > This mess is much bigger. There's 2 pairs of bridge functions:
> > 
> > - drm_bridge_attach/detach. Those are meant to be called by the overall
> >   drm driver to connect/disconnect a drm_bridge.
> > 
> > - drm_bridge_add/remove. These are supposed to be called by the bridge
> >   driver itself to register/unregister itself. Maybe we should rename
> >   them, since the same issue happens with drm_panel, with the same
> >   confusion.
> > 
> > I thought someone was working on a cleanup series to fix this mess, but I
> > didn't find anything.
> 
> Ok, I just spotted the imbalance and didn't really dig into what
> actually happens in these error paths. Now that I have done so I
> believe that the removed drm_bridge_remove calls causes NULL
> dereferences if/when the error paths are triggered.
> 
> So, I don't think this can wait for some bigger cleanup.
> 
> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> __list_del with NULL in both prev and next since the list member
> is never initialized. prev and next are dereferenced by __list_del
> and you have *boom*
> 
> I recommend adding the tag
> 
> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> 
> so that stable picks this one up.

I just wanted to correct your commit message text - the correct solution
is definitely _not_ for sti here to call drm_bridge_add. It should call
drm_bridge_attach/detach only, as a pair.

I didn't check whether you instead have a _detach call missing or what's
going on here.
-Daniel
> 
> Cheers,
> Peter
> 
> > -Daniel
> > 
> >> ---
> >>  drivers/gpu/drm/sti/sti_hda.c  | 1 -
> >>  drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >>  2 files changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >> index 67bbdb49fffc..199db13f565c 100644
> >> --- a/drivers/gpu/drm/sti/sti_hda.c
> >> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >>  	return 0;
> >>  
> >>  err_sysfs:
> >> -	drm_bridge_remove(bridge);
> >>  	return -EINVAL;
> >>  }
> >>  
> >> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >> index 58f431102512..932724784942 100644
> >> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>  	return 0;
> >>  
> >>  err_sysfs:
> >> -	drm_bridge_remove(bridge);
> >>  	hdmi->drm_connector = NULL;
> >>  	return -EINVAL;
> >>  }
> >> -- 
> >> 2.11.0
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: daniel@ffwll.ch (Daniel Vetter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
Date: Mon, 7 May 2018 15:39:29 +0200	[thread overview]
Message-ID: <20180507133929.GG12521@phenom.ffwll.local> (raw)
In-Reply-To: <bd8d12f7-0c71-c96b-80fa-54de7de39511@axentia.se>

On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> On 2018-05-03 11:06, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >> The more natural approach would perhaps be to add an drm_bridge_add,
> >> but there are several other bridges that never call drm_bridge_add.
> >> Just removing the drm_bridge_remove is the easier fix.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> > 
> > This mess is much bigger. There's 2 pairs of bridge functions:
> > 
> > - drm_bridge_attach/detach. Those are meant to be called by the overall
> >   drm driver to connect/disconnect a drm_bridge.
> > 
> > - drm_bridge_add/remove. These are supposed to be called by the bridge
> >   driver itself to register/unregister itself. Maybe we should rename
> >   them, since the same issue happens with drm_panel, with the same
> >   confusion.
> > 
> > I thought someone was working on a cleanup series to fix this mess, but I
> > didn't find anything.
> 
> Ok, I just spotted the imbalance and didn't really dig into what
> actually happens in these error paths. Now that I have done so I
> believe that the removed drm_bridge_remove calls causes NULL
> dereferences if/when the error paths are triggered.
> 
> So, I don't think this can wait for some bigger cleanup.
> 
> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> __list_del with NULL in both prev and next since the list member
> is never initialized. prev and next are dereferenced by __list_del
> and you have *boom*
> 
> I recommend adding the tag
> 
> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> 
> so that stable picks this one up.

I just wanted to correct your commit message text - the correct solution
is definitely _not_ for sti here to call drm_bridge_add. It should call
drm_bridge_attach/detach only, as a pair.

I didn't check whether you instead have a _detach call missing or what's
going on here.
-Daniel
> 
> Cheers,
> Peter
> 
> > -Daniel
> > 
> >> ---
> >>  drivers/gpu/drm/sti/sti_hda.c  | 1 -
> >>  drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >>  2 files changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >> index 67bbdb49fffc..199db13f565c 100644
> >> --- a/drivers/gpu/drm/sti/sti_hda.c
> >> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >>  	return 0;
> >>  
> >>  err_sysfs:
> >> -	drm_bridge_remove(bridge);
> >>  	return -EINVAL;
> >>  }
> >>  
> >> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >> index 58f431102512..932724784942 100644
> >> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>  	return 0;
> >>  
> >>  err_sysfs:
> >> -	drm_bridge_remove(bridge);
> >>  	hdmi->drm_connector = NULL;
> >>  	return -EINVAL;
> >>  }
> >> -- 
> >> 2.11.0
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2018-05-07 13:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-02  7:40 [PATCH 0/3] drm: fix some bridge api misunderstandings Peter Rosin
2018-05-02  7:40 ` Peter Rosin
2018-05-02  7:40 ` [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added Peter Rosin
2018-05-02  7:40   ` Peter Rosin
2018-05-03  9:06   ` Daniel Vetter
2018-05-03  9:06     ` Daniel Vetter
2018-05-03  9:06     ` Daniel Vetter
2018-05-03 21:12     ` Peter Rosin
2018-05-03 21:12       ` Peter Rosin
2018-05-07 13:39       ` Daniel Vetter [this message]
2018-05-07 13:39         ` Daniel Vetter
2018-05-07 13:39         ` Daniel Vetter
2018-05-07 13:59         ` Peter Rosin
2018-05-07 13:59           ` Peter Rosin
2018-05-07 14:24           ` Peter Rosin
2018-05-07 14:24             ` Peter Rosin
2018-05-08  7:51             ` Daniel Vetter
2018-05-08  7:51               ` Daniel Vetter
2018-05-08  7:41           ` Daniel Vetter
2018-05-08  7:41             ` Daniel Vetter
2018-05-08  7:41             ` Daniel Vetter
2018-05-02  7:40 ` [PATCH 2/3] drm/rockchip: lvds: avoid duplicating drm_bridge_attach Peter Rosin
2018-05-02  7:40   ` Peter Rosin
2018-05-20 11:48   ` Heiko Stuebner
2018-05-20 11:48     ` Heiko Stuebner
2018-05-20 11:48     ` Heiko Stuebner
2018-05-02  7:40 ` [PATCH 3/3] drm/exynos: hdmi: " Peter Rosin
2018-05-02  7:40   ` Peter Rosin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180507133929.GG12521@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=sw0312.kim@samsung.com \
    --cc=vincent.abriou@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.