On 2020-04-17 10:50:35 [+0800], Liwei Song wrote:
>
>
> On 4/17/20 01:09, Sebastian Andrzej Siewior wrote:
> > On 2020-04-13 12:18:17 [+0800], Liwei Song wrote:
> >> Interrupts are off during resume from RAM, this will triger a warning
> >> when allocate memory in non-preemptible context on RT since commit
> >> b5d5bc970f209 ("mm: Warn on memory allocation in non-preemptible
> >> context on RT"), exclude suspend from this warning check.
> >
> > Is this the ACPI backtrace or do you have something else?
>
> Yes, there are two backtrace here include one ACPI Calltrace, another one
> is from iommu:
>
> 1).
> [ 88.992342] ? acpi_os_allocate_zeroed+0x28/0x2a
> [ 88.992349] acpi_os_allocate_zeroed+0x28/0x2a
> [ 88.992351] acpi_ns_internalize_name+0x4b/0xa0
> [ 88.992354] ? trace_preempt_on+0x2a/0x120
> [ 88.992360] acpi_ns_get_node_unlocked+0x6f/0xd7
> [ 88.992362] ? _raw_spin_unlock_irqrestore+0x42/0x90
> [ 88.992367] ? down_timeout+0x3c/0x60
> [ 88.992372] ? acpi_os_wait_semaphore+0x4d/0x70
> [ 88.992378] acpi_ns_get_node+0x43/0x5d
>
> 2).
> [ 88.991560] Call Trace:
> [ 88.991561] ? _raw_spin_unlock_irqrestore+0x42/0x90
> [ 88.991563] ? iommu_suspend+0x4f/0x1c0
> [ 88.991569] iommu_suspend+0x4f/0x1c0
> [ 88.991572] syscore_suspend+0x9b/0x3e0
> [ 88.991575] suspend_devices_and_enter+0x1fb/0xec0
> [ 88.991579] ? rcu_read_lock_sched_held+0x4f/0x80
> [ 88.991580] ? prb_unlock+0x18/0x80
> [ 88.991585] pm_suspend.cold+0x326/0x37b
>
> During suspend phase the only way to make preemptible() happy is
> enable interrupt before kcalloc/kmalloc/kzalloc, but enable interrupt
> may cause some unknown issue if device access I/O address which already
> suspend, so I think it's better and safe to exclude suspend from this
> warning check.
At this point all CPUs are down so there is no scheduling. No lock
within the buddy allocator should not be acquired by another task. That
looks good.
But: calling into the buddy allocator goes via allocate_slab() which
enables interrupts.
> Thanks,
> Liwei.
Sebastian
