[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.1910301559340.18400@pobox.suse.cz>
Date: Wed, 30 Oct 2019 16:00:58 +0100 (CET)
From: Miroslav Benes <mbenes@...e.cz>
To: Mark Rutland <mark.rutland@....com>
cc: linux-arm-kernel@...ts.infradead.org,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org, amit.kachhap@....com,
catalin.marinas@....com, deller@....de, duwe@...e.de,
James.Bottomley@...senPartnership.com, james.morse@....com,
jeyu@...nel.org, jpoimboe@...hat.com, jthierry@...hat.com,
linux-parisc@...r.kernel.org, mingo@...hat.com,
peterz@...radead.org, svens@...ckframe.org,
takahiro.akashi@...aro.org, will@...nel.org
Subject: Re: [PATCHv2 1/8] ftrace: add ftrace_init_nop()
On Tue, 29 Oct 2019, Mark Rutland wrote:
> Architectures may need to perform special initialization of ftrace
> callsites, and today they do so by special-casing ftrace_make_nop() when
> the expected branch address is MCOUNT_ADDR. In some cases (e.g. for
> patchable-function-entry), we don't have an mcount-like symbol and don't
> want a synthetic MCOUNT_ADDR, but we may need to perform some
> initialization of callsites.
>
> To make it possible to separate initialization from runtime
> modification, and to handle cases without an mcount-like symbol, this
> patch adds an optional ftrace_init_nop() function that architectures can
> implement, which does not pass a branch address.
>
> Where an architecture does not provide ftrace_init_nop(), we will fall
> back to the existing behaviour of calling ftrace_make_nop() with
> MCOUNT_ADDR.
>
> At the same time, ftrace_code_disable() is renamed to
> ftrace_nop_initialize() to make it clearer that it is intended to
> intialize a callsite into a disabled state, and is not for disabling a
> callsite that has been runtime enabled. The kerneldoc description of rec
> arguments is updated to cover non-mcount callsites.
>
> Signed-off-by: Mark Rutland <mark.rutland@....com>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Torsten Duwe <duwe@...e.de>
Reviewed-by: Miroslav Benes <mbenes@...e.cz>
M
Powered by blists - more mailing lists