[Devel] [PATCH v3 vz9/vz10] dm-ploop: fallback to kvmalloc for large bvec allocations

[Pavel Tikhomirov]

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.