On 17/02/2021 09:03, Michal Hocko wrote:
>> No I don't think so. A mutex isn't a spinlock so we can sleep on the allocation.
>> We can't use GFP_KERNEL as we're about to do I/O. blk_revalidate_disk_zones() called
>> a few line below also does the memalloc_noio_{save,restore}() dance.
>
> You should be extending noio scope then if this allocation falls into
> the same category. Ideally the scope should start at the recursion place
> and end where the scope really ened.
That means all callers of blk_revalidate_disk_zones() should do
memalloc_noio_{save,restore}? If yes, can we somehow runtime assert
that this is done, so we don't end up with bad surprises?
>>
>> Would a kmem_cache for these revalidations help us in any way?
>
> I am not sure what you mean here.
>
Using a kmem_cache for the allocations passed into blk_revalidate_disk_zones().
I've looked into kmem_cache_alloc() and I couldn't find anything that speaks
against it, but I'm not too familiar with the code.
