Re: dump, restore

On Sat, 3 Aug 2024, Stan Johnson wrote:

> 
> Using "-a" appears to be a better option than just specifying a really
> long tape size. Unfortunately, it also doesn't work. The problem seems
> to affect only m68k; ppc-32, ppc-64, x86-32 and x86-64 all work as
> expected...

I reproduced the problem in QEMU and found it went away when I ran dump 
under Linux v5.6. So I went through a lot of "git bisect" steps and the 
culprit appears to be commit ef2c41cf38a7 ("clone3: allow spawning 
processes into cgroups"). That seems plausible, since we are seeing an 
error from fork_clone_io() below...

#ifdef __linux__
#if defined(SYS_clone) && defined(CLONE_IO)
pid_t
fork_clone_io(void)
{
        return syscall(SYS_clone, CLONE_ARGS);
}
#endif
#endif

That code bypasses the C library so I suppose it's not too surprising that 
different architectures give different results...

Anyway, if I run dump under strace I see no CLONE_INTO_CGROUP flag:

clone(child_stack=NULL, flags=CLONE_IO|SIGCHLD) = -1 EBADF (Bad file descriptor)

The -EBADF result was introduced into cgroup_css_set_fork() by the commit 
above. That should not happen unless CLONE_INTO_CGROUP was set, but strace 
says its not. So I don't know what's going on here.