Commits on Source (8)
-
Marius Vlad authored
Make it obvious that weston_surface has a reference counting happening and destruction of the weston_surface happens when the last weston_surface reference has been accounted for. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
0d8e94af -
Marius Vlad authored
Calling weston_surface_unref() one time too many could be a sign we haven't correctly increased the ref count for it. Also, if we don't have a surface being passed, do no attempt to use it. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
d3ed2eb3 -
Marius Vlad authored
Similar to how we do it with drm_fb ref counts, increase a reference count and return the same object. Plug-in in desktop-shell when we map up the view in order to survive a weston_surface destruction. Astute readers will notice that this patch removes weston_view_destroy() while keeping the balance between removing and adding a weston_surface_unref() call in desktop_shell_destroy_surface(). The reason is to let weston_surface_unref() handle destruction on its own. If multiple references are taken, then weston_surface_unref() doesn't destroy the view, it just decreases the reference, with a latter call to weston_surface_unref() to determine if the view should be destroyed as well. This situation happens if we have close animation enabled, were we have more than one reference taken: one when mapping the view/surface and when when the surface itself was created, (what we call, a weak reference). If only a single reference is taken (for instance if we don't have close animations enabled) then this weston_surface_unref() call is inert as that reference is not set-up, leaving libweston to handle the view destruction. Following that with a weston_view_destroy() explicit call would cause a UAF as the view was previous destroyed by a weston_surface_unref() call. A side-effect of not keeping the weston_view_destroy() call would happen when tearing down the compositor. If close animations are enabled, weston_surface_unref() would not destroy the view, and because weston_view_destroy() no longer exists, we would still have the view in the other layers by the time we check-up if layers have views present. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
bd831407 -
Marius Vlad authored
Creates a distinct view, separated from the one created by libweston-desktop, in order to avoid a potential ownership fight with libweston-desktop upon destroying the view. Upon weston_desktop_surface destruction, libweston-desktop inflicts damage on the view it creates, so we need the view to be alive at that time. This wasn't such an issue before because we had different destruction paths but with commit 'desktop-shell: Do not leave views in layers upon shell destruction' all of the destruction paths now land in the same spot + handle compositor tear down. Note as we still use the same weston_surface we'll keep the previous construct where we were taking a reference to keep it alive. The original view is destroyed when releasing the ownership, while for the view created in this patch we handle the destruction directly upon compositor tear down. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
9cf60284 -
Marius Vlad authored
No functional change. Makes it obvious that we also call weston_layer_fini(). Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
be5b6f9c -
Marius Vlad authored
Moving weston_desktop_surface_unlink_view() to desktop_shell_destroy_surface() makes sure we don't leak the underlying weston_desktop_view when tearing/shutting down the compositor. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
c41cdcab -
Marius Vlad authored
This patch fixes the following trace: #0 0x7f07d1bcecfa in weston_desktop_surface_get_surface ../libweston-desktop/surface.c:585 #1 0x7f07d1bfc9b8 in move_grab_motion ../desktop-shell/shell.c:1499 #2 0x7f07e539f841 in notify_motion ../libweston/input.c:1794 #3 0x7f07e1e8ace4 in handle_pointer_motion ../libweston/libinput-device.c:132 #4 0x7f07e1e8cad5 in evdev_device_process_event ../libweston/libinput-device.c:535 #5 0x7f07e1e89311 in udev_input_process_event ../libweston/libinput-seat.c:208 #6 0x7f07e1e8932f in process_event ../libweston/libinput-seat.c:218 #7 0x7f07e1e8935f in process_events ../libweston/libinput-seat.c:228 #8 0x7f07e1e8940a in udev_input_dispatch ../libweston/libinput-seat.c:239 #9 0x7f07e1e89437 in libinput_source_dispatch ../libweston/libinput-seat.c:249 #10 0x7f07e53122b1 in wl_event_loop_dispatch ../src/event-loop.c:1027 #11 0x7f07e5310114 in wl_display_run ../src/wayland-server.c:1408 #12 0x7f07e579c7ba in wet_main ../compositor/main.c:3589 #13 0x555611d6b17d in main ../compositor/executable.c:33 #14 0x7f07e55be7fc in __libc_start_main ../csu/libc-start.c:332 #15 0x555611d6b099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099) A highly unlikely, but still valid operation, is to close/destroy the window while still having it grabbed and moved around, basically having an in-flight destruction of grabbed moving window. Another situation would be that the client terminates abruptly (crashing for instance), while being dragged which might take down the compositor. This could happen for both touch/pointer grab operations and could cause a NULL pointer access while accessing desktop_surface when being used to retrieve the underlying weston_surface. With this patch we check for a valid desktop_surface and return early if that's not the case. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
d03f0137 -
Marius Vlad authored
This documents the fact that other views are handled implictly by libweston-desktop, and we shouldn't attempt to destroy indiscriminately views that aren't created by desktop-shell. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
299f87f0