On Mon, Nov 12, 2018 at 12:30:25PM -0600, Eric W. Biederman wrote: > Tycho Andersen <ty...@tycho.ws> 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
