From: Steven Rostedt <rostedt@goodmis.org>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Masahiro Yamada <yamada.masahiro@socionext.com>
Subject: Re: [RFC PATCH 0/1] support ftrace and -ffunction-sections
Date: Tue, 27 Nov 2018 21:09:42 -0500 [thread overview]
Message-ID: <20181127210942.4067ad46@vmware.local.home> (raw)
In-Reply-To: <a6c4b12d-389e-8919-d37b-50ba73319b8f@redhat.com>
On Tue, 27 Nov 2018 15:27:14 -0500
Joe Lawrence <joe.lawrence@redhat.com> wrote:
> Gentle ping... I took a dive through the rhkl-archives and found a few
> older discussions:
Thanks for the reminder, my INBOX is totally out of control with
Plumbers followed by Turkey Day.
>
> [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.
> https://lore.kernel.org/lkml/CAFbHwiRtBaHkpZqTm6VZ=fCJcyu+dsdpo_kxMHy1egce=rTuyA@mail.gmail.com/
>
> and related LWN article:
>
> The source of the e1000e corruption bug
> https://lwn.net/Articles/304105/
>
> Catching up with those, I assume that this has never been implemented in
> the past due to fear of ftrace modifying a potentially freed section
> (and bricking NICs in the process :(
Actually, we have a lot more safe guards against that today.
>
> Looking through the kernel sources (like Will in 2008) I don't see any
> code jumping out at me that frees code other than .init. However a
> quick code inspection is no guarantee.
>
> Assuming the same use-after-free reservation holds true today:
>
> 1: Is there any reasonable way to mark code sections (pages?) as
> in-use to avoid memory freeing mechanisms from releasing them? The
> logic for .init is mostly arch-specific, so there could be many
> different ways random arches may try to pull this off.
>
> 2: Would/could it be safer to restrict __mcount_loc detection of
> ".text.*" sections to modules? The recordmcount.pl script already
> knows about is_module... that information could be provided to
> recordmcount.c as well for consideration.
I'm fine with just applying your patch. Today, for x86, there's a gcc
option that adds the __mcount_loc automatically without doing any
whitelisting (it doesn't run recordmcount.*). It just adds anything that
is traced, thus it has to work for all possible cases now.
-- Steve
next prev parent reply other threads:[~2018-11-28 2:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 20:19 [RFC PATCH 0/1] support ftrace and -ffunction-sections Joe Lawrence
2018-11-20 20:19 ` [RFC PATCH 1/1] scripts/recordmcount.{c,pl}: support -ffunction-sections .text.* section names Joe Lawrence
2018-11-27 20:27 ` [RFC PATCH 0/1] support ftrace and -ffunction-sections Joe Lawrence
2018-11-28 2:09 ` Steven Rostedt [this message]
2018-11-28 14:59 ` Joe Lawrence
Reply instructions:
You may reply publicly 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181127210942.4067ad46@vmware.local.home \
--to=rostedt@goodmis.org \
--cc=joe.lawrence@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).