system/core
| Revisão | c9e873f2747108cc6f010791c86569367d0bef44 (tree) |
|---|---|
| Hora | 2019-06-01 00:58:45 |
| Autor | Anton Hansson <hansson@goog...> |
| Commiter | Anton Hansson |
Close /dev/fuse FD before calling onClosed
This works around a deadlock when a bridge that is about to be closed
is reused for a new call to openFile. The call to open() ends up holding
the vold lock, waiting for appfuse to respond. The appfuse event loop
calls onClosed(), which ends up calling vold.unmountAppFuse(), which
cannot get the lock.
Closing this file descriptor causes any current calls to open() on its
mount path to fail with either ECONNABORTED or ENOTCONN, allowing the
event loop to make progress, call onClosed() and unmount the path.
Note that the failed call to open() will result in a retry, which
will create a new appfuse bridge. This is not ideal but not a new
problem -- the common case here is that that each call to
openProxyFileDescriptor creates a new bridge. This should ideally
be improved.
Bug: 132344997
Test: flick through info of photos with location info attached
Exempt-From-Owner-Approval: verbal approval of approach
Change-Id: I878e5cf86f18c5233f8505f52eb9db076bd72d01
libappfuse/FuseBridgeLoop.cc (diff)| @@ -353,8 +353,8 @@ bool FuseBridgeLoop::ProcessEventLocked(const std::unordered_set<FuseBridgeEntry | ||
| 353 | 353 | } |
| 354 | 354 | if (entry->IsClosing()) { |
| 355 | 355 | const int mount_id = entry->mount_id(); |
| 356 | - callback->OnClosed(mount_id); | |
| 357 | 356 | bridges_.erase(mount_id); |
| 357 | + callback->OnClosed(mount_id); | |
| 358 | 358 | if (bridges_.size() == 0) { |
| 359 | 359 | // All bridges are now closed. |
| 360 | 360 | return false; |
Fork