On Mon, 22 Apr 2024 at 20:55, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Sat, Apr 20, 2024 at 10:38 PM Sergei Antonov <saproj@xxxxxxxxx> wrote: > > > [ 7.018270] BUG: scheduling while atomic: kworker/0:1/9/0x00000002 > (...) > > [ 7.057443] CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.8.0-rc4+ #225 > > [ 7.064527] Hardware name: Generic DT based system > > [ 7.069677] Workqueue: events_freezable mmc_rescan > > [ 7.075121] unwind_backtrace from show_stack+0x10/0x14 > > [ 7.080930] show_stack from dump_stack_lvl+0x34/0x44 > > [ 7.086576] dump_stack_lvl from __schedule_bug+0x64/0x84 > > [ 7.092608] __schedule_bug from __schedule+0x58/0x594 > > [ 7.098320] __schedule from schedule+0x74/0xa8 > > [ 7.103368] schedule from schedule_timeout+0xd4/0x108 > > [ 7.109070] schedule_timeout from __wait_for_common+0x94/0x120 > > [ 7.115547] __wait_for_common from moxart_request+0x278/0x468 > > [ 7.121980] moxart_request from mmc_start_request+0x94/0xa8 > > moxart_transfer_pio() is called from the interrupt handler and > should be properly atomic right, so the flags to sg_miter should > be fine. The stack in my message does not include moxart_irq() or moxart_transfer_pio(). It is not an IRQ. As a result of commit 3ee0e7c3e67cab83ffbbe7707b43df8d41c9fe47 SG_MITER_ATOMIC is used in the context of moxart_request(): moxart_request() -> moxart_prepare_data() -> sg_miter_start(,,,SG_MITER_ATOMIC) and in the same context down in the code a wait_for_completion_interruptible_timeout() is called. > The way I read it is that the completion does not arrive and that triggers > a timeout, am I right? No, timeout does not happen. Function schedule_timeout() is named so because it receives a timeout value as an argument.
