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. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up -- 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
