On Wed, Jan 11, 2017 at 10:54 AM, Lv Zheng <lv.zheng@xxxxxxxxx> wrote: > The rcu synchronization logic is originally provided to protect > apei_read()/apei_write() as in the APEI drivers, there is NMI event source > requiring non spinlock based synchronization mechanism. After that, ACPI > developers think FADT registers may also require same facility, so they > moved the RCU stuffs to generic ACPI layer. So now interrupt (irq, nmi) > context ACPI map lookup is only protected by RCU. > > This triggers a kernel hang when ACPICA API starts to unmap unused tables > (see Link #1 for details). The cause of the hang is > drivers/iommu/amd_iommu_init.c calling acpi_put_table() too early and then > land in RCU which is uninitialized yet: > early_amd_iommu_init() > acpi_put_table(ivrs_base) > acpi_os_unmap_memory() > synchronize_rcu_expedited() > Now that function goes and sends IPIs, i.e., schedule_work() but this is > too early - workqueue_init() hasn't been invoked. Actually, from looking > at the callstack, we do kernel_init_freeable()->native_smp_prepare_cpus() > and workqueue_init() comes next. > > Actually this facility is only used to protect interrupt context ACPI map > lookup, and such mappings are only introduced by > acpi_os_map_generic_address(). So before it is invoked, there is no need to > use RCU, mutex should be used instead of. Why should the mutex be used then? There's nothing wrong with using RCU in all cases except when that happens early on boot when things don't work as expected, but at that time there's no need to do the synchronization *at* *all* as the list protected by RCU is not even walked. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
