Check thread safety of PermissionManager initialization
Categories
(Core :: Permission Manager, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox136 | --- | fixed |
People
(Reporter: jstutte, Assigned: jstutte)
References
Details
Attachments
(2 files)
There is at least a known minimal possibility for a race on GetInstance.
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
It looks like PermissionManager::GetInstance wants to avoid to take the sCreationMutex lock that GetXPCOMSingleton actually takes. I assume this "just works" as is currently because we can kind of rely on finding either nullptr or the entirly written correct pointer in gPermissionManager due to pseudo-atomical behavior of 64Bit writes on most of the systems of interest. But we could make this explicit either by:
- Making
gPermissionManageratomic or - just always call
GetXPCOMSingletondirectly, if we think it is not too performance critical to take the creation lock.
It is worth mentioning that PermissionManager is NS_DECL_THREADSAFE_ISUPPORTS which implies IMHO that at least creation and destruction of the singleton should be entirely thread safe.
| Assignee | ||
Comment 2•1 year ago
|
||
This patch makes PermissionManager::GetInstance do the instantiation
work and GetXPCOMSingleton just uses it.
We always acquire the creation mutex and return an already_AddRefed to
avoid any possible race. We count on callers of GetInstance to
(shortly) keep a local reference if they have more work to do.
On async shutdown in the parent process, we first mark our singleton
dead, then close all our resources async and finally null our instance
holder only after the async shutdown has finished.
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Comment 5•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/2636a0d71a2f
https://hg.mozilla.org/mozilla-central/rev/b2b47f64fd35
Updated•1 year ago
|
Description
•