On Wednesday, 1 August 2018 17:18:18 MSK Russell King - ARM Linux wrote: > On Wed, Aug 01, 2018 at 05:02:54PM +0300, Dmitry Osipenko wrote: > > On Wednesday, 1 August 2018 16:22:33 MSK Russell King - ARM Linux wrote: > > > On Wed, Aug 01, 2018 at 03:00:22PM +0300, Dmitry Osipenko wrote: > > > > Hello Abbott, > > > > > > > > I gave a quick whirl to your KASAN patches on top of current > > > > linux-next on > > > > NVIDIA Tegra20 and here are couple notes: > > > > > > > > 1) Kernel is booting fine. > > > > > > > > 2) Loading test_kasan.ko makes KASAN to trap faulty memory accesses. > > > > > > > > 3) Running Tegra GPU 2D/3D tests works without any issue. > > > > > > > > 4) I wanted to try Tegra's video decoder driver under KASAN, but > > > > unfortunately Xorg server and video player processes are getting stuck > > > > consuming 100% CPU and processes are not KILL'able. > > > > > > > > I've tried to disable Opentegra Xorg driver and result is the same, > > > > you > > > > should be able to reproduce the issue by just running some desktop > > > > environment. > > > > > > > > 5) There is a splat during kernels boot-up if CONFIG_FTRACE=y and > > > > CONFIG_THUMB2_KERNEL=y. > > > > > > > > ftrace: allocating 40389 entries in 79 pages > > > > ------------[ cut here ]------------ > > > > WARNING: CPU: 0 PID: 0 at arch/arm/kernel/insn.c:15 > > > > __arm_gen_branch+0x7f/0x84 > > > > > > That basically means the branch is out of range for the instruction. > > > It seems to suggest this is a Thumb2 kernel, and relative offset of > > > the function to the mcount function is beyond the Thumb2 branch-link > > > instruction range. (See ftrace_code_disable() in > > > kernel/trace/ftrace.c). > > > > > > This unfortunately provokes two warnings - one from the instruction > > > > > > generation code, and one from the ftrace code: > > > > WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2059 > > > > ftrace_bug+0x1d7/0x28c > > > > > > > > > > > > Initializing ftrace call sites > > > > ftrace record flags: 0 > > > > > > > > (0) > > > > > > > > expected tramp: c010f7dd > > > > > > This may not be the affected function - it looks like the ftrace > > > code bails out on the first ftrace_code_disable() that fails... > > > > > > Which ever function it is, the compiler would have had to create > > > code that would allow it to get to the mcount function, so it > > > suggests that the ftrace code doesn't know about some compiler > > > trick... > > > > Also.. kernel module may fail to load (even with CONFIG_THUMB2_KERNEL=n): > > test_kasan: section 4 reloc 357 sym 'arm_copy_from_user': relocation 28 > > > > out of range (0xbf004f20 -> 0xc106e0c0) > > > > Disabling CONFIG_FTRACE=n helped, but that module loading worked once with > > enabled ftrace and a slightly different kernel config. I think it is not > > due to enabled KASAN because I've experienced such (or similar) module > > load failures a lot with a thumb2 kernel in general. That should be some > > generic trouble with the ARM kernel. Russell, do you have a clue why a > > such module- load failure happens? > > It's all down to whether the kernel is way too large for the ARM/Thumb2 > branch instructions to reach their destinations. We do have a config > option (ARM_MODULE_PLTS) which allows modules to work with big > monolithic kernels, and that is now enabled by default (unless you're > using an old config where it's already disabled.) > > There's no single combination of module options that invokes this > problem - people have tried in the past to say "if you enable X, the > kernel becomes too big, so we need to force ARM_MODULE_PLTS=y if X > is enabled" which is _really_ broken thinking. The problem is never > _just_ that X is enabled, it's always X + lots of other stuff. It > just happens that for "lots of other stuff", enabling "X" tips it > over the balance for _that_ particular set of "other stuff". > > As the kernel progresses, it's not going to get smaller - the kernel > has been growing consistently for any one particular configuration > for years, and as it does, the problem of branch reachability is > only going to get worse. Hence why ARM_MODULE_PLTS now defaults > to being enabled to prevent these issues in the future. Thank you very much for the clarification. I've recognized that it is a branch reachability problem, but I've missed that there is a cure for that in a form of CONFIG_ARM_MODULE_PLTS. That config option is enabled now, thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
