| Summary: | psuedo path mismatch during image build | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Ross Burton <ross.burton> |
| Component: | core | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie, ross.burton |
| Version: | 3.4 | ||
| Target Milestone: | 3.3 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | AB-INT | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Ross Burton
2021-01-11 12:46:31 UTC
RP: Looks like mkstemp is racing with pseudo occasionally. Encounterd when using apt but likely happening elsewhere from time to time. There was a recent fix in pseudo for rename() handling. We may want to audit the apt codepaths to see if that rename issue could have caused this. The worry is the rename()+fstat() issue should reproduce all the time and this does not. https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1341/steps/14/logs/stdio pid 959642 [parent 959629], doing new pid setup and server start Setup complete, sending SIGUSR1 to pid 959629. path mismatch [1 link]: ino 88221442 db '/home/pokybuild/yocto-worker/oe-selftest/build/build-st-2079038/reproducibleB/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/apt/lists/partial/_home_pokybuild_yocto-worker_oe-selftest_build_build-st-2079038_reproducibleB_tmp_work_qemux86%5f64-poky-linux_core-image-sato_1.0-r0_oe-rootfs-repo_all_._Release.oY00En' req '/home/pokybuild/yocto-worker/oe-selftest/build/build-st-2079038/reproducibleB/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/apt/lists/partial/_home_pokybuild_yocto-worker_oe-selftest_build_build-st-2079038_reproducibleB_tmp_work_qemux86%5f64-poky-linux_core-image-sato_1.0-r0_oe-rootfs-repo_all_._Release'. db cleanup for server shutdown, 03:04:13.117 memory-to-file backup complete, 03:04:13.118. db cleanup finished, 03:04:13.118 pseudo.log (END) so definitely still present I suspect what is is happening is that in between pseudo calling real_rename() and then running OP_RENAME on the pseudo database, something is calling something like stat() on the newpath. This stat call would have the same inode as oldpath and oldpath would still be in the database but isn't marked as MAY_UNLINK so this abort triggers. The fix is likely to mark oldpath as MAY_UNLINK in the database before real_rename call. |