Received-SPF: pass (google.com: domain of linux-kernel+bounces-81316-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 26 Feb 2024 11:57:29 +0000
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: 20240223063608.2605736-1-liuyongqiang13@huawei.com
Cc: liuyongqiang13@huawei.com, arnd@arndb.de, keescook@chromium.org,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	m.szyprowski@samsung.com, rppt@linux.ibm.com, sunnanyong@huawei.com,
	wangkefeng.wang@huawei.com, willy@infradead.org,
	yanaijie@huawei.com, zhangxiaoxu5@huawei.com
Subject: Re: [PATCH v2] arm: flush: check if the folio is reserved for
 no-mapping addresses
Message-ID: <Zdx8qZLyjh4pO+vx@shell.armlinux.org.uk>
References: <20240223063608.2605736-1-liuyongqiang13@huawei.com>
 <788c8a64-09ed-96fd-9878-ed126b09c683@huawei.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <788c8a64-09ed-96fd-9878-ed126b09c683@huawei.com>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>

On Mon, Feb 26, 2024 at 02:38:58PM +0800, Jinjiang Tu wrote:
> Since some abuses of pfn_valid() have been reported, I check all the use of
> pfn_valid(), and find some suspicious cases.

I do get really tired of kernel interfaces migrating to become something
different from what they were when code was originally written, and then
having users of that interface labelled as "suspicious" or an "abuse".

I don't follow MM stuff, so I can't comment on the rights or wrongs of
this, but what I understood was that pfn_valid() is there to check that
for a given PFN, pfn_to_page() would return a valid pointer to a struct
page. Given that we only have struct page's for memory which the kernel
is managing, this seems entirely correct.

There may be other RAM in the system which is being managed via
different mechanisms, and because those won't have a struct page
associated with them, pfn_valid() should be returning false (which
means memory carved out for e.g. other processors etc) won't be mapped
cacheable.

Or at least that's how things used to be - because 32-bit Arm's
pfn_valid() was implemented by checking memblock for memory, and
stolen memory _was_ removed from memblock.memory (see
arm_memblock_steal) or quite simply these areas were not passed to
the kernel as memory.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!