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;
Subject: Re: [RFC PATCH 0/1] support ftrace and -ffunction-sections
From:   Joe Lawrence <joe.lawrence@redhat.com>
To:     linux-kernel@vger.kernel.org
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Masahiro Yamada <yamada.masahiro@socionext.com>
References: <1542745158-25392-1-git-send-email-joe.lawrence@redhat.com>
Organization: Red Hat
Message-ID: <a6c4b12d-389e-8919-d37b-50ba73319b8f@redhat.com>
Date:   Tue, 27 Nov 2018 15:27:14 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <1542745158-25392-1-git-send-email-joe.lawrence@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/20/2018 03:19 PM, Joe Lawrence wrote:
> Hi Steve,
> 
> I noticed that ftrace does not currently support functions built with
> the -ffunction-sections option as they end up in .text.<function_name>
> ELF sections, never making into the __mcount_loc section.
> 
> I modified the recordmcount scripts to handle such .text. section
> prefixes and this appears to work on x86_64, ppc64le, and s390x -- at
> least for simple modules, including the "Test trace_printk from module"
> ftrace self-test. 
> 
> That said, I did notice 90ad4052e85c ("kbuild: avoid conflict between
> -ffunction-sections and -pg on gcc-4.7") which indicates that the kernel
> still supports versions of gcc which may not play well with ftrace and
> -ffunction-sections.
> 
> With that limitation in mind, can we support ftracing of functions in
> such sections for compiler versions that do support it? (fwiw, gcc
> v4.8.5 seems happy)  And then if so, what additional testing or coding
> would need to be done to be confident that it is safe?  Is matching on
> ".text.*" too inclusive?
> 

Gentle ping...  I took a dive through the rhkl-archives and found a few
older discussions:

  [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 :(

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.

-- Joe