[spice-gtk RFC 0/3] coroutine: Make signal/notify coroutine code more robust against unexpected coroutine_init()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey,

Before the recent rework of disconnect/channel_reset, it was possible to get in a situation where
an idle would get queued, then an attempt to emit a signal from coroutine context would be attempted.
The first idle would run, call coroutine_init() which would reset the coroutine state, and then the
signal emission idle would run in an invalid context (the stack allocated
signal_data data would no longer be valid), causing a hard to diagnose crash.
This series tries to improve that by showing a warning when coroutine_init() is called while
a signal/notify idle is queued.
For now this is only done for the ucontext implementation, depending on where this RFC goes,
I'll add support to the other variants. While this adds some code to coroutine_init() and a member to
struct coroutine, the only thing which is needed is some way to run a check
when coroutine_init() gets called. For example, an alternative could be a g_coroutine_init() wrapper
doing the check and then calling into coroutine_init().
Patch 3/3 is a bit ugly because of the hoops it has to go through in order to safely free some
allocated memory. In my opinion, it's plenty fine to decide that we'll leak a bit of memory when
the warning added in 2/3 triggers.

Christophe

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]