Messages in this thread | | | Date | Thu, 17 Sep 2020 18:30:01 +0200 | From | Sebastian Siewior <> | Subject | Re: [patch 09/10] sched/core: Add migrate_disable/enable() |
| |
On 2020-09-17 17:54:10 [+0200], peterz@infradead.org wrote: > I'm not sure what the problem with FPU was, I was throwing alternatives > at tglx to see what would stick, in part to (re)discover the design > constraints of this thing.
was this recent or distant in the time line?
> One reason for not allowing migrate_disable() to sleep was: FPU code. > > Could it be it does something like: > > preempt_disable(); > spin_lock(); > > spin_unlock(); > preempt_enable(); > > Where we'll never get preempted while migrate_disable()'d and thus never > trigger any of the sleep paths?
I try to get rid of something like that. This doesn't work either way because the spin_lock() may block which it can't with disabled preemption.
Looking at my queue, FPU related is crypto. And here we break the loops mostly due to the construct: kernel_fpu_begin(); while (bytes) crypto_thingy(); skcipher_walk_done()
and skcipher_walk_done() could allocate/free/map memory. This is independent.
Ah. We used to have migrate_disable() in pagefault_disable(). The x86 FPU code does preempt_disable(); … pagefault_disable();
but that migrate_disable() was moved from pagefault_disable() to kmap_atomic(). We shouldn't have preempt_disable(); || local_irq_disable(); kmap_atomic();
on RT. I've been running around removing those. See a10dcebacdb0c ("fs/ntfs/aops.c: don't disable interrupts during kmap_atomic()") ce1e518190ea7 ("ide: don't disable interrupts during kmap_atomic()") f3a1075e5fc34 ("block: don't disable interrupts during kmap_atomic()")
Sebastian
| |