mtd: Fix bug using smp_processor_id() in preemptible ubi_bgt1d kthread
in [Kernel]
|
Prev: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300
Next: Intel IOMMU double lock
From: Jamie Lokier on 14 Jun 2010 11:10 Philby John wrote: > mtd: Fix bug using smp_processor_id() in preemptible ubi_bgt1d kthread > > On a MIPS Cavium Octeon CN5020 when trying to create a UBI volume, > on the NOR flash, the kernel thread ubi_bgt1d calls > cfi_amdstd_write_buffers() --> do_write_buffer() --> > INVALIDATE_CACHE_UDELAY --> __udelay(). Its __udelay() that calls > smp_processor_id() in preemptible code, which you are not supposed to. > Fix the problem by disabling preemption. The MTD code just calls udelay(). Are you sure it isn't permitted to call udelay() from preemptible code? I think it is fine. Perhaps MIPS udelay() should be disabling preemption itself, or (as x86 does) using raw_smp_processor_id() instead? Or perhaps the x86 version is a bug because the current CPU might change during the delay loop? See git commit 5c1ea08215f1f830dfaf4819a5f22efca41c3832 "x86: enable preemption in delay" I don't think it makes sense to disable preemption in all udelay() calls in drivers, so my NAK to this MTD patch. To workaround, consider putting the preempt_disable in MIPS udelay(), or using raw_smp_processor_id() in it, after reading the above git commit's message. A proper fix would accept a context switch during the delay and rescale the remaining count, but even on x86 they haven't done that yet :-) Regards, -- Jamie -- 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/ |