From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE297ECDFB8 for ; Mon, 23 Jul 2018 19:41:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6E70F20685 for ; Mon, 23 Jul 2018 19:41:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E70F20685 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=iogearbox.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388156AbeGWUoZ (ORCPT ); Mon, 23 Jul 2018 16:44:25 -0400 Received: from www62.your-server.de ([213.133.104.62]:50103 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726943AbeGWUoZ (ORCPT ); Mon, 23 Jul 2018 16:44:25 -0400 Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fhgiC-0002fX-B9; Mon, 23 Jul 2018 21:41:40 +0200 Received: from [99.0.85.34] (helo=localhost.localdomain) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fhgiC-000Waq-11; Mon, 23 Jul 2018 21:41:40 +0200 Subject: Re: bisected: 4.18-rc* regression: x86-32 troubles (with timers?) To: Arnd Bergmann , Meelis Roos Cc: Linux Kernel list , Networking References: From: Daniel Borkmann Message-ID: <32227088-7754-c160-8046-e860f42ca91c@iogearbox.net> Date: Mon, 23 Jul 2018 21:41:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.100.0/24776/Mon Jul 23 18:44:17 2018) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Meelis, Arnd, On 07/23/2018 06:03 PM, Arnd Bergmann wrote: > On Sat, Jul 21, 2018 at 1:01 AM, Meelis Roos wrote: >> Added netdev and Daniel Borkmann - please see >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1724795.html >> for the original report. It seems to be about BPF instead. >> >> Meanwhile I have found more machines with the trouble. Still no clear >> mark in the config - some x86-32 machines that have >> CONFIG_BPF=y >> CONFIG_BPF_SYSCALL=y >> CONFIG_BPF_JIT_ALWAYS_ON=y >> are working fine. >> >>> The new bisect seems to have also led me to a strange commit. This time >>> I tried to be careful and tested most on two reboots before classifying >>> as good. >>> >>> However, f4e3ec0d573e was suspicious - it failed to autoload e1000 but >>> had no other errors. On both boots with this kernel, modprobe e1000 and >>> ifup -a made the system work so I assumed it was good, while it might >>> not have been. Will try bisecting with f4e3ec0d573e marked bad. >> >> Now this seems more relevant: >> >> mroos@rx100s2:~/linux$ nice git bisect good >> 24dea04767e6e5175f4750770281b0c17ac6a2fb is the first bad commit >> commit 24dea04767e6e5175f4750770281b0c17ac6a2fb >> Author: Daniel Borkmann >> 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. Thanks, Daniel