On 10/22/25 23:20, Vasileios Almpanis wrote:
@@ -2615,7 +2624,7 @@ static void ploop_submit_embedded_pio(struct ploop
*ploop, struct pio *pio)
goto out;
}
- ploop_prepare_one_embedded_pio(ploop, pio, &deferred_pios);
+ ploop_prepare_one_embedded_pio(ploop, pio, &deferred_pios, GFP_ATOMIC |
__GFP_NOWARN);
/*
* Disable fast path due to rcu lockups fs -> ploop -> fs - fses are
not reentrant
* we can however try another fast path skip dispatcher thread and pass
directly to
Stupid question, do we really need GFP_ATOMIC at all on request sending
path?
For all the paths where ploop_submit_embedded_pio is called:
+-< ploop_submit_embedded_pio
+-< ploop_submit_embedded_pios
| +-< ploop_resume_submitting_pios
| | +-< ploop_suspend_submitting_pios
| | +-< ploop_resize
| | +-< ploop_merge_latest_snapshot
| | +-< ploop_delta_clusters_merged
| | +-< ploop_update_delta_index
| +-< ploop_resubmit_enospc_pios
| | +-< do_ploop_run_work
| | +-< ploop_presuspend
+-< ploop_clone_and_map
+-< map_request
+-< dm_mq_queue_rq
+-< blk_mq_dispatch_rq_list
+-< __blk_mq_issue_directly
+-< __blk_mq_flush_plug_list
I don't really see any interrupt-path. Can device mapper really call us
from interrupt context?
Note in original bug where we've decided to add GFP_ATOMIC
https://virtuozzo.atlassian.net/browse/VSTOR-98291 we have stacks that
are definitely not from interrupts. It might just be that we take some
rcu/spinlocks on those paths and thus we had problems with sleep =) :
468.029539] BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:273
[ 468.030477] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid:
6110, name: dd
[ 468.031288] preempt_count: 0, expected: 0
[ 468.031731] RCU nest depth: 1, expected: 0
[ 466.575891] BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:273
[ 466.576971] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid:
5954, name: ploop22352-r-8
[ 466.577871] preempt_count: 1, expected: 0
If I checkout to "99e18f6fee415ac23a9193d001bcc80fd520da16~" I clearly
see that it was spinlock:
ploop_prepare_bat_update() {
lockdep_assert_held(&ploop->bat_lock); // which is spinlock
piwb = kmalloc(sizeof(*piwb), GFP_NOIO); // sleeping allocation
}
Maybe we just should not try allocations under spinlock/rcu and that
would save us from using GFP_ATOMIC everywhere.
Maybe I'm missing something?
--
Best regards, Pavel Tikhomirov
Senior Software Developer, Virtuozzo.
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
