Re: [PATCH v2 1/3] powerpc/code-patching: Add generic memory patching
From: Benjamin Gray <hidden>
Date: 2024-02-05 02:32:05
On Thu, 2023-11-30 at 15:55 +0530, Naveen N Rao wrote:
On Mon, Oct 16, 2023 at 04:01:45PM +1100, Benjamin Gray wrote:quoted
patch_instruction() is designed for patching instructions in otherwise readonly memory. Other consumers also sometimes need to patch readonly memory, so have abused patch_instruction() for arbitrary data patches. This is a problem on ppc64 as patch_instruction() decides on the patch width using the 'instruction' opcode to see if it's a prefixed instruction. Data that triggers this can lead to larger writes, possibly crossing a page boundary and failing the write altogether. Introduce patch_uint(), and patch_ulong(), with aliases patch_u32(), and patch_u64() (on ppc64) designed for aligned data patches. The patch size is now determined by the called function, and is passed as an additional parameter to generic internals. While the instruction flushing is not required for data patches, the use cases for data patching (mainly module loading and static calls) are less performance sensitive than for instruction patching (ftrace activation).That's debatable. While it is nice to be able to activate function tracing quickly, it is not necessarily a hot path. On the flip side, I do have a use case for data patching for ftrace activation :)
True, but it's still correct to do so at least. Having a different path for data writes is definitely a possibility, but would be added for performance. This series is motivated by fixing a correctness issue with data write sizes.
quoted
So the instruction flushing remains unconditional in this patch. ppc32 does not support prefixed instructions, so is unaffected by the original issue. Care is taken in not exposing the size parameter in the public (non-static) interface, so the compiler can const-propagate it away. Signed-off-by: Benjamin Gray <redacted> --- v2: * Deduplicate patch_32() definition * Use u32 for val32 * Remove noinline --- arch/powerpc/include/asm/code-patching.h | 33 ++++++++++++ arch/powerpc/lib/code-patching.c | 66 ++++++++++++++++++-- ---- 2 files changed, 83 insertions(+), 16 deletions(-)diff --git a/arch/powerpc/include/asm/code-patching.hb/arch/powerpc/include/asm/code-patching.h index 3f881548fb61..7c6056bb1706 100644--- a/arch/powerpc/include/asm/code-patching.h +++ b/arch/powerpc/include/asm/code-patching.h@@ -75,6 +75,39 @@ int patch_branch(u32 *addr, unsigned longtarget, int flags); int patch_instruction(u32 *addr, ppc_inst_t instr); int raw_patch_instruction(u32 *addr, ppc_inst_t instr); +/* + * patch_uint() and patch_ulong() should only be called on addresses where the + * patch does not cross a cacheline, otherwise it may not be flushed properly + * and mixes of new and stale data may be observed. It cannot cross a page + * boundary, as only the target page is mapped as writable.Should we enforce alignment requirements, especially for patch_ulong() on 64-bit powerpc? I am not sure if there are use cases for unaligned 64-bit writes. That should also ensure that the write doesn't cross a cacheline.
Yeah, the current description is more just the technical restrictions, not an endorsement of usage. If the caller isn't working with aligned data, it seems unlikely it would still be cacheline aligned. The caller should break it into 32bit patches if this is the case. By enforce, are you suggesting a WARN_ON in the code too?
quoted
+ * + * patch_instruction() and other instruction patchers automatically satisfy this + * requirement due to instruction alignment requirements. + */ + +#ifdef CONFIG_PPC64 + +int patch_uint(void *addr, unsigned int val); +int patch_ulong(void *addr, unsigned long val); + +#define patch_u64 patch_ulong + +#else + +static inline int patch_uint(u32 *addr, unsigned int val)Is there a reason to use u32 * here?
No, fixed to void* for next series
quoted
+{ + return patch_instruction(addr, ppc_inst(val)); +} + +static inline int patch_ulong(void *addr, unsigned long val) +{ + return patch_instruction(addr, ppc_inst(val)); +} + +#endif + +#define patch_u32 patch_uint + static inline unsigned long patch_site_addr(s32 *site) { return (unsigned long)site + *site;diff --git a/arch/powerpc/lib/code-patching.cb/arch/powerpc/lib/code-patching.c index b00112d7ad46..60289332412f 100644--- a/arch/powerpc/lib/code-patching.c +++ b/arch/powerpc/lib/code-patching.c@@ -20,15 +20,14 @@#include <asm/code-patching.h> #include <asm/inst.h> -static int __patch_instruction(u32 *exec_addr, ppc_inst_t instr, u32 *patch_addr) +static int __patch_memory(void *exec_addr, unsigned long val, void *patch_addr, + bool is_dword) { - if (!ppc_inst_prefixed(instr)) { - u32 val = ppc_inst_val(instr); + if (!IS_ENABLED(CONFIG_PPC64) || likely(!is_dword)) { + u32 val32 = val;Would be good to add a comment indicating the need for this for BE.
Yup, added
- Naveen