On Wed, Aug 28, 2019 at 6:30 PM Paul Walmsley <paul.walmsley@xxxxxxxxxx> wrote: > On Mon, 26 Aug 2019, Kees Cook wrote: > > > On Mon, Aug 26, 2019 at 09:39:50AM -0700, David Abdurachmanov wrote: > > > I don't have the a build with SECCOMP for the board right now, so it > > > will have to wait. I just finished a new kernel (almost rc6) for Fedora, > > > > FWIW, I don't think this should block landing the code: all the tests > > fail without seccomp support. ;) So this patch is an improvement! > > Am sympathetic to this -- we did it with the hugetlb patches for RISC-V -- > but it would be good to understand a little bit more about why the test > fails before we merge it. The test is almost certainly failing due to the environmental requirements (i.e. namespaces, user ids, etc). There are some corner cases in there that we've had to fix in the past. If the other tests are passing, then I would expect all the seccomp internals are fine -- it's just the case being weird. It's just a matter of figuring out what state the test environment is in so we can cover that corner case too. > Once we merge the patch, it will probably reduce the motivation for others > to either understand and fix the underlying problem with the RISC-V code > -- or, if it truly is a flaky test, to drop (or fix) the test in the > seccomp_bpf kselftests. Sure, I get that point -- but I don't want to block seccomp landing for riscv for that. I suggested to David offlist that the test could just be marked with a FIXME XFAIL on riscv and once someone's in a better position to reproduce it we can fix it. (I think the test bug is almost certainly not riscv specific, but just some missing requirement that we aren't handling correctly.) How does that sound? -Kees
