From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Liwei Song <liwei.song@windriver.com>
Cc: linux-rt <linux-rt-users@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH RT] mm: do not warn for suspend when allocate memory on RT
Date: Tue, 21 Apr 2020 16:51:47 +0200 [thread overview]
Message-ID: <20200421145147.lejozjuvjjd4nmyf@linutronix.de> (raw)
In-Reply-To: <8cd11f67-dbf8-cce9-548f-ccc544f9486c@windriver.com>
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
next prev parent reply other threads:[~2020-04-21 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 4:18 [PATCH RT] mm: do not warn for suspend when allocate memory on RT Liwei Song
2020-04-16 17:09 ` Sebastian Andrzej Siewior
2020-04-17 2:50 ` Liwei Song
2020-04-21 14:51 ` Sebastian Andrzej Siewior [this message]
2020-04-24 9:09 ` Liwei Song
2020-05-04 14:53 ` [PATCH RT] mm: Don't warn about atomic memory allocations during suspend Sebastian Andrzej Siewior
2020-05-05 3:59 ` Liwei Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200421145147.lejozjuvjjd4nmyf@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=efault@gmx.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=liwei.song@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).