Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1521592pxb; Sun, 7 Mar 2021 22:41:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwZ9+wsAhxJlgNPAqDqV26xDX/kkqGBBJZSHBK88q0WUm2fktCUHgN4Lo6ZQ6Pp8GXeUQCL X-Received: by 2002:a17:907:216a:: with SMTP id rl10mr13626560ejb.365.1615185694703; Sun, 07 Mar 2021 22:41:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615185694; cv=none; d=google.com; s=arc-20160816; b=QA3XFn0afLTjCZu1TyCf9fIfLoNYHoq+AYWU0iCieTzSjrETt+qKfZ3qIipk3/aExi aSvWo2jZGVNK8ylRPyqUa9pO+3hMqSsOz+SB75smQqYU3PY2qtclVegYzyNaRjUU/L72 4mrHG7mP+a2dSat9qAuYVV+zs83SSl5SEwvhjpMhZHBi1ykaU3hdAiElctNflcwp6h69 EY1zwwTvO0VfNL4Hg5pPn15+qlGU7xNzuh0CTDNQ/+d27/gCS9XKOsEebRK9zQlAHTP1 iUjNhvdCXyw7FmCn0QqhccjjG+za+D6aahjjw7rFD/yKDpNz10u6d7LasV56qZmdxplP NCdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=L0tyXK7K5aU/7ShBJSMF3+Nj/FvHo/5L4AqetC4jXBA=; b=h82rL9Zht6eriL9Xr+lJNHX5QtgkZwOLhxiQgWufTPV7tlFTNyn8qdXbYtMpwje5mL jPJxTOissjBQg4MyxDXpFdlik6IeIL0rr7NuusKX7902mWBo3er3e2C4rBHZJ/gUz+Ad FpvqmvD6mOPhiF7wj00BeJsKgK/9PVTAEK+BQvYTIrxNqZpDtCqid4RCYTCJsUYhhmE8 qCn9L4wgiVlc0IHiJT1qIIkVyAr2yPVU4gMf28sD/chIfAjD9qtZV7D/eqnM9BgoJAtp 0q206t5lW9wdtpzCjvGQHl07CBV1nVrT4N6g7vINilC5L4oCAylGbFeuQZnZETaTvWzd s24A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y2si5828501eje.495.2021.03.07.22.41.12; Sun, 07 Mar 2021 22:41:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229591AbhCGR0z (ORCPT + 99 others); Sun, 7 Mar 2021 12:26:55 -0500 Received: from foss.arm.com ([217.140.110.172]:54282 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229711AbhCGR0y (ORCPT ); Sun, 7 Mar 2021 12:26:54 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D8D8431B; Sun, 7 Mar 2021 09:26:53 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BC6363F73C; Sun, 7 Mar 2021 09:26:52 -0800 (PST) Date: Sun, 7 Mar 2021 17:26:50 +0000 From: Qais Yousef To: Alexander A Sverdlin Cc: Steven Rostedt , Ingo Molnar , Russell King , linux-arm-kernel@lists.infradead.org, Florian Fainelli , linux-kernel@vger.kernel.org, Ard Biesheuvel Subject: Re: [PATCH v7 2/2] ARM: ftrace: Add MODULE_PLTS support Message-ID: <20210307172650.uztx3sk5abybbp3f@e107158-lin.cambridge.arm.com> References: <20210127110944.41813-1-alexander.sverdlin@nokia.com> <20210127110944.41813-3-alexander.sverdlin@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210127110944.41813-3-alexander.sverdlin@nokia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexander Sorry if I'm butting in out of the blue. I got curious so decided to have a go at reproducing the issue :-) On 01/27/21 12:09, Alexander A Sverdlin wrote: > From: Alexander Sverdlin > > Teach ftrace_make_call() and ftrace_make_nop() about PLTs. > Teach PLT code about FTRACE and all its callbacks. > Otherwise the following might happen: > > ------------[ cut here ]------------ > WARNING: CPU: 14 PID: 2265 at .../arch/arm/kernel/insn.c:14 __arm_gen_branch+0x83/0x8c() > ... > Hardware name: LSI Axxia AXM55XX > [] (unwind_backtrace) from [] (show_stack+0x11/0x14) > [] (show_stack) from [] (dump_stack+0x81/0xa8) > [] (dump_stack) from [] (warn_slowpath_common+0x69/0x90) > [] (warn_slowpath_common) from [] (warn_slowpath_null+0x17/0x1c) > [] (warn_slowpath_null) from [] (__arm_gen_branch+0x83/0x8c) > [] (__arm_gen_branch) from [] (ftrace_make_nop+0xf/0x24) > [] (ftrace_make_nop) from [] (ftrace_process_locs+0x27b/0x3e8) > [] (ftrace_process_locs) from [] (load_module+0x11e9/0x1a44) > [] (load_module) from [] (SyS_finit_module+0x59/0x84) > [] (SyS_finit_module) from [] (ret_fast_syscall+0x1/0x18) > ---[ end trace e1b64ced7a89adcc ]--- > ------------[ cut here ]------------ > WARNING: CPU: 14 PID: 2265 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1b1/0x234() > ... > Hardware name: LSI Axxia AXM55XX > [] (unwind_backtrace) from [] (show_stack+0x11/0x14) > [] (show_stack) from [] (dump_stack+0x81/0xa8) > [] (dump_stack) from [] (warn_slowpath_common+0x69/0x90) > [] (warn_slowpath_common) from [] (warn_slowpath_null+0x17/0x1c) > [] (warn_slowpath_null) from [] (ftrace_bug+0x1b1/0x234) > [] (ftrace_bug) from [] (ftrace_process_locs+0x285/0x3e8) > [] (ftrace_process_locs) from [] (load_module+0x11e9/0x1a44) > [] (load_module) from [] (SyS_finit_module+0x59/0x84) > [] (SyS_finit_module) from [] (ret_fast_syscall+0x1/0x18) > ---[ end trace e1b64ced7a89adcd ]--- > ftrace failed to modify [] 0xe9ef7006 > actual: 02:f0:3b:fa > ftrace record flags: 0 > (0) expected tramp: c0314265 > > Signed-off-by: Alexander Sverdlin I tried on 5.12-rc2 and 5.11 but couldn't reproduce the problem using your instructions on the other email. But most likely because I'm hitting another problem that could be masking it. I'm not sure it is related or just randomly happened to hit it. Did you see something similar? [ 0.000000] ftrace: allocating 82941 entries in 244 pages [ 0.000000] ------------[ ftrace bug ]------------ [ 0.000000] ftrace failed to modify [ 0.000000] [] set_reset_devices+0x10/0x28 [ 0.000000] actual: 0e:28:03:eb [ 0.000000] Initializing ftrace call sites [ 0.000000] ftrace record flags: 0 [ 0.000000] (0) [ 0.000000] expected tramp: c0312eb8 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2066 ftrace_bug+0x240/0x268 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.12.0-rc2-00002-gcb8fe87aa3fa-dirty #12 [ 0.000000] Hardware name: Generic DT based system [ 0.000000] Backtrace: [ 0.000000] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 0.000000] r7:c2e13c1c r6:600000d3 r5:00000000 r4:c2e13c1c [ 0.000000] [] (show_stack) from [] (dump_stack+0xf4/0x124) [ 0.000000] [] (dump_stack) from [] (__warn+0xfc/0x128) [ 0.000000] r10:c2d0908c r9:00000000 r8:00000009 r7:00000812 r6:00000009 r5:c1b01c78 [ 0.000000] r4:c27d0f70 r3:c2d08f50 [ 0.000000] [] (__warn) from [] (warn_slowpath_fmt+0x74/0xd0) [ 0.000000] r7:c1b01c78 r6:00000812 r5:c27d0f70 r4:00000000 [ 0.000000] [] (warn_slowpath_fmt) from [] (ftrace_bug+0x240/0x268) [ 0.000000] r8:c0312eac r7:c362f518 r6:ffffffea r5:c2b00350 r4:c3817ac4 [ 0.000000] [] (ftrace_bug) from [] (ftrace_process_locs+0x2b0/0x518) [ 0.000000] r7:c3817ac4 r6:c38040c0 r5:00000a3c r4:000134e4 [ 0.000000] [] (ftrace_process_locs) from [] (ftrace_init+0xc8/0x174) [ 0.000000] r10:c2ffa000 r9:c2be8a78 r8:c2c5d1fc r7:c2c0c208 r6:00000001 r5:c2d0908c [ 0.000000] r4:c362f518 [ 0.000000] [] (ftrace_init) from [] (start_kernel+0x2f4/0x5b8) [ 0.000000] r9:c2be8a78 r8:dbfffec0 r7:00000000 r6:c36385cc r5:c2d08f00 r4:c2ffa000 [ 0.000000] [] (start_kernel) from [<00000000>] (0x0) [ 0.000000] r10:10c5387d r9:412fc0f1 r8:48000000 r7:ffffffff r6:10c0387d r5:00000051 [ 0.000000] r4:c2b00330 [ 0.000000] irq event stamp: 0 [ 0.000000] hardirqs last enabled at (0): [<00000000>] 0x0 [ 0.000000] hardirqs last disabled at (0): [<00000000>] 0x0 [ 0.000000] softirqs last enabled at (0): [<00000000>] 0x0 [ 0.000000] softirqs last disabled at (0): [<00000000>] 0x0 [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0xa0 with crng_init=0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] ftrace: allocated 243 pages with 6 groups > diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c > index 9a79ef6..fa867a5 100644 > --- a/arch/arm/kernel/ftrace.c > +++ b/arch/arm/kernel/ftrace.c > @@ -70,6 +70,19 @@ int ftrace_arch_code_modify_post_process(void) > > static unsigned long ftrace_call_replace(unsigned long pc, unsigned long addr) > { > + s32 offset = addr - pc; > + s32 blim = 0xfe000008; > + s32 flim = 0x02000004; This look like magic numbers to me.. > + > + if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) { > + blim = 0xff000004; > + flim = 0x01000002; .. ditto .. > + } > + > + if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) && > + (offset < blim || offset > flim)) > + return 0; .. I could have missed something, but wouldn't something like below be clearer? Only compile tested. I think abs() will do the right thing here given the passed types. I admit I don't understand why you have the '4' and '8' at the lowest nibble.. diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c index fa867a57100f..b44aee87c53a 100644 --- a/arch/arm/kernel/ftrace.c +++ b/arch/arm/kernel/ftrace.c @@ -70,17 +70,13 @@ int ftrace_arch_code_modify_post_process(void) static unsigned long ftrace_call_replace(unsigned long pc, unsigned long addr) { - s32 offset = addr - pc; - s32 blim = 0xfe000008; - s32 flim = 0x02000004; + u32 offset = abs(addr - pc); + u32 range = 0x02000000; /* +-32MiB */ - if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) { - blim = 0xff000004; - flim = 0x01000002; - } + if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) + range = 0x01000000; /* +-16MiB */ - if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) && - (offset < blim || offset > flim)) + if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) && offset > range) return 0; return arm_gen_branch_link(pc, addr); In case CONFIG_ARM_MODULE_PLTS is not enabled what would happen? Is it impossible to hit this corner case or we could fail one way or another? IOW, should this check be always compiled in? > + > return arm_gen_branch_link(pc, addr); > } > > @@ -124,10 +137,22 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr) > { > unsigned long new, old; > unsigned long ip = rec->ip; > + unsigned long aaddr = adjust_address(rec, addr); > > old = ftrace_nop_replace(rec); > > - new = ftrace_call_replace(ip, adjust_address(rec, addr)); > + new = ftrace_call_replace(ip, aaddr); > + > +#ifdef CONFIG_ARM_MODULE_PLTS > + if (!new) { > + struct module *mod = rec->arch.mod; > + > + if (mod) { What would happen if !new and !mod? > + aaddr = get_module_plt(mod, ip, aaddr); > + new = ftrace_call_replace(ip, aaddr); I assume we're guaranteed to have a sensible value returned in 'new' here? Thanks -- Qais Yousef > + } > + } > +#endif