Prev: [PATCH] Handle instruction cache maintenance fault properly
Next: [OOPS] apbuart.c: Two problems related to grlib_apbuart_configure()
From: Russell King - ARM Linux on 10 May 2010 09:20 On Mon, May 10, 2010 at 04:07:57PM +0300, Kirill A. Shutemov wrote: > Between "clean D line..." and "invalidate I line" operations in > v7_coherent_user_range(), the memory page may get swapped out. > And the fault on "invalidate I line" could not be properly handled > causing the oops. You have to be very careful when doing this kind of change - you need to review the behaviour of previous ARMs to ensure that you don't throw the CPU into an infinite loop when an "external abort on linefetch" occurs. With older CPUs, an "external abort on linefetch" is most probably fatal to the process and can never be recovered. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kirill A. Shutemov on 10 May 2010 09:40 On Mon, May 10, 2010 at 4:15 PM, Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > On Mon, May 10, 2010 at 04:07:57PM +0300, Kirill A. Shutemov wrote: >> Between "clean D line..." and "invalidate I line" operations in >> v7_coherent_user_range(), the memory page may get swapped out. >> And the fault on "invalidate I line" could not be properly handled >> causing the oops. > > You have to be very careful when doing this kind of change - you need to > review the behaviour of previous ARMs to ensure that you don't throw the > CPU into an infinite loop when an "external abort on linefetch" occurs. > > With older CPUs, an "external abort on linefetch" is most probably fatal > to the process and can never be recovered. It looks like cache maintenance fault was introduced in ARMv6. So, what is the right way to fix it? Something like: #if __LINUX_ARM_ARCH__ < 6 { do_bad, SIGBUS, 0, "external abort on linefetch" }, #else { do_translation_fault, SIGSEGV, SEGV_MAPERR, "I-cache maintenance fault" }, #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valdis.Kletnieks on 10 May 2010 11:00 On Mon, 10 May 2010 16:34:57 +0300, "Kirill A. Shutemov" said: > It looks like cache maintenance fault was introduced in ARMv6. > > So, what is the right way to fix it? Something like: > > #if __LINUX_ARM_ARCH__ < 6 > { do_bad, SIGBUS, 0, "external This would need to be a runtime test, no? Or does LINUX_ARM_ARCH not allow it to run on other arch levels? (i.e. can an ARM kernel boot for v5 and v6?)
From: Catalin Marinas on 10 May 2010 11:00
On Mon, 2010-05-10 at 15:52 +0100, Valdis.Kletnieks(a)vt.edu wrote: > On Mon, 10 May 2010 16:34:57 +0300, "Kirill A. Shutemov" said: > > > It looks like cache maintenance fault was introduced in ARMv6. > > > > So, what is the right way to fix it? Something like: > > > > #if __LINUX_ARM_ARCH__ < 6 > > { do_bad, SIGBUS, 0, "external > > This would need to be a runtime test, no? Or does LINUX_ARM_ARCH not allow > it to run on other arch levels? (i.e. can an ARM kernel boot for v5 and v6?) v6 and v7 probably but I doubt v5 and v6 would work. There are other #ifdefs in arch/arm/include/asm/system.h like barriers. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |