Commit Graph

14 Commits

Author SHA1 Message Date
Brad Fitzpatrick
1b60843547 Framework-side support for Dalvik "isSensitiveThread" hook.
Used in lock contention stats.

Bug: 3226270
Change-Id: Ie6f58d130a29079a59bdefad40b80304d9bc3623
2010-12-14 09:28:16 -08:00
Dianne Hackborn
67f78c4fe8 Some debugging support.
- New feature to "am monitor" to have it automatically launch
  gdbserv for you when a crash/ANR happens, and tell you how to
  run the client.

- Update dumpstate to match new location of binder debug logs

- Various commented out logs that are being used to track down
  issues.

Change-Id: Ia5dd0cd2df983a1fc6be697642a4590aa02a26a5
2010-09-24 13:11:55 -07:00
Brad Fitzpatrick
5273603e98 Don't propagate StrictMode over one-way Binder calls.
This was causing stack stitching problems where a one-way call with
violations followed by a two-way call without violations was getting
the previous one-way call's violation stack stitched on to the second
caller's stack.

The solution is a little more indirect than I would've liked
(preserving the binder's onTransact flags until enforceInterface) but
was seemingly necessary to work without changing the AIDL compiler.
It should also be sufficiently cheap, since no new calls to
thread-local IPCThreadState lookups were required.  The additional
work is just same-thread getter/setters on the existing
IPCThreadState.

Change-Id: I4b6db1d445c56e868e6d0d7be3ba6849f4ef23ae
2010-08-31 13:16:49 -07:00
Brad Fitzpatrick
a877cd85b5 More StrictMode work, keeping Binder & BlockGuard's thread-locals in-sync.
Change-Id: Ia67cabcc17a73a0f15907ffea683d06bc41b90e5
2010-07-15 13:18:05 -07:00
Brad Fitzpatrick
702ea9d42f Start of work on passing around StrictMode policy over Binder calls.
This is (intendend to be) a no-op change.

At this stage, Binder RPCs just have an additional uint32 passed around
in the header, right before the interface name.  But nothing is actually
done with them yet.  That value should right now always be 0.

This now boots and seems to work.

Change-Id: I135b7c84f07575e6b9717fef2424d301a450df7b
2010-06-21 12:56:35 -07:00
Christopher Tate
440fd870b2 Ensure that binder incalls to the system process keep the fg cgroup
On binder incalls, the handler thread is given the caller's priority by the
driver, but not the caller's cgroup.  We have explicit code that sets the
handler's cgroup to match the caller's, *except* that the system process
explicitly disables this behavior.  This led to a siuation in which we were
running binder incalls to the system process at nice=10 but cgroup=fg.

That's fine as far as it goes, except that if a GC happened in the handler
thread, it would be promoted to foreground priority and cgroup both, to avoid
having the GC take forever.  Then, when GC finished, the original priority
is reset, and the cgroup set *based on that priority*.  This would push the
handler thread into nice=10 cgroup=bg_non_interactive -- which matches the
caller, but is supposed to be impossible in the system process.

The end result of this was that we could be running "lengthy" operations in
the system process in the background.  Unfortunately, some of the operations
that wound up like this would hold important global system locks for up to
twenty seconds as a result, making the entire device unresponsive to input
for that period.

This CL fixes the binder incall setup to ensure that within the system process,
a binder incall is always begun from the normal foreground priority as well
as cgroup.  In practice now the device still becomes laggy/sluggish when the
offending lock-holding time-consuming incall occurs, but since it still runs
as a foreground task it is able to proceed to completion within a short time
rather than taking 20 seconds.

Fixes bug #2403717

Change-Id: Id046aeabd0e80c48eef94accc37842835eab308d
2010-03-18 18:13:57 -07:00
Dianne Hackborn
8c6cedc9bc Propagate background scheduling class across processes.
This is a very simply implementation: upon receiving an IPC, if the handling
thread is at a background priority (the driver will have taken care of
propagating this from the calling thread), then stick it in to the background
scheduling group.  Plus an API to turn this off for the process, which is
used by the system process.

This also pulls some of the code for managing scheduling classes out of
the Process JNI wrappers and in to some convenience methods in thread.h.
2009-12-07 19:11:14 -08:00
Christopher Tate
07d69893e1 Reset binder service threads' cgroup/priority after command completion
To prevent buggy command implementations from poisoning binder threads'
scheduling class & priority for future command execution, we now reset the
cgroup and thread priority to foreground/normal when a binder service thread
finishes executing the designated command.

Change-Id: Ibc0ab2485751453f6dc96fdb4eb877fd02796e3f
2009-11-08 14:29:02 -08:00
Evan Millar
6dfe8f1ffa Revert jparks code from IPCThreadState. 2009-11-06 11:25:23 -08:00
Jason Parks
b5c4135333 When a thread is about to be put back onto the thread pool ensure that it is in the foreground cgroup. 2009-11-04 14:25:26 -08:00
Jason Parks
dcd3958c50 Add a warning when we leave threads in the binder thread pool in the background scheduling group. 2009-11-03 13:10:15 -08:00
Marco Nelissen
d43b194b69 Instead of using -1 for pid and uid in the simulator, and then having
to special-case the simulator case all over the framework, just use
getuid and getpid, and intercept those in the simulator wrapper.
2009-07-17 10:48:09 -07:00
Mathias Agopian
c5b2c0bf80 move libbinder's header files under includes/binder 2009-05-20 12:55:03 -07:00
Mathias Agopian
208059f67e checkpoint: split libutils into libutils + libbinder 2009-05-20 12:55:02 -07:00