Fix deadlock in BackupManagerService
Lock ordering bug. The fix is to avoid having to hold both locks simultaneously in one prong of the deadlock. (Further strengthening: the code path for potentially acquiring both simultaneously now begins at a common method, ensuring that lock ordering is always consistent.) Change-Id: If9433aff8326fec2ba0e97e96ad2d835b01e2cda
This commit is contained in:
@@ -760,15 +760,15 @@ class BackupManagerService extends IBackupManager.Stub {
|
||||
sf.delete();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Enqueue a new backup of every participant
|
||||
int N = mBackupParticipants.size();
|
||||
for (int i=0; i<N; i++) {
|
||||
int uid = mBackupParticipants.keyAt(i);
|
||||
HashSet<ApplicationInfo> participants = mBackupParticipants.valueAt(i);
|
||||
for (ApplicationInfo app: participants) {
|
||||
dataChangedImpl(app.packageName);
|
||||
}
|
||||
// Enqueue a new backup of every participant
|
||||
int N = mBackupParticipants.size();
|
||||
for (int i=0; i<N; i++) {
|
||||
int uid = mBackupParticipants.keyAt(i);
|
||||
HashSet<ApplicationInfo> participants = mBackupParticipants.valueAt(i);
|
||||
for (ApplicationInfo app: participants) {
|
||||
dataChangedImpl(app.packageName);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user