chmod: use the libc fchmodat symbol for recursive mode changes - #14121
Conversation
|
GNU testsuite comparison: |
Merging this PR will improve performance by 3.22%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | Simulation | du_summarize_balanced_tree[(5, 4, 10)] |
16.5 ms | 15.9 ms | +3.42% |
| ⚡ | Simulation | cksum_sysv |
68.4 ms | 66.2 ms | +3.32% |
| ⚡ | Simulation | cksum_crc32b |
39.7 ms | 38.5 ms | +3.11% |
| ⚡ | Simulation | cksum_multiple_files |
61.5 ms | 59.7 ms | +3.01% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing sylvestre:preload (e3e5876) with main (ebb9ab1)
Footnotes
-
50 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
The raw syscall(SYS_fchmodat2, ...) in DirFd::chmod_at bypassed LD_PRELOAD tools (fakeroot, fakechroot, pseudo), so a recursive mode change landed on disk but their bookkeeping never saw it, silently and with exit status 0. Try libc fchmodat() first and keep the raw syscall as a fallback for the NoFollow case libc declines; glibc issues fchmodat2 from there anyway. Add util/check-libc-interposition.sh, which runs chown -R and chmod -R under fakeroot and compares what fakeroot reports afterwards. Fixes uutils#14028
|
@nadzyah |
|
@codspeedbot explain why this is faster |
|
@sylvestre hey! Sorry, I didn't review it this quickly as I wanted to test the change I've verified that it fixes the issue. I reverted Thank you for the fix! |
|
@nadzyah np and thanks for testing ! |
Fixes #14028