mirrors/wlroots
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/wlroots/wlroots.git synced 2026-02-15 22:05:31 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

buffer: introduce wlr_buffer_acquire()

Browse source 
A footgun in the wlr_buffer API is that there's no difference
between acquiring a buffer and increasing the lock count. In other
words, transitioning a buffer from the released state to the
acquired state is not explicit. This may result in hard-to-debug
failures if there is a dangling released wlr_buffer somewhere
(e.g. wlr_client_buffer.source [1]) and some piece of code calls
wlr_buffer_lock(). In that case, the buffer will be acquired and
released again. In the context of a wlr_buffer issued from a
Wayland protocol wl_buffer object, this can cause the underlying
memory to be used after wl_buffer.release has been sent to the
client, and a double wl_buffer.release event to be sent.

Make it so acquiring a buffer is an explicit operation to make sure
the caller means the state transition and is prepared for a new
release event. wlr_buffer_acquire() forbids calls on already-acquired
buffers, and wlr_buffer_lock() now forbids calls on released buffers.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4904
This commit is contained in:
Simon Ser 2024-11-21 17:30:27 +01:00
parent f233d25e86
commit 30ccac3a02
5 changed files with 32 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

2
render/swapchain.c
View file

@ -74,7 +74,7 @@ static struct wlr_buffer *slot_acquire(struct wlr_swapchain *swapchain,
slot->release.notify = slot_handle_release;
wl_signal_add(&slot->buffer->events.release, &slot->release);
return wlr_buffer_lock(slot->buffer);
return wlr_buffer_acquire(slot->buffer);
}
struct wlr_buffer *wlr_swapchain_acquire(struct wlr_swapchain *swapchain) {