commit d60428264fdd9a2281308ea45f6fbae4512eb061
Author: Ondrej Holy <oholy@redhat.com>
Date: 2016-04-25
Update NEWS for 1.29.1 release
M NEWS
commit fd36dd9e1074a4b69d1f05a2c1e201522a288a83
Author: Ondrej Holy <oholy@redhat.com>
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 <philipl@overt.org>
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 <philipl@overt.org>
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 <philipl@overt.org>
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 <oholy@redhat.com>
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 <oholy@redhat.com>
Date: 2016-04-15
Post branch version bump
M configure.ac
commit 4a156988465cb86ee40f0d4454f5c38f895b92f8
Author: Ondrej Holy <oholy@redhat.com>
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 <oholy@redhat.com>
Date: 2016-04-11
Post release version bump
M configure.ac