[PATCH v10 0/5] [PIDNS] Final

[Ákos Uzonyi]

On Thu, 20 Aug 2020 at 17:56, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Thu, Aug 20, 2020 at 04:19:25PM +0300, Dmitry V. Levin wrote:
> > On Thu, Aug 20, 2020 at 03:11:23PM +0200, Ákos Uzonyi wrote:
> > > On Thu, 20 Aug 2020 at 13:44, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > On Thu, Aug 20, 2020 at 01:38:34PM +0200, Ákos Uzonyi wrote:
> > > > > On Thu, 20 Aug 2020 at 11:34, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > When I tried this patchset on various systems, on those where NS_* ioctl
> > > > > > commands are not supported by the kernel, a lot of tests start failing with
> > > > > > similar diagnostics.  For example:
> > > > > >
> > > > > > FAIL: dup-y.gen
> > > > > > ===============
> > > > > >
> > > > > > + ../strace -V
> > > > > > + TIMEOUT='timeout -k 5 -s XCPU 2100'
> > > > > > + timeout -k 5 -s XCPU 2100 true
> > > > > > + '[' 1 -eq 0 ']'
> > > > > > + exec timeout -k 5 -s XCPU 2100 ./dup-y.gen.test
> > > > > > + run_strace_match_diff -a8 --trace=dup -y
> > > > > > + args='-a8 --trace=dup -y'
> > > > > > + '[' -n '-a8 --trace=dup -y' -a '(' -z '-a8 --trace=dup -y' -o -z '' ')' ']'
> > > > > > + run_prog
> > > > > > + '[' 0 -eq 0 ']'
> > > > > > + set -- ../dup-y
> > > > > > + args=../dup-y
> > > > > > + ../dup-y
> > > > > > + run_strace -a8 --trace=dup -y ../dup-y
> > > > > > + args='-a8 --trace=dup -y ../dup-y'
> > > > > > + ../../strace -o log -a8 --trace=dup -y ../dup-y
> > > > > > ../../strace: NS_* ioctl commands are not supported by the kernel
> > > > > > + match_diff log exp
> > > > > > + local output expected error
> > > > > > + '[' 2 -eq 0 ']'
> > > > > > + output=log
> > > > > > + shift
> > > > > > + '[' 1 -eq 0 ']'
> > > > > > + expected=exp
> > > > > > + shift
> > > > > > + '[' 0 -eq 0 ']'
> > > > > > + error='../../strace -a8 --trace=dup -y ../dup-y output mismatch'
> > > > > > + check_prog diff
> > > > > > + type diff
> > > > > > + diff -u -- exp log
> > > > > > --- exp 2020-08-20 00:53:31.868741256 +0000
> > > > > > +++ log 2020-08-20 00:53:31.868741256 +0000
> > > > > > @@ -1,5 +1,5 @@
> > > > > >  dup(-1) = -1 EBADF (Bad file descriptor)
> > > > > > -dup(0</dev/null>) = 3</dev/null>
> > > > > > -dup(3</dev/null>) = 4</dev/null>
> > > > > > -dup(9</dev/full>) = 5</dev/full>
> > > > > > +dup(0)  = 3
> > > > > > +dup(3)  = 4
> > > > > > +dup(9)  = 5
> > > > > >  +++ exited with 0 +++
> > > > > > + fail_ '../../strace -a8 --trace=dup -y ../dup-y output mismatch'
> > > > > > + warn_ 'dup-y.gen.test: failed test: ../../strace -a8 --trace=dup -y ../dup-y output mismatch'
> > > > > > + printf '%s\n' 'dup-y.gen.test: failed test: ../../strace -a8 --trace=dup -y ../dup-y output mismatch'
> > > > > > dup-y.gen.test: failed test: ../../strace -a8 --trace=dup -y ../dup-y output mismatch
> > > > > > + exit 1
> > > > > > FAIL dup-y.gen.test (exit status: 1)
> > > > >
> > > > > Interesting. On travis we have some systems where NS_* ioctl commands
> > > > > are not supported, and all tests pass. I think the problem is caused
> > > > > by is_proc_ours returning false (otherwise translation should be
> > > > > trivial, and no NS_ ioctl commands would be needed). First I thought
> > > > > that /proc is not mounted on that system, but dup-y is skipped if
> > > > > /proc/self/fd is not available (anyway we should check if /proc is
> > > > > mounted and return 0 in translate_pid if not). Also I think we could
> > > > > print error messages if /proc/%s/ns/pid or /proc/%s/status is not
> > > > > available. Is it possible that these are not available on this system?
> > > >
> > > > No, both /proc/self/status and /proc/self/ns/pid are available, and
> > > > $ readlink /proc/self/ns/pid
> > > > pid:[4026532619]
> > > > they look plausible.
> > > >
> > > > FWiW, the host where I first seen this is
> > > > Linux el7-test.fedorainfracloud.org 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > Interesting, the kernel version is 3.10.0, the test should have been
> > > skipped by check_ns_ioctl. Or is it possible somehow that
> > > NS_GET_USERNS is available and NS_GET_PARENT is not?
> >
> > As that is a vendor kernel, everything is possible.
> > I can check this.
>
> No, in that system NS_GET_USERNS fails with ENOTTY:
>
> open("/proc/self/ns/pid", O_RDONLY) = 3
> ioctl(3, NS_GET_USERNS) = -1 ENOTTY (Inappropriate ioctl for device)

Thanks for checking it.

I realized I was wrong, as check_ns_ioctl is not called in dup-y test
(it's not a pidns test). I think get_proc_pid returns false for some
reason, and that causes this problem. I'll send a patch that adds more
error messages, could you please run the test again with that patch
applied?