• Mark Rutland's avatar
    arm64: module/ftrace: intialize PLT at load time · f1a54ae9
    Mark Rutland authored
    Currently we lazily-initialize a module's ftrace PLT at runtime when we
    install the first ftrace call. To do so we have to apply a number of
    sanity checks, transiently mark the module text as RW, and perform an
    IPI as part of handling Neoverse-N1 erratum #1542419.
    
    We only expect the ftrace trampoline to point at ftrace_caller() (AKA
    FTRACE_ADDR), so let's simplify all of this by intializing the PLT at
    module load time, before the module loader marks the module RO and
    performs the intial I-cache maintenance for the module.
    
    Thus we can rely on the module having been correctly intialized, and can
    simplify the runtime work necessary to install an ftrace call in a
    module. This will also allow for the removal of module_disable_ro().
    
    Tested by forcing ftrace_make_call() to use the module PLT, and then
    loading up a module after setting up ftrace with:
    
    | echo ":mod:<module-name>" > set_ftrace_filter;
    | echo function > current_tracer;
    | modprobe <module-name>
    
    Since FTRACE_ADDR is only defined when CONFIG_DYNAMIC_FTRACE is
    selected, we wrap its use along with most of module_init_ftrace_plt()
    with ifdeffery rather than using IS_ENABLED().
    Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
    Reviewed-by: default avatarAmit Daniel Kachhap <amit.kachhap@arm.com>
    Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: default avatarTorsten Duwe <duwe@suse.de>
    Tested-by: default avatarAmit Daniel Kachhap <amit.kachhap@arm.com>
    Tested-by: default avatarTorsten Duwe <duwe@suse.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    f1a54ae9
module.c 13.6 KB