BPathMonitor: Lock on incoming node monitor messages.

The lock was only acquired when paths to watch were added or removed,
protecting the data structures against concurrent modification due
to addition/removal of entries by the API user.

Locking is also required for node monitor messages since these can
trigger the data structures to be modified (due to recursive watching
and new directories becoming available or due to resyncing of modified
ancestor chains).

Previously it was possible to corrupt the data structures when node
monitor messages were received while still starting to watch a directory
structure. This was especially likely in the case of watching devfs
directories, as accessing these can trigger device scanning which in
turn could possibly add new device entries. Either the path monitor
looper or the API user would then trip over the corrupted data
structures.

Probably fixes #11280. Although I was only able to reproduce crashes
on the API side, corruption of the hash tables and corresponding endless
loops are quite plausible.

Possibly also fixes #12412 if the input_server was in the process of
starting to watch entries. It's hard to tell due to the lack of a back
trace but would fit the crashes I was able to reproduce with a synthetic
test case.
This commit is contained in:
Michael Lotz
2015-11-07 09:52:20 +01:00
parent f22bfa7665
commit 8599f4b330
+1
View File
@@ -903,6 +903,7 @@ PathHandler::MessageReceived(BMessage* message)
if (message->FindInt32("opcode", &opcode) != B_OK)
return;
BAutolock _(sLocker);
switch (opcode) {
case B_ENTRY_CREATED:
_EntryCreated(message);