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:
@@ -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);
|
||||
|
||||
Reference in New Issue
Block a user