This is the mail archive of the
mailing list for the glibc project.
Re: V7 test-in-container patch
- From: Florian Weimer <fweimer at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org, joseph at codesourcery dot com, carlos at redhat dot com
- Date: Thu, 16 Aug 2018 09:58:33 +0200
- Subject: Re: V7 test-in-container patch
- References: <email@example.com>
On 08/16/2018 01:57 AM, DJ Delorie wrote:
Hurd doesn't have unshare, so you need to avoid building the container
Is it OK to return UNSUPPORTED for those? I don't think it makes sense
to try to work around the whole containerized-test setup if containers
UNSUPPORTED would work there. If the Hurd maintainers do not like it,
we could probably filter out test-containers tests there.
The Red Hat Enterprise Linux 7 kernel doesn't seem to like this
combination of flags, even as root:
unshare(CLONE_NEWNS|CLONE_NEWUSER|CLONE_NEWPID) = -1 EINVAL (Invalid
Is CLONE_NEWPID really required?
Yes. You can't mount /proc without it. Don't ask me why ;-)
Can you perform a bind mount of the existing /proc instead? Maybe you
can drop the CLONE_NEWPID this way.
If the bind mount doesn't work, I suggest to ask internally what our
kernel needs to get this working.
My concern about the over-use of FAIL_UNSUPPORTED and the UNSUPPORTED
test status in the container framework remains. Sure, there are some
things that can fail due to missing host support, but e.g. a fork file
shouldn't lead to UNSUPPORTED, but FAIL.
I replaced them all with FAILs. I was trying to keep "failure of the
test" separate from "failure of the test harness" but I'm OK with it
It's hard to draw a line. Fork failures in particular tend to leak
between tests because of kernel bugs (still unfixed upstream,