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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5E1FC54EE9 for ; Wed, 21 Sep 2022 01:31:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230526AbiIUBba (ORCPT ); Tue, 20 Sep 2022 21:31:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230391AbiIUBb1 (ORCPT ); Tue, 20 Sep 2022 21:31:27 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFE9711178 for ; Tue, 20 Sep 2022 18:31:26 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id go6so4915223pjb.2 for ; Tue, 20 Sep 2022 18:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=vrZbq/hL3g85/CLbfG3JsdHSRD/rOZmQkOZ2dFbbZj8=; b=YqklhaPHAumP+mpxQOMS2PTelXmDSbHwCVTEGId5S3oUI9NHDbl3DkUrpKbtLeeWIA 2WRjwBq6oyFsyn+/5x6Et1CVVbUyKjy6N+R226ZrKm3P/Ns8EZ2LRYk1jY8sreF2KCrj AchXRJWyZ9X06oJC8Vb8eTak93idcRf06/8x4SK0xitQThUCRgUGo791HcIAgLH6vjo0 fG4EiNk502ObStRIHJ93rGf9TT5wqenR5W0pLfVeh3v4Gj7qdfO4a6fJPraLO+U3QXPI /Am0t2yKYt+bj/bFIu3hGl3JRolfa+FypTnrEBImAJ7WGuKI4iWXfHU6JFrKBdXNClJa bQVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=vrZbq/hL3g85/CLbfG3JsdHSRD/rOZmQkOZ2dFbbZj8=; b=sSz/p52WSyTM/O3HCspuy9KxIO4oGuRr5Sl4GoblJ4fEephR/7LCM/OsjMZa7AK//f WKlu6sLFVElSLQSTvHOA4hP5Vhv+5snFzE9WamJ1l2nZqteHdyUkJI5q7zBXmo9IrFHI /4ETFFFGJ4KmMkqFtTEBFKmp9RMapRHPaBFhj/ak09AkImSPcGoPC+EfMG8lUe6xkRuw FtMd7nWl8toVJlpvdSSFGhfvgN+H4Pt27HBd3kK7AJJVt0gv+SJFlYt333ck2NOne6J+ PuJnqTOGegCPcI/qjDhWTB7//rfeM/Z03jJ0Czwdn8pSmTfNnbhOs6KBehViMuhCOp0r PWXQ== X-Gm-Message-State: ACrzQf1sjOgeCA18yYzGvZ6BCQPfzqdfBZk7l1YDvozPnjziTpcgBJ+V LN0LOm6o2SzKP1WfDm3wPrM= X-Google-Smtp-Source: AMsMyM7UX7WEXDteCamL95O73fPuFXTYXrivpQulkszrFaInrAveKAYA0XX4sTgJrGenGvos4OnP1A== X-Received: by 2002:a17:90a:b00b:b0:203:a6de:5b0f with SMTP id x11-20020a17090ab00b00b00203a6de5b0fmr6752757pjq.134.1663723885976; Tue, 20 Sep 2022 18:31:25 -0700 (PDT) Received: from smtpclient.apple ([66.170.99.95]) by smtp.gmail.com with ESMTPSA id y2-20020a17090322c200b00177fb862a87sm603621plg.20.2022.09.20.18.31.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Sep 2022 18:31:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [RFC PATCH] x86/syscalls: allow tracing of __do_sys_[syscall] functions From: Nadav Amit In-Reply-To: Date: Tue, 20 Sep 2022 18:31:24 -0700 Cc: "Steven Rostedt (Google)" , LKML , X86 ML , Dave Hansen , Borislav Petkov , Ingo Molnar , Thomas Gleixner Content-Transfer-Encoding: quoted-printable Message-Id: <72644F1F-7A13-4CC1-8C24-BE271323FE94@gmail.com> References: <20220913135213.720368-1-namit@vmware.com> <2D09BBFE-45F3-4B9C-8734-D002CA99FD94@gmail.com> To: Peter Zijlstra X-Mailer: Apple Mail (2.3696.120.41.1.1) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Just following my questions with the answers I figured out, just to save others time. On Sep 20, 2022, at 9:48 AM, Nadav Amit wrote: > On Sep 20, 2022, at 4:02 AM, Peter Zijlstra = wrote: >=20 >> On Mon, Sep 19, 2022 at 07:35:42PM -0700, Nadav Amit wrote: >>=20 >>> 1. What is the reason that inline functions are marked with notrace? >>=20 >> IIRC the concern is that a notrace function using an inline function; >> GCC deciding to not inline and then still hitting tracing. >>=20 >> For noinstr we've mandated __always_inline to avoid this problem. The >> direct advantage is that those inlined into instrumented code get, = well, >> instrumented. Commit 45959ee7aa645 (=E2=80=9Cftrace: Do not function trace inlined = functions=E2=80=9D) gives two reasons which correspond with what you were saying: (1) consistency and (2) function that should not be traced are mostly marked = as inline. I am not sure I fully agree with the arguments, specifically the = consistency (any function might be inlined and not traceable). But I am too = afraid/lazy to cause damage and fix it. I will remove the inline and play a bit with = the kernel to see how it behaves. >>> 2. Is probing function that is called from do_idle() supposed to = work, or >>> should the kernel prevent it? >>=20 >> Should work for some :-) Specifically it doesn't work for those that >> disable RCU, and that's (largely) being fixed here: >>=20 >> = https://lore.kernel.org/all/20220919095939.761690562@infradead.org/T/#u >>=20 >> Although looking at it just now, I think I missed a spot.. lemme go = fix >> ;-) I did not try your patches, but I do think I figured out what=E2=80=99s = wrong and sent a patch. = https://lore.kernel.org/lkml/EECE6FD7-FC3D-40E2-A957-151A1BE2B2F9@vmware.c= om/T/#t Thanks again, Nadav=