Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 27 Nov 2018 21:09:42 -0500
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
Message-ID: <20181127210942.4067ad46@vmware.local.home>
In-Reply-To: <a6c4b12d-389e-8919-d37b-50ba73319b8f@redhat.com>
References: <1542745158-25392-1-git-send-email-joe.lawrence@redhat.com>
        <a6c4b12d-389e-8919-d37b-50ba73319b8f@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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