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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,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 E48F8C04AB4 for ; Fri, 17 May 2019 14:10:29 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9F8BB216FD for ; Fri, 17 May 2019 14:10:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F8BB216FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1hRdYe-0002Xl-Lq; Fri, 17 May 2019 10:10:00 -0400 Received: from omr1.cc.ipv6.vt.edu ([2607:b400:92:8300:0:c6:2117:b0e] helo=omr1.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hRdYc-0002Xf-Rt for kernelnewbies@kernelnewbies.org; Fri, 17 May 2019 10:09:58 -0400 Received: from mr6.cc.vt.edu (mr6.cc.vt.edu [IPv6:2607:b400:92:8500:0:af:2d00:4488]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x4HE9u8p024070 for ; Fri, 17 May 2019 10:09:57 -0400 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mr6.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x4HE9pGM009350 for ; Fri, 17 May 2019 10:09:56 -0400 Received: by mail-qk1-f197.google.com with SMTP id h16so5791224qke.11 for ; Fri, 17 May 2019 07:09:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=CemUXGRWOQ1rQAKzhG9uiirzrz+ZsZR6lwnApCVF+ZI=; b=kd5tVnOiNsNO+oFd0BiJgzuqqdInqIc5WK6qjd0gfKVFc484YbapF4S1mptUQIucE1 SZmZwpZ0kI7wYkv5AjuC4vJrx/0DcZbJnMaMn1Or5WzBKwau8yvC4wBgkyAr4827dgzQ 6opY9UoZsYfDjrNrDj7yYdGaJwm1FVrYRn6lXOaiq9Fw4m64gFpvkZjcG6K+r72UqXlP IEOPVCo5gZ/PCntXyfo5JMn9trwK2Fqsy2wR5pgVVgSnWMm5vMPO8vg1YZpH+FJ+4S50 mOUCD17f7ZyesjHDpDj9+C062LlLsQIyvRaFSfcXTB9/B5SYAFcDG4jglHNvhqCTjxas DwTA== X-Gm-Message-State: APjAAAVykCQPZ9BYDpKCfkjucwH2+znWCM9LOwznR7AizHURxjGolFI6 Fdws1c6wWCs3Jz8a0vnlfySsy06Q/AucBsE/gso/Fsdc8eu6qHmlKqirm2nHG6GCcGjoY7nwScw tW/8g83wJ+Of/AM6fUc5sjCBQEDiCr967B08j4hk= X-Received: by 2002:ae9:e918:: with SMTP id x24mr18721057qkf.209.1558102191531; Fri, 17 May 2019 07:09:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqyTvQILP2M+e4ooEsgVDshiHLN1XkiU44sK7P9IXpUrJgtkHFD4Gy4uWTPuT64bBZ3MaDPE0Q== X-Received: by 2002:ae9:e918:: with SMTP id x24mr18721032qkf.209.1558102191303; Fri, 17 May 2019 07:09:51 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:4341:5952:f06b:5958:9b7c]) by smtp.gmail.com with ESMTPSA id n22sm5246711qtb.56.2019.05.17.07.09.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 May 2019 07:09:49 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: Pedro Terra Delboni Subject: Re: how to collect information regarding function calls in run time? In-Reply-To: References: <2216.1557855958@turing-police> Mime-Version: 1.0 Date: Fri, 17 May 2019 10:09:48 -0400 Message-ID: <21382.1558102188@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7087998483531200921==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============7087998483531200921== Content-Type: multipart/signed; boundary="==_Exmh_1558102188_1872P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1558102188_1872P Content-Type: text/plain; charset=us-ascii On Tue, 14 May 2019 16:11:51 -0300, Pedro Terra Delboni said: > I agree that the question alone seems like a weird one, I just assumed > when I wrote my first email that the explaining the motivation would > only consume time of the reader. Asking "what problem are you trying to solve" is a standard question, because whenever a programmer is saying "I can't get X to do Y", a good 85% of the time it turns out that isn't working because using W to do Z is the already-existing API for what they actually wanted to do.... > The subject I'm working on is Control-Flow Integrity, which instrument > a code so that each indirect jump (which are usually returns or > indirect calls) verify if the address they are returning is a valid > one (so there is a code stub that runs in every function call and > return). > The reason I want to count call instructions execution is because the > function return tied to the most executed call instruction will be the > one that will cause the greater increase in execution time, so by > inlining that call we'll be exchanging this cost for the cache impact > of the code expansion (as the code stub won't exist anymore for this > call). I suspect that the vast majority of functions that are *that* heavily used are either (a) already inlined or (b) too large to inline - for instance, kmalloc is used heavily, but having separate inlined copies everyplace to avoid the return statement is going to bloat the code - and even worse, make almost all the inline copies cache-cold instead of one shared cache-hot chunk of 2K. And the question we *should* be asking is *not* "is the return address a plausible one". It's "is the return address *the one we were called from*". Checking whether kmalloc is about to return to a valid call point doesn't tell you much. Finding out that kmalloc is about to return to one of the 193,358 *other* call points rather than the one it was actually called from is something big. --==_Exmh_1558102188_1872P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXN7AqwdmEQWDXROgAQL+Bw/9GlKOmbRIdv7rskqOz7idE9YXTBs9MgkE ikmZwiplEttFXzEBqFYhqEAdsSzdBMnTjK9VhjuI4Pk5kOrYES38gEQ31PFMjJtY AePv7fVTbt41HhZ5vOjI1zkOu7+I/2hyjHVsI7mK2mQAwZaNwSZoc4ZABq1l5guf UCeDP1yKTKy1H1v7J8XATT+wTxkidnFJMfBCGt/qtXuKp84Sx+KsbXDTi9I/CNcp z1pMIyoEEBCRLn2LUtoejgmsKIk/D34o92yKJcoSHEqnJ0G0wmFqb1Zvm0t1xr52 VuDz0fExnENvu59bHElWnkKZaLngGCQH9xJ0P2DRU04VqcETfb7jb1IKQcwI0eBM xuauBRqtrsv0iBFvUnmnN5uU9i7YXwl+HqOH/xx5V/cgTvjYWZMxwEO857O0gyjX uq5zJzQeNUfvO2UdLv/nzrs6/8QDTJKU++gGoFFEfxfxML5QgY9YO4KlQjrZZmea SHHAl59WD7ExbcqNQACrEb6almEF2R5evMJGDX3k/F6+btyxoUNB3S/6ow4SO7Xs fYEhDXR22Cbedn/xPgFNpUM9vWEhJEPUM6gtU7BjaOEWII/KwWxuU6vIA0eYJJym wXM+nlTEuLbl6zIdoN72uldz2J2jHjGb8QikKjsQbSWuPCWAPwDQqDqzuSTk+vkR Pgfb0I2S2GA= =V76z -----END PGP SIGNATURE----- --==_Exmh_1558102188_1872P-- --===============7087998483531200921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============7087998483531200921==--