Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp159973ybt; Tue, 30 Jun 2020 17:12:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGtmarqfePRhyuA3P89T0Vk3BxcYAoWaOaV93Mhw33m8K62peQIlroiLkAp3fs3xB30zys X-Received: by 2002:a50:ee8a:: with SMTP id f10mr6363824edr.383.1593562365143; Tue, 30 Jun 2020 17:12:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593562365; cv=none; d=google.com; s=arc-20160816; b=0Z6kEjXETHa84+1uHWi2XSzcC5zfqMC0BIeUkWYfhLyJhfK+9ny630c2ulNkV5nfnW ISf1TcFwB1H7b8n2CasufidAgMtqZSQq2f5fmnuxFvFRv/r6BDbQyn2/GAhtbcTtFwsp 7XRSIfSXCGCkhugm4iwsiQxxF1PIY3c7P1JepdpD+kMvzLR5981cCtChudzrwVzxVWca uv4KSkv0DqzEN+WAteQbgwCFu2GfJeAZm6EKhJv7N27ReYrGJgwW/u13jlhnjXxgAPj/ oPDJFRPTZJ4kweImzg4cB/1mimoxVTNfFbabcrg6N/xbbiIEfvDO0HP8G2/U+WP+2IrQ CkRA== 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=bjQDKTaJMxV8x+iQcgy2rKRLrj+SFItZBE5zPQLkZuA=; b=OFTVshbMhzpUHzkAOUKvRNO2rMBB6g5XhZLwMU2MnMh4iR/+GPYjUuDKw0jxTytBGy pj60E8WsnE+ciImvNRrNZTZQOaRtjgeHkuTAHvTF9D6zkNIYOaR6s+Zj12ou2Lv8DdyY iIWNALySCHxy279BJ/Z1psPvYNsijcYzZHjbv+OCN4ykB3SV8sTUw3PESDEKALu61RLG if+TxGa5Z1dX6pPcEbIfDxqYJiJx6TdOAKAP4QdnPqLcl+p2+OYU0/SKdqAX3iMBxUby vkJkA2OOmJpfwKqFtJUNOOhk7rJzWmKH/705uzi107YpFxuQsoGsVd7KLDBQ7aaVY/PP Njlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TCnqJK+t; 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 j3si2753207edt.8.2020.06.30.17.12.22; Tue, 30 Jun 2020 17:12: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=TCnqJK+t; 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 S1726336AbgGAAK4 (ORCPT + 99 others); Tue, 30 Jun 2020 20:10:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725872AbgGAAKz (ORCPT ); Tue, 30 Jun 2020 20:10:55 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 671B8C03E97B for ; Tue, 30 Jun 2020 17:10:55 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id a8so16764089edy.1 for ; Tue, 30 Jun 2020 17:10: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=bjQDKTaJMxV8x+iQcgy2rKRLrj+SFItZBE5zPQLkZuA=; b=TCnqJK+trIrn/5gbFdl+LRcqR+V+NQ/I4JtzRoERVHVmT1c3XM3fR70h/kayP3sFZd fa5ACr8LbCR/9DpeNYu+hkr9RA8S8Tjtq1J1lOOHnTi1bXP1rfmCXlzos4PP6J9A1ozf oFMhOpKsksoFWZM0mJ4FGfSVcOH/XItOcs51LPsNnQ8Hm87LNTnCchAer6u2v1MskKsz e795FdyNugjhuXHGt/d1jHHCdSsWjH9sSq8r5kP7nEKtvp3lwfEGnSiPzvQVIjLNZdQh Klw7NSpPUdpyZtat3VERb/p/3Nnox2iMmJ1jdbJXIvbQvlZQfY2SSLBgJACiN/UxHUAF LHQg== 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=bjQDKTaJMxV8x+iQcgy2rKRLrj+SFItZBE5zPQLkZuA=; b=jZH0etq38lQVzDdhPOgiUiSQRppfqY3XU6aIQgJ9k1NbKI1zdogAVOTOZzLq//4IrX cajZhJ7bOK2M/zcJDLnsOF4YB8HFYHUUwlteAuIEc0AicKqKQwjM21OtF9HVJIBuOOqw 6skmopkJu/LfQz3L2nkbhCRtyKKiLKn9tWIIl93RKGybaoYCZ2gfbGP2+qvv2AQbZ82R xo9aJTbHTpVAOykmEiN4c+UA2zahWhlB70WQ9qATEG23IVgmoHCmSA0xXmtb0RyNusrT mLSKs8xQrDjbinAtVplqRyUAAGuykpmcFTnyqBKIRVNJHVB1/GS8ViSkzzB+pfvuB52a b4Ow== X-Gm-Message-State: AOAM532yczw96HNWS8TWfGFdz8He99ujGX994+KDBEwWp/2XJQ2va2Z9 ECD7fIdOs8PE3vn3QBoRSxPQ9likQK/Ld+EIFXNJzg== X-Received: by 2002:aa7:cdca:: with SMTP id h10mr12506937edw.285.1593562253769; Tue, 30 Jun 2020 17:10:53 -0700 (PDT) MIME-Version: 1.0 References: <20200630184922.455439-1-haoluo@google.com> <49df8306-ecc7-b979-d887-b023275e4842@fb.com> In-Reply-To: From: Hao Luo Date: Tue, 30 Jun 2020 17:10:42 -0700 Message-ID: Subject: Re: [PATCH bpf-next] selftests/bpf: Switch test_vmlinux to use hrtimer_range_start_ns. To: Yonghong Song Cc: Networking , bpf , linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, linux-kselftest@vger.kernel.org, Stanislav Fomichev , Shuah Khan , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , Bill Wendling 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 Ok, with the help of my colleague Ian Rogers, I think we solved the mystery. Clang actually inlined hrtimer_nanosleep() inside SyS_nanosleep(), so there is no call to that function throughout the path of the nanosleep syscall. I've been looking at the function body of hrtimer_nanosleep for quite some time, but clearly overlooked the caller of hrtimer_nanosleep. hrtimer_nanosleep is pretty short and there are many constants, inlining would not be too surprising. Sigh... Hao 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. > > Hao