From: Dan Carpenter <error27@gmail.com>
To: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: outreachy-kernel@googlegroups.com
Subject: calling iounmap while holding a spinlock (preempt disabled)
Date: Fri, 6 Jan 2023 18:13:58 +0300 [thread overview]
Message-ID: <Y7g6tkauv8eV3ZBm@kili> (raw)
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()
reply other threads:[~2023-01-06 15:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y7g6tkauv8eV3ZBm@kili \
--to=error27@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=outreachy-kernel@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox