Smatch complains correctly that it is a bug to call iounmap while
holding a spin_lock (or other actions which disable preemption).
However there are too many bugs for me to look at them so I'm just
going to forward the list here and whoever wants to can fix them as
a kind of newbie project.
The Smatch warnings look like:
arch/x86/mm/ioremap.c:471 iounmap() warn: sleeping in atomic context
arch/x86/mm/ioremap.c:494 iounmap() warn: sleeping in atomic context
Which means that the iounmap() function sleeps. Then we run
`smatch/smatch_data/db/smdb.py preempt iounmap` to get the list of
callers which disable preemption.
The raw output is below. Basically every "disables preempt" is a bug.
In the first example, tsi148_master_set() calls spin_lock(&image->lock),
then it calls tsi148_alloc_resource() which calls iounmap(). Clear bug.
However it's not clear how to fix it necessarily.
regards,
dan carpenter
tsi148_master_set() <- disables preempt
-> tsi148_alloc_resource()
hfc_remove_pci() <- disables preempt
-> release_card()
-> release_io_hfcmulti()
pcc_get_freq() <- disables preempt
pcc_cpufreq_target() <- disables preempt
-> pcc_cmd()
-> acpi_read()
-> acpi_hw_read()
ghes_poll_func() <- disables preempt
ghes_irq_func() <- disables preempt
ghes_notify_hed() <- disables preempt
ghes_probe() <- disables preempt
-> ghes_proc()
ghes_notify_nmi() <- disables preempt
-> ghes_in_nmi_spool_from_list()
ghes_sdei_normal_callback() <- disables preempt
ghes_sdei_critical_callback() <- disables preempt
-> __ghes_sdei_callback()
-> ghes_in_nmi_queue_one_entry()
-> __ghes_panic()
ghes_in_nmi_queue_one_entry() <duplicate>
-> ghes_clear_estatus()
-> ghes_ack_error()
ghes_proc() <duplicate>
-> ghes_read_estatus()
ghes_in_nmi_queue_one_entry() <duplicate>
-> __ghes_peek_estatus()
-> apei_read()
-> acpi_os_read_memory()
pcc_cmd() <duplicate>
-> acpi_write()
-> acpi_hw_write()
ghes_ack_error() <duplicate>
-> apei_write()
-> acpi_os_write_memory()
-> iounmap()
