g_lock_trylock() always incremented the counter 'i', even after cleaning a stale
entry at position 'i', which means it skipped checking for a conflict against
the new entry at position 'i'.
As result a process could get a write lock, while there're still
some read lock holders. Once we get into that problem, also more than
one write lock are possible.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13195
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Wed Dec 20 20:31:48 CET 2017 on sn-devel-144
(similar to commit
576fb4fb5dc506bf55e5cf87973999dca444149b)
Autobuild-User(v4-6-test): Karolin Seeger <kseeger@samba.org>
Autobuild-Date(v4-6-test): Fri Dec 22 22:11:00 CET 2017 on sn-devel-144
return NT_STATUS_INTERNAL_ERROR;
}
- for (i=0; i<num_locks; i++) {
+ i=0;
+
+ while (i < num_locks) {
if (serverid_equal(&self, &locks[i].pid)) {
status = NT_STATUS_INTERNAL_ERROR;
goto done;
locks[i] = locks[num_locks-1];
num_locks -= 1;
modified = true;
+ continue;
}
+ i++;
}
tmp = talloc_realloc(talloc_tos(), locks, struct g_lock_rec,