ivi-shell: bugfix, list of surfaces on a layer are cumulated when set render order is called several time in one commitchanges.

Submitted by Nobuhiko Tanibata on Aug. 5, 2015, 7 a.m.

Details

Message ID 1438758057-20125-1-git-send-email-nobuhiko_tanibata@xddp.denso.co.jp
State Superseded
Headers show

Not browsing as part of any series.

Commit Message

Nobuhiko Tanibata Aug. 5, 2015, 7 a.m.
The final list of surfaces of set render order shall be applied. So link
of surfaces and list of surfaces in a layer shall be initialized. And
then the order of surfaces shall be restructured.

Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
---
 ivi-shell/ivi-layout.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

Patch hide | download patch | download mbox

diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index bb175b0..2b61ff2 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -2082,14 +2082,14 @@  ivi_layout_layer_set_render_order(struct ivi_layout_layer *ivilayer,
 		return IVI_FAILED;
 	}
 
-	if (pSurface == NULL) {
-		wl_list_for_each_safe(ivisurf, next, &ivilayer->pending.surface_list, pending.link) {
-			if (!wl_list_empty(&ivisurf->pending.link)) {
-				wl_list_remove(&ivisurf->pending.link);
-			}
+	wl_list_for_each_safe(ivisurf, next,
+			      &ivilayer->pending.surface_list, pending.link) {
+		wl_list_init(&ivisurf->pending.link);
+	}
 
-			wl_list_init(&ivisurf->pending.link);
-		}
+	wl_list_init(&ivilayer->pending.surface_list);
+
+	if (pSurface == NULL || number ==0) {
 		ivilayer->event_mask |= IVI_NOTIFICATION_REMOVE;
 		return IVI_SUCCEEDED;
 	}

Comments

On Wed,  5 Aug 2015 16:00:57 +0900
Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> wrote:

> The final list of surfaces of set render order shall be applied. So link
> of surfaces and list of surfaces in a layer shall be initialized. And
> then the order of surfaces shall be restructured.
> 
> Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
> ---
>  ivi-shell/ivi-layout.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index bb175b0..2b61ff2 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -2082,14 +2082,14 @@ ivi_layout_layer_set_render_order(struct ivi_layout_layer *ivilayer,
>  		return IVI_FAILED;
>  	}
>  
> -	if (pSurface == NULL) {
> -		wl_list_for_each_safe(ivisurf, next, &ivilayer->pending.surface_list, pending.link) {
> -			if (!wl_list_empty(&ivisurf->pending.link)) {
> -				wl_list_remove(&ivisurf->pending.link);
> -			}
> +	wl_list_for_each_safe(ivisurf, next,
> +			      &ivilayer->pending.surface_list, pending.link) {
> +		wl_list_init(&ivisurf->pending.link);
> +	}
>  
> -			wl_list_init(&ivisurf->pending.link);
> -		}
> +	wl_list_init(&ivilayer->pending.surface_list);

Hi,

heh, I don't recall seeing this code pattern before. It looks fragile
or even dangerous, because it is init'ing a link that is part of a
list, and doing that while traversing that list. However, I think it is
safe in this case, because:

- wl_list_for_each_safe protects against removal of the current item by
  fetching the pointer to the next item before-hand, so init'ing rather
  than removing the current item is still ok, and

- the whole list is always processed through, and finally the list head
  is init'd, so all involved pointers are reset.

I've been using another pattern, e.g. src/rpi-renderer.c:1768

	while (!wl_list_empty(&output->view_cleanup_list)) {
		view = container_of(output->view_cleanup_list.next,
				    struct rpir_view, link);
		rpir_view_destroy(view);
	}

I'm not sure if we should prefer one or the other, because I'm
obviously biased in my judgement. :-)

The latter one does not involve temporarily broken list structures...

> +
> +	if (pSurface == NULL || number ==0) {
>  		ivilayer->event_mask |= IVI_NOTIFICATION_REMOVE;
>  		return IVI_SUCCEEDED;
>  	}

Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>


Thanks,
pq
> -----Original Message-----
> From: wayland-devel
> [mailto:wayland-devel-bounces@lists.freedesktop.org] On Behalf Of Pekka
> Paalanen
> Sent: Friday, August 14, 2015 9:44 PM
> To: Nobuhiko Tanibata
> Cc: securitycheck@denso.co.jp; wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH] ivi-shell: bugfix, list of surfaces on a layer are
> cumulated when set render order is called several time in one commitchanges.
> 
> On Wed,  5 Aug 2015 16:00:57 +0900
> Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> wrote:
> 
> > The final list of surfaces of set render order shall be applied. So
> > link of surfaces and list of surfaces in a layer shall be initialized.
> > And then the order of surfaces shall be restructured.
> >
> > Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
> > ---
> >  ivi-shell/ivi-layout.c | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c index
> > bb175b0..2b61ff2 100644
> > --- a/ivi-shell/ivi-layout.c
> > +++ b/ivi-shell/ivi-layout.c
> > @@ -2082,14 +2082,14 @@ ivi_layout_layer_set_render_order(struct
> ivi_layout_layer *ivilayer,
> >  		return IVI_FAILED;
> >  	}
> >
> > -	if (pSurface == NULL) {
> > -		wl_list_for_each_safe(ivisurf, next,
> &ivilayer->pending.surface_list, pending.link) {
> > -			if (!wl_list_empty(&ivisurf->pending.link)) {
> > -
> 	wl_list_remove(&ivisurf->pending.link);
> > -			}
> > +	wl_list_for_each_safe(ivisurf, next,
> > +			      &ivilayer->pending.surface_list,
> pending.link) {
> > +		wl_list_init(&ivisurf->pending.link);
> > +	}
> >
> > -			wl_list_init(&ivisurf->pending.link);
> > -		}
> > +	wl_list_init(&ivilayer->pending.surface_list);
> 
> Hi,
> 
> heh, I don't recall seeing this code pattern before. It looks fragile or
> even dangerous, because it is init'ing a link that is part of a list, and
> doing that while traversing that list. However, I think it is safe in this
> case, because:
> 
> - wl_list_for_each_safe protects against removal of the current item by
>   fetching the pointer to the next item before-hand, so init'ing rather
>   than removing the current item is still ok, and
> 
> - the whole list is always processed through, and finally the list head
>   is init'd, so all involved pointers are reset.
> 
> I've been using another pattern, e.g. src/rpi-renderer.c:1768
> 
> 	while (!wl_list_empty(&output->view_cleanup_list)) {
> 		view = container_of(output->view_cleanup_list.next,
> 				    struct rpir_view, link);
> 		rpir_view_destroy(view);
> 	}
> 
> I'm not sure if we should prefer one or the other, because I'm obviously
> biased in my judgement. :-)
> 
> The latter one does not involve temporarily broken list structures...
[ntanibata] Hi Pekka-san,
I will use later one to send it as v2. Thank you!

Nobuhiko Tanibata

> 
> > +
> > +	if (pSurface == NULL || number ==0) {
> >  		ivilayer->event_mask |= IVI_NOTIFICATION_REMOVE;
> >  		return IVI_SUCCEEDED;
> >  	}
> 
> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> 
> 
> Thanks,
> pq