On Tue, Apr 23, 2024 at 1:14 PM Sergei Antonov <saproj@xxxxxxxxx> wrote: > 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. This puzzles me since sg_miter_start() isn't doing anything that is atomic, such as kmap_atomic(), which is only done in sg_miter_next(). It doesn't even look at the flags, just assign it to __flags in struct sg_mapping_iter. I.e. calling sg_miter_start(,,,SG_MITER_ATOMIC) does not need to happen in an atomic context. Yours, Linus Walleij
