chdir ends its VFS guard before taking process-data, the order open takes

issues/a-user-copy-demand-pages-under-whatever-its-caller-holds.md

@@ -16,6 +16,12 @@ lock on the first unmapped window: it spins, and the kernel panics
 "DEADLOCK at …" (`Lock::lock`, `kernel/src/sync.rs`). Nothing in the tree
 refuses that order: no lock-order check covers these locks.
 
+The global VFS lock (`vfs::lock()`) is a fourth nothing orders. `ops::open`
+takes it under `process_data`, and `sys_chdir` took `process_data` under it
+until its guard was made to end before the store; that no holder of the VFS
+guard takes `process_data` is held by reading alone. A checked lock level
+ranks it with the three.
+
 **Exit:** the order is refused by something that fails (a type or a
 checked lock level), or every caller is shown to hold none of the three and
 the invariant is one line in `user_ptr.rs`'s header.

issues/clippy-stage-two-is-lints-one-at-a-time.md

@@ -124,6 +124,12 @@ before adopting:
   "this device's memory has one owner, enforced by the driver, not by the
   type." Two of three already carry a `# Safety`/`SAFETY:` comment saying so.
 
+## Measured, not decided
+
+| lint | count | what was measured, and what it does not see |
+|---|---:|---|
+| `significant_drop_in_scrutinee` | 6, 1 a defect | Silent in the gate: it reports only a guard marked `#[clippy::has_significant_drop]`, and no kernel guard is. With `sync::LockGuard` alone marked, the kernel under `x86_64-unknown-none` with default features reported 6 sites, and 5 once `sys_chdir` stopped holding the VFS guard into `process_data` — the one defect. The 5 left (`arch/x86_64/idt/mod.rs`'s `for` over `IDT.lock()`, `loader/mod.rs`'s `/system/lib` fallback, `user_ptr::translate_user`, `sys_readdir`, `sys_dlopen`) take no second lock under the guard, and adopting the lint rewrites each. Unmeasured: AArch64, the actuator and instrument shapes, and the guards the measurement did not mark (`SleepGuard`, `block`'s `Locked`, the serial guard). It cannot join `ADOPTED`, which `src/clippy.rs` splices into the host workspace's shapes too, where std's `MutexGuard` is already marked: it would be a per-shape `-W`, as `undocumented_unsafe_blocks` is. **It sees one spelling, not the order**: an `if let Some(x) = L.lock().as_mut()` whose value borrows from the guard is in the tree and in neither report (`file_cache::touch`, `scheduler::remove_vruntime`, `inbox`'s `answer`), and so is any inversion through a named guard, the common shape. |
+
 ## `undocumented_unsafe_blocks`, per area
 
 | area | unsafe blocks | status |

kernel/src/syscall/fs.rs

@@ -83,7 +83,9 @@ pub(super) fn sys_delete(path: &str) -> u64 {
 
 pub(super) fn sys_chdir(path: &str) -> u64 {
     let cwd = process::with_process_data(|d| d.cwd.clone());
-    match vfs::lock().cd(&cwd, path) {
+    // The VFS guard ends with this statement: `sys_open` takes VFS under process-data.
+    let resolved = vfs::lock().cd(&cwd, path);
+    match resolved {
         Ok(new_cwd) => {
             process::with_process_data(|d| d.cwd = new_cwd);
             0