Re: [RFC PATCH 0/1] support ftrace and -ffunction-sections

[Steven Rostedt]

On Tue, 27 Nov 2018 15:27:14 -0500
Joe Lawrence <joe.lawrence@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/
> 
> 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