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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 0F3FBC433E0 for ; Wed, 1 Jul 2020 00:06:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DEFA620781 for ; Wed, 1 Jul 2020 00:06:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="oIi2JFEv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726120AbgGAAG4 (ORCPT ); Tue, 30 Jun 2020 20:06:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725947AbgGAAG4 (ORCPT ); Tue, 30 Jun 2020 20:06:56 -0400 Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C21F6C03E97A for ; Tue, 30 Jun 2020 17:06:55 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id q15so1563570vso.9 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=CmN2ve96UR/y0QiEWULUxBZgt1IvjF3d0QzBaP8LRGG4qK6/2oLaA77ylt2n718g+S 4eYATMfmiV82Zn2hk1vqxFZ8twq+AfYu5wy6m7R+caWVxA+FclyGnitzfpoLGTAUiJWe MUrkRzCeeqRPNNez8qR5gSnxbtpZKc480IHyY/7XUq3LO/KXFqgmBIvBB5gy6af5YGdN Pmb/Yn7sD31XZQcmVJld9fYOXuQOdGFwIQrytKAnzd0dHZIt6N4k8eakp49Ek3c/82OW T2NUAF5gbVE7VsJcJaIKMJv7mvm3Gzyi9DJwWtEKFiJ5dXQnZCqNnRFbzUplLZl4lO+O puUA== X-Gm-Message-State: AOAM532L9ZrAqG6Wv7ft+FBnzGhOhh0TqSEXr1MNt4b9OgySx4CVcVZX DDpJuakEWiM9nZpqaMYvJ51yqK8ImHFG402kxJE6 X-Google-Smtp-Source: ABdhPJzAqs6cElenC01gUzsDtsvwsJx2nGOZyUnKLNyoFEReEJBd3v4RZOf8Kpet7WG3DkYwTUeEJgqFnJo+tuGZ3pM= 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-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@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