Kernel Newbies archive on
 help / color / Atom feed
From: "Valdis Klētnieks" <>
To: Pedro Terra Delboni <>
Subject: Re: how to collect information regarding function calls in run time?
Date: Fri, 17 May 2019 10:09:48 -0400
Message-ID: <21382.1558102188@turing-police> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 1963 bytes --]

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.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

Kernelnewbies mailing list

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 19:25 Pedro Terra Delboni
2019-04-03 20:15 ` Bharath Vedartham
     [not found] ` <>
2019-05-14 13:55   ` Pedro Terra Delboni
2019-05-14 14:05     ` Greg KH
2019-05-14 14:14       ` Pedro Terra Delboni
2019-05-14 17:45     ` Valdis Klētnieks
2019-05-14 19:11       ` Pedro Terra Delboni
2019-05-17 14:09         ` Valdis Klētnieks [this message]
2019-05-17 16:19           ` Pedro Terra Delboni

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21382.1558102188@turing-police \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel Newbies archive on

Archives are clonable:
	git clone --mirror kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ \
	public-inbox-index kernelnewbies

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox