mirror of
https://github.com/facebook/sapling.git
synced 2024-10-08 07:49:11 +03:00
fe919940bc
Summary: If EdenMount::shutdownImpl and EdenMount::startFuse execute concurrently, the mount's `state_` might end up inconsistent. For example, for the following sequence of events, EdenMount::shutdownImpl is erroneously called twice: 1. EdenMount::initialize transitions the mount's state to INITIALIZED. 2. EdenMount::startFuse begins and transitions the mount's state to STARTING. 3. EdenMount::shutdown begins and transitions the mount's state to SHUTTING_DOWN. 4. EdenMount::shutdown finishes and transitions the mount's state to SHUT_DOWN. 5. EdenMount::startFuse finishes due to FuseChannel::initialize failing with an error and transitions the mount's state to FUSE_ERROR. 6. EdenMountDeleter calls EdenMount::destroy, which observes that the mount's state is FUSE_ERROR. EdenMount::destroy proceeds by calling EdenMount::shutdownImpl. This specific scenario can't happen in production right now because step 3 requires allowFuseNotStarted to be true (and it's never true in production). A similar scenario can happen with EdenMount::startFuse+EdenMount::destroy running currently, but the effects are benign. However, in a future diff (D14015024), I am changing how EdenMount::destroy works, and the SHUT_DOWN -> FUSE_ERROR transition causes problems. When FuseChannel::initialize returns an error, transition the mount to the FUSE_ERROR state only if we are not already shutting down (instead of unconditionally). This fixes the [impossible] scenario above, and also fixes EdenMount::destroy in a future diff. Reviewed By: simpkins Differential Revision: D14030898 fbshipit-source-id: fe5a749b8798749734e0de91eb3b71b601ebb64b |
||
|---|---|---|
| .. | ||
| benchmarks | ||
| cli | ||
| docs | ||
| fs | ||
| integration | ||
| py | ||
| scripts | ||
| test_support | ||
| test-data | ||
| third-party | ||
| win | ||
| .gitignore | ||
| .pyre_configuration.local | ||
| Eden.project.toml | ||