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
This commit is contained in:
parent
cc18faf4d6
commit
c9e873f274
1 changed files with 1 additions and 1 deletions
|
@ -353,8 +353,8 @@ bool FuseBridgeLoop::ProcessEventLocked(const std::unordered_set<FuseBridgeEntry
|
|||
}
|
||||
if (entry->IsClosing()) {
|
||||
const int mount_id = entry->mount_id();
|
||||
callback->OnClosed(mount_id);
|
||||
bridges_.erase(mount_id);
|
||||
callback->OnClosed(mount_id);
|
||||
if (bridges_.size() == 0) {
|
||||
// All bridges are now closed.
|
||||
return false;
|
||||
|
|
Loading…
Reference in a new issue