commit d60428264fdd9a2281308ea45f6fbae4512eb061 Author: Ondrej Holy Date: 2016-04-25 Update NEWS for 1.29.1 release M NEWS commit fd36dd9e1074a4b69d1f05a2c1e201522a288a83 Author: Ondrej Holy Date: 2016-04-18 udisks2: Fix crash when mounting encrypted volume Code handling external unlocks during mount operation was added by the commit beea21e recently. Unfortunately, it may cause crashes due to accessing already freed memory, because gvfs_udisks2_volume_monitor_update waits for pending dbus messages using udisks_client_settle, thus another main context iteration may happen (i.e. mount operation may finish and mount data may be freed) before accessing mount data pointer. The mount data pointer has to be obtained after gvfs_udisks2_volume_monitor_update call in order to fix this crashes. https://bugzilla.gnome.org/show_bug.cgi?id=765146 M monitor/udisks2/gvfsudisks2volume.c commit 466bfb2f025b741076e68480c86ad5bfa22f18a6 Author: Philip Langdale Date: 2016-04-10 MTP: Use improved libmtp event polling mechanism to fix unmount race Welcome to the end of this little road. With all the refactoring in place, we are now in a position to introduce the use of LIBMTP_Read_Event_Async. This version of Read_Event uses an explicit asynchronous API, which gives us more control over how long it blocks in a polling call, and what happens if it is interrupted. According to libusb documentation, a blocking poll will be interrupted when the device being polled is closed. This means we should be able to block indefinitely, and close the device during our unmount and have the poll call return so our thread can terminate cleanly. In theory, this approach should work with the original poll mechanism using the synchronous API, but that seems risky based on the crashes we've seen. When the synchronous API is interrupted, it returns to code (in libusb) that doesn't actually stop polling; it will attempt to start the poll operation again. This leads to a segfault as the device state is gone. By using the explicit asynchronous API, we are able to ensure that only safe code is called after the interruption. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=761278 M configure.ac M daemon/gvfsbackendmtp.c M daemon/gvfsbackendmtp.h commit e625ffe4fbab40a1b2d25a67308c8dafe8e71212 Author: Philip Langdale Date: 2016-04-10 MTP: Move handling of events to a thread pool In the next, and hopefully final, change in this series, I'm going to introduce a new way of checking for events that avoids the race condition which can lead to crashes on unmount in the current code. As part of that, event handling must move off the checking thread to a separate thread. But even the existing checking mechanism could stand to benefit from using a separate thread. It's generally undesirable for a thread that's polling for activity to potentially block for a long time, and this is what could happen today if there's a long transfer happening when an event comes in. With the separate handler thread, we can dispatch the work and then resume polling for activity quickly. I used a single-thread thread pool to handle the heavy lifting of queuing events - there's no benefit to writing that yourself. Finally, some thoughts on synchronization: 1) The thread pool has the lifetime of the backend. It is important not to tie it to mount state, as this would lead to requiring holding the backend mutex to know it is safe to push an event to the pool, and that brings us back to potentially blocking the checking thread again. 2) While the thread pool needs the extended lifetime, we don't want to handle events once unmount has started. We enforce this in two ways. a) We set the pool thread count to 0 in unmount. From here on, newly queued events will not get dispatched. b) We reorder the checks in handle_event() so that it always attempts to take the backend mutex first. After taking the mutex, it will check if an unmount is underway. This ensures that either an unmount has not started and it is safe to handle the event, or the unmount is complete, and we know we should drop the event. M daemon/gvfsbackendmtp.c M daemon/gvfsbackendmtp.h commit 50f92a55e8a08855cb684eedcc7eed5eeee01e4f Author: Philip Langdale Date: 2016-04-10 MTP: Refactor event handling into a separate function In preparation for moving event handling to a separate thread from checking, let's break handling out as a separate function. Let's also move the conditional check and mutex locking out of each individual case block. M daemon/gvfsbackendmtp.c commit 00ed5c6320d9cab35e5a4c12f3e35ec10dc3fb62 Author: Ondrej Holy Date: 2016-04-12 sftp: Show original hostname in the password prompt Server shortcuts may be configured in ~/.ssh/config. Shortcut name may be used in the URI consequently, however underlying SSH daemon connects to the original hostname, which might be confusing and potential security issue. Show the original hostname in the password prompt from the mentioned reasons. https://bugzilla.gnome.org/show_bug.cgi?id=688308 M daemon/gvfsbackendsftp.c commit 507e1a3eb2eed3983beb9d2e07b15b2bf285bfd3 Author: Ondrej Holy Date: 2016-04-15 Post branch version bump M configure.ac commit 4a156988465cb86ee40f0d4454f5c38f895b92f8 Author: Ondrej Holy Date: 2016-04-13 sftp: Fix hostname and ip name parsing The value returned from strchr is immediately incremented. So NULL is incremented if char is not found, therefore consequent check is always true and next strchr can cause a segfault. https://bugzilla.gnome.org/show_bug.cgi?id=545445 M daemon/gvfsbackendsftp.c commit 442ccb08616dcfac4e5554ba9c43b50668192f3a Author: Ondrej Holy Date: 2016-04-11 Post release version bump M configure.ac