On Mon, Jan 27, 2025 at 11:23:52PM -0800, Darrick J. Wong wrote: > On Tue, Jan 28, 2025 at 03:34:50PM +1100, Dave Chinner wrote: > > On Thu, Jan 23, 2025 at 12:16:50PM +1100, Dave Chinner wrote: > > 4. /tmp is still shared across all runner instances so all the > > > > concurrent runners dump all their tmp files in /tmp. However, the > > runners no longer have unique PIDs (i.e. check runs as PID 3 in > > all runner instaces). This means using /tmp/tmp.$$ as the > > check/test temp file definition results is instant tmp file name > > collisions and random things in check and tests fail. check and > > common/preamble have to be converted to use `mktemp` to provide > > unique tempfile name prefixes again. > > > > 5. Don't forget to revert the parent /proc mount back to shared > > after check has finished running (or was aborted). > > > > I think with this (current prototype patch below), we can use PID > > namespaces rather than process session IDs for check-parallel safe > > process management. > > > > Thoughts? > > Was about to go to bed, but can we also start a new mount namespace, > create a private (or at least non-global) /tmp to put files into, and > then each test instance is isolated from clobbering the /tmpfiles of > other ./check instances *and* the rest of the system? We probably can. I didn't want to go down that rat hole straight away, because then I'd have to make a decision about what to mount there. One thing at a time.... I suspect that I can just use a tmpfs filesystem for it - there's heaps of memory available on my test machines and we don't use /tmp to hold large files, so that should work fine for me. However, I'm a little concerned about what will happen when testing under memory pressure situations if /tmp needs memory to operate correctly. I'll have a look at what is needed for private tmpfs /tmp instances to work - it should work just fine. However, if check-parallel has taught me anything, it is that trying to use "should work" features on a modern system tends to mean "this is a poorly documented rat-hole that with many dead-ends that will be explored before a working solution is found"... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
