From: <yf.wang@mediatek.com>
To: <robin.murphy@arm.com>
Cc: <Libo.Kang@mediatek.com>, <Ning.Li@mediatek.com>,
<iommu@lists.linux-foundation.org>, <joro@8bytes.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>, <matthias.bgg@gmail.com>,
<stable@vger.kernel.org>, <will@kernel.org>,
<wsd_upstream@mediatek.com>, <yf.wang@mediatek.com>
Subject: RE: [PATCH] iommu/iova: Free all CPU rcache for retry when iova alloc failure
Date: Mon, 7 Mar 2022 11:32:46 +0800 [thread overview]
Message-ID: <20220307033246.23051-1-yf.wang@mediatek.com> (raw)
In-Reply-To: <906a446e-3e25-5813-d380-de699a84b6f4@arm.com>
On Fri, 2022-03-04 at 14:03 +0000, Robin Murphy wrote:
>
> OK, so either there's a mystery bug where IOVAs somehow get freed on
> offline CPUs, or the hotplug notifier isn't working correctly, or
> you've
> contrived a situation where alloc_iova_fast() is actually racing
> against
> iova_cpuhp_dead(). In the latter case, the solution is "don't do
> that".
>
> This change should not be necessary.
>
> Thanks,
> Robin.
Hi Robin,
1.As long as iova domain is not destroyed, the cached iovas will always
exist, the only chance to free the cache is the retry flushing
mechanism when alloc fail, but not free cached iova of not online CPU.
2.Iova rcache mechanism is by cpu, but there is no free rcache
mechanism when the CPU state switch.
3.iova.c does not know about CPU state switching, eg.online <--> offline.
Based on the above basic information, this is not a user bug, it is
more like a defect of the iova rcache mechanism.
Thanks,
Yunfei.
next prev parent reply other threads:[~2022-03-07 3:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-04 4:46 [PATCH] iommu/iova: Free all CPU rcache for retry when iova alloc failure yf.wang
2022-03-04 5:00 ` yf.wang
2022-03-04 9:22 ` John Garry
2022-03-07 3:18 ` yf.wang
2022-03-04 14:03 ` Robin Murphy
2022-03-07 3:32 ` yf.wang [this message]
2022-03-07 3:49 ` yf.wang
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=20220307033246.23051-1-yf.wang@mediatek.com \
--to=yf.wang@mediatek.com \
--cc=Libo.Kang@mediatek.com \
--cc=Ning.Li@mediatek.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robin.murphy@arm.com \
--cc=stable@vger.kernel.org \
--cc=will@kernel.org \
--cc=wsd_upstream@mediatek.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).