> >> Now this seems more relevant: > >> > >> mroos@rx100s2:~/linux$ nice git bisect good > >> 24dea04767e6e5175f4750770281b0c17ac6a2fb is the first bad commit > >> commit 24dea04767e6e5175f4750770281b0c17ac6a2fb > >> Author: Daniel Borkmann <dan...@iogearbox.net> > >> Date: Fri May 4 01:08:23 2018 +0200 > >> > >> bpf, x32: remove ld_abs/ld_ind > >> > >> Since LD_ABS/LD_IND instructions are now removed from the core and > >> reimplemented through a combination of inlined BPF instructions and > >> a slow-path helper, we can get rid of the complexity from x32 JIT. > > > > This does seem much more likely than the previous bisection, given > > that you ended up in an x86-32 specific commit (the subject says x32, > > but that is a mistake). I also checked that systemd indeed does > > call into bpf in a number of places, possibly for the journald socket. > > > > OTOH, it's still hard to tell how that commit can have ended up > > corrupting the clock read function in systemd. To cross-check, > > could you try reverting that commit on the latest kernel and see > > if it still works? > > I would be curious as well about that whether revert would make it > work. What's the value of sysctl net.core.bpf_jit_enable ? Does it > change anything if you set it to 0 (only interpreter) or 1 (JIT > enabled). Seems a bit strange to me that bisect ended at this commit > given the issue you have. The JIT itself was also new in this window > fwiw. In any case some more debug info would be great to have.
net.core.bpf_jit_enable is 1. Since it breaks bootup, I can not easily change the value at runtime (it would be postfactum). Do you mean changing the CONFIG_BPF_JIT_ALWAYS_ON=y option? Anyway, I started compile of v4.18-rc5 that was the latest I tested, with the commit in question reverted. Will see if I can test tomorrow morning. But I will leave tomorrow for a week and can only test further things if they happen to boot fine (no manual reboot possible for a week). -- Meelis Roos (mr...@linux.ee)
