There are two locks used by AppFuseBridge.
First is it's object lock, and the second is a mutex lock in app fuse library.
There are two oppsite routines to get those locks.
(Thread A) Got Java lock -> Try to get Native lock
(Thread B) Got Native lock -> Try to get Java lock
Bug : https://issuetracker.google.com/issues/145707568
Signed-off-by: hyeeun.jun@samsung.com <hyeeun.jun@samsung.com>
The order must be followed to obtain two locks.
If not, the dead lock will be caused.
Therefore we change the routine to get the mutex lock first, and the object lock later.
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
When reading/writing proxy FD, if it returns EAGAIN,
BridgeEpollController updates epoll entries to observe specific FD
events. Before updating epoll entries, BridgeEpollController checks if
it really needs to update by comparing |state_| and |last_state_|.
|last_state_| has not been updated correctly so it resulted in wrong
epoll settings and keeps blocking the event loop.
Bug: 134104939
Test: atest libappfuse_test
Change-Id: I1c4a0164c1c016baf24ecfd523476ced981d3b28
The ScopedLogSeverity was added to observe APCT failures, which turned
out to be a compiler optimization error.
Bug: 62429763
Test: None
Change-Id: Ibb45d018d8eaf4b29cb417da80ae5f0b000dda8e
APCT log shows that we got FUSE request unique=0 and replying to such
request causes a EINVAL.
The possible reasons of getting unique=0 here are:
* /dev/fuse actually submits such requests. In this case, not replying
to such request probabbly safe as the kernel cannot wait corresponding
response without a unique number. We can observing the kernel code to
find out what unique=0 actually means.
* Memory corruption happens and unique number are cleared with zero.
In this case, if we skip unique=0 request, libappfuse does not reply
to the kernel request and APCT result will become timeout .
To see which case happens, the CL ScopedLogSeverity to output
verbose logs and lets FuseBridgeLoop skip a request from /dev/fuse if unique=0.
Bug: 62429763
Test: libappfuse_tests
Change-Id: I8c4d532564b690d55573b92260170b0cd68150ab
The CL turns StartFuseBridgeLoop function into FuseBridgeLoop class, and
adds a method adding new appfuse mount to the loop.
After doing this, one FuseBridgeLoop can process FUSE commands from
multiple AppFuse mounts.
Bug: 34903085
Test: libappfuse_test
Change-Id: I54f11f54bc26c551281b9c32e9bb91f8f043774c
The CL changes FuseBridgeLoop so that it exits when all files opened on
the AppFuse mount point are closed. Note that the client code will
unmount the FUSE mount point after the loop exits.
Bug: 32260320
Test: libappfuse_test
Change-Id: I4965fbb48de8a280c6306e70757a07376b1956a7
The class is used at the app side (StorageManager) to parse FUSE
commands.
Bug: 32260320
Test: libappfuse_test
Change-Id: I1ae2904d3290a041f1efbf8fc10ba032eda5449c
The CL adds FuseBridgeLoop class to libappfuse, which is used in the
system service to proxy fuse commands to applications.
Bug: 29970149
Test: libappfuse_test
Change-Id: I0708f608b3868721ab16ba4028fd2c17a6735af7
