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.
Reply to: