Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp156743ybt; Tue, 30 Jun 2020 17:07:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5XrGtXTfAdsBC1pWWrsJT9rh6/JKdYjoU9KR0t0G19lPL8hxgsmEC8qYkbCwj9G1ESfmP X-Received: by 2002:a17:907:264d:: with SMTP id ar13mr15858954ejc.504.1593562065540; Tue, 30 Jun 2020 17:07:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593562065; cv=none; d=google.com; s=arc-20160816; b=zKRu5y6rcJR6OejgYKnVpZNNKdyCCAGA+2IV9mrZkg6ZB1QtR6DEH89dFMe+ZnBvnV 06jN+H51sFCdC2e3Ak5UCxeSlc9PpCyc8M+agyOCexPfWO6AsVSvdeS4tolTSD0F75Kk 0OXj4PWm+YVRYgK5ENNpZxf5wtI7ZRk+c6Vw9YZ5dfBcRAyXnYkisVs0E844ruwsgwSO haSRg1BTg9AK5LuJ2VgtX+Lqy2modUt0w+sCVMwyzottIQ+Q7EHSAz9trdtXtAyXbt7H G1rlavqYd7LKRxemeSJLDvPj1sEdbA/Ud+EQX9oKNdKxHD4ildndENXhIhnGP0X18H7x 2h2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ljeanCVomM9pm7YqGsm40u2yOhEfwYZjVfL5sMIeFvE=; b=vc8tmawjc72hg5EyogYyp//Qu8DCsO5fYy4LPmK0UFfCBdKORiEic5V780NaGmV2E4 XZbNHfI8CMUwTh2ajLnlmaQ7C5F7jNogj6joo4Ml2Tma7ErsUsRra0Za+zSHBjBo3hvw W7lC8lv/h4vktHtoCawANsVONUdux7YgtyoT4Wjv8/q6wmFYG9RCifc+XnChyw96c2cz GPws0Oo1oBsWzyIUgIOSJtUoRG2Jn7lKNo9AlaWPISFdjwZnku7lmlBPZbP0Amzjl+Nw 5SIt9VL3zQeeLAqUNZZ+16zCetmDURhIEW1GcvOX9ppnr3no8PQSdN/HbK7Blen4kZQ9 /Zrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=oIi2JFEv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d21si2779952ejt.197.2020.06.30.17.07.06; Tue, 30 Jun 2020 17:07:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=oIi2JFEv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726152AbgGAAG4 (ORCPT + 99 others); Tue, 30 Jun 2020 20:06:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725872AbgGAAG4 (ORCPT ); Tue, 30 Jun 2020 20:06:56 -0400 Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA543C03E979 for ; Tue, 30 Jun 2020 17:06:55 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id o15so12277669vsp.12 for ; Tue, 30 Jun 2020 17:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ljeanCVomM9pm7YqGsm40u2yOhEfwYZjVfL5sMIeFvE=; b=oIi2JFEv5Rzvgj01VOi5im5BDpG8PBOTCR2Gw/jkmGUZ56w9OrfB3MYqilO6LH+HiZ Ou+iBDqd+74Fl6JYiVdYj6rV7qyR/n915XQ347lsXgEzS4pUKmAv+OfxvXRfj/LT3TF3 LwIZ9VJhGFcPgKdG1BgMRIxMKKb06K6GGJjD7MHwML0XQJtVI3Hl2+RcdgGk9kurlx7K 5MOgJOMav82M89YEaW7Q6XwOAY0uIdZWuTjcxn48Qj/rCAkvP6kT6PqXkPQS22NXM9QD nnlNuJx67KyNukV7ztxVjj8VLzxPjetLaUKP+l8Vx4Aevz1XCpFO/EBxgexS679k/Bjt ll2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ljeanCVomM9pm7YqGsm40u2yOhEfwYZjVfL5sMIeFvE=; b=bqKc46s+Qbt5lcKf/qRFEi1Dp5ObDRZpoZXF0I3P/nNX4ACj58HsAxfC3sFBipcwh1 T4T5rkqjcUUauNuFIcripG7ySd3dRF883PX8RKFojotbJ73qCQXPlzxlWpyEaPkiwjJR j2uwfrwZs/eEJrL5Ey5TazkjhLjVsbiELVET4zq1+qL/hoLzl8KG3cv2dSe/kBi7Vzxg e1KEiENKDU5IkLc4z1YnjY0PCPM636cAjf8OdHW6KmKxnKItAWEVfsnUkrpFlByp18MX HiDpitBNGoiXMo6FuVDMJDswDqycLaRkuJCW94NtfsQn0viRnLcpZlZgniamROm0vF49 UhFA== X-Gm-Message-State: AOAM5300zuInL8e6almbpzEkdOa+LKTrNdKcUHUZx5GI3IrARvKuQXqy wAB7yzCGbdSJdCFJ/Xeddj1bzWGZyikxlDSPDHZs X-Received: by 2002:a67:f04:: with SMTP id 4mr17254670vsp.112.1593562014487; Tue, 30 Jun 2020 17:06:54 -0700 (PDT) MIME-Version: 1.0 References: <20200630184922.455439-1-haoluo@google.com> <49df8306-ecc7-b979-d887-b023275e4842@fb.com> In-Reply-To: From: Bill Wendling Date: Tue, 30 Jun 2020 17:06:43 -0700 Message-ID: Subject: Re: [PATCH bpf-next] selftests/bpf: Switch test_vmlinux to use hrtimer_range_start_ns. To: Hao Luo Cc: Yonghong Song , Networking , bpf , LKML , clang-built-linux , linux-kselftest@vger.kernel.org, Stanislav Fomichev , Shuah Khan , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 30, 2020 at 3:48 PM Hao Luo wrote: > > On Tue, Jun 30, 2020 at 1:37 PM Yonghong Song wrote: > > > > On 6/30/20 11:49 AM, Hao Luo wrote: > > > The test_vmlinux test uses hrtimer_nanosleep as hook to test tracing > > > programs. But it seems Clang may have done an aggressive optimization, > > > causing fentry and kprobe to not hook on this function properly on a > > > Clang build kernel. > > > > Could you explain why it does not on clang built kernel? How did you > > build the kernel? Did you use [thin]lto? > > > > hrtimer_nanosleep is a global function who is called in several > > different files. I am curious how clang optimization can make > > function disappear, or make its function signature change, or > > rename the function? > > > > Yonghong, > > We didn't enable LTO. It also puzzled me. But I can confirm those > fentry/kprobe test failures via many different experiments I've done. > After talking to my colleague on kernel compiling tools (Bill, cc'ed), > we suspected this could be because of clang's aggressive inlining. We > also noticed that all the callsites of hrtimer_nanosleep() are tail > calls. > > For a better explanation, I can reach out to the people who are more > familiar to clang in the compiler team to see if they have any > insights. This may not be of high priority for them though. > Hi Yonghong, Clang is generally more aggressive at inlining than gcc. So even though hrtimer_nanosleep is a global function, clang goes ahead and inlines it into the "nanosleep" syscall, which is in the same file. (We're not currently using {Thin}LTO, so this won't happen in functions outside of kernel/time/hrtimer.c.) Note that if gcc were to change it's inlining heuristics so that it inlined more aggressively, you would be faced with a similar issue. If you would like to test that it calls hrtimer_nanosleep() and not another function, it might be best to call a syscall not defined in hrtimer.c, e.g. clock_nanosleep(). -bw