Does iommu_init_table need to use GFP_ATOMIC allocations?

[Michael Ellerman]

On Thu, Sep 19, 2013 at 09:50:35AM -0700, Nishanth Aravamudan wrote:
> Under heavy (DLPAR?) stress, we tripped this panic() in
> arch/powerpc/kernel/iommu.c::iommu_init_table():
> 
>         page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
>         if (!page)
>                 panic("iommu_init_table: Can't allocate %ld bytes\n",
> sz);
> 
> Before the panic() we got a page allocation failure for an order-2
> allocation. There appears to be memory free, but perhaps not in the
> ATOMIC context. I looked through all the call-sites of
> iommu_init_table() and didn't see any obvious reason to need an ATOMIC
> allocation. Most call-sites in fact have an explicit GFP_KERNEL
> allocation shortly before the call to iommu_init_table(), indicating we
> are not in an atomic context. There is some indirection for some paths,
> but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
> Does anyone know if/why ATOMIC allocations are necessary here?

I can't see any reason for it.

It was GFP_ATOMIC in the initial ppc64 code submission, so there's no
explanation in the commit history for it.

cheers