Re: siginfo pid not populated from ptrace?

[Tycho Andersen]

On Mon, Nov 12, 2018 at 12:30:25PM -0600, Eric W. Biederman wrote:
> Tycho Andersen <tycho@xxxxxxxx> writes:
> 
> > Hi Oleg,
> >
> > I've been running some tests on my seccomp series, and in one of the
> > tests on v4.20-rc2, I noticed,
> >
> > [ RUN      ] global.syscall_restart
> > seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (1492) == info._sifields._kill.si_pid (0)
> > global.syscall_restart: Test failed at step #22
> >
> > which seems unrelated to my series (the kernel was stock v4.20 with my
> > patches on top).
> >
> > I've been running a lot of tests, and only seen this once, so it seems
> > like a fairly rare race. I tried to look through the code but didn't
> > see anything obvious. Thoughts?
> 
> My guess would be pid namespaces, or stopping for a signal other than
> SIGSTOP.
> 
> If you can get this to reproduce at all it would be interesting to see
> si_signo and si_code.  So that we can see just which signal is in info,
> and how it should be decoded. 

Sure, here's what I see,

seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (2195) == info._sifields._kill.si_pid (0)
seccomp_bpf.c:2785:global.syscall_restart:si_signo: 19
seccomp_bpf.c:2786:global.syscall_restart:si_code: 0

> I see this test at line 2736 in 4.20-rc1 so there are almost 50 lines of
> change in your version of seccomp_bpf.c.  So I hope I am reading the
> proper test.

Yes, sorry, that's additional test stuff from my user trap series. I
haven't manage to reproduce it on stock v4.20-rc2, unfortunately. It
could be that this is some memory corruption introduced by my series,
but I'm running these tests with KASAN so hopefully it would complain?

Tycho