From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Yongqiang Liu <liuyongqiang13@huawei.com>,
linux-arm-kernel@lists.infradead.org, yanaijie@huawei.com,
zhangxiaoxu5@huawei.com, wangkefeng.wang@huawei.com,
sunnanyong@huawei.com, rppt@linux.ibm.com,
linux-kernel@vger.kernel.org, keescook@chromium.org,
arnd@arndb.de, m.szyprowski@samsung.com, willy@infradead.org
Subject: Re: [PATCH] arm: flush: don't abuse pfn_valid() to check if pfn is in RAM
Date: Wed, 31 Jan 2024 19:00:39 +0000 [thread overview]
Message-ID: <ZbqY12U/CXwAAu7A@shell.armlinux.org.uk> (raw)
In-Reply-To: <0da50102-3e87-49f7-b8f7-45cfcb4232d6@arm.com>
On Wed, Jan 31, 2024 at 06:39:31PM +0000, Robin Murphy wrote:
> On 31/01/2024 12:59 pm, Yongqiang Liu wrote:
> > @@ -292,7 +293,7 @@ void __sync_icache_dcache(pte_t pteval)
> > /* only flush non-aliasing VIPT caches for exec mappings */
> > return;
> > pfn = pte_pfn(pteval);
> > - if (!pfn_valid(pfn))
> > + if (!memblock_is_map_memory(PFN_PHYS(pfn)))
> > return;
> > folio = page_folio(pfn_to_page(pfn));
>
> Hmm, it's a bit odd in context, since pfn_valid() obviously pairs with this
> pfn_to_page(), whereas it's not necessarily clear that
> memblock_is_map_memory() implies pfn_valid().
>
> However, in this case we're starting from a PTE - rather than going off to
> do a slow scan of memblock to determine whether a round-trip through
> page_address() is going to give back a mapped VA, can we not trivially
> identify that from whether the PTE itself is valid?
Depends what you mean by "valid". If you're referring to pte_valid()
and L_PTE_VALID then no.
On 32-bit non-LPAE, the valid bit is the same as the present bit, and
needs to be set for the PTE to not fault. Any PTE that is mapping
something will be "valid" whether it is memory or not, whether it is
backed by a page or not.
pfn_valid() should be telling us whether the PFN is suitable to be
passed to pfn_to_page(), and if we have a situation where pfn_valid()
returns true, but pfn_to_page() returns an invalid page, then that in
itself is a bug that needs to be fixed and probably has far reaching
implications for the stability of the kernel.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-31 19:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 12:59 [PATCH] arm: flush: don't abuse pfn_valid() to check if pfn is in RAM Yongqiang Liu
2024-01-31 16:16 ` Florian Fainelli
2024-01-31 18:39 ` Robin Murphy
2024-01-31 19:00 ` Russell King (Oracle) [this message]
2024-01-31 21:20 ` Robin Murphy
2024-02-01 8:00 ` Yongqiang Liu
2024-02-01 9:00 ` Mike Rapoport
2024-02-02 3:19 ` Yongqiang Liu
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=ZbqY12U/CXwAAu7A@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=arnd@arndb.de \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyongqiang13@huawei.com \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=rppt@linux.ibm.com \
--cc=sunnanyong@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=yanaijie@huawei.com \
--cc=zhangxiaoxu5@huawei.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).