[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230906150309.114360-1-zi.yan@sent.com>
Date: Wed, 6 Sep 2023 11:03:04 -0400
From: Zi Yan <zi.yan@...t.com>
To: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-mips@...r.kernel.org
Cc: Zi Yan <ziy@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
David Hildenbrand <david@...hat.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Muchun Song <muchun.song@...ux.dev>,
"Mike Rapoport (IBM)" <rppt@...nel.org>
Subject: [PATCH v2 0/5] Use nth_page() in place of direct struct page manipulation
From: Zi Yan <ziy@...dia.com>
On SPARSEMEM without VMEMMAP, struct page is not guaranteed to be
contiguous, since each memory section's memmap might be allocated
independently. hugetlb pages can go beyond a memory section size, thus
direct struct page manipulation on hugetlb pages/subpages might give
wrong struct page. Kernel provides nth_page() to do the manipulation
properly. Use that whenever code can see hugetlb pages.
The patches are on top of next-20230906
Changes from v1:
1. Separated first patch into three and add Fixes for better backport.
2. Collected Reviewed-by.
Zi Yan (5):
mm/cma: use nth_page() in place of direct struct page manipulation.
mm/hugetlb: use nth_page() in place of direct struct page
manipulation.
mm/memory_hotplug: use nth_page() in place of direct struct page
manipulation.
fs: use nth_page() in place of direct struct page manipulation.
mips: use nth_page() in place of direct struct page manipulation.
arch/mips/mm/cache.c | 2 +-
fs/hugetlbfs/inode.c | 4 ++--
mm/cma.c | 2 +-
mm/hugetlb.c | 2 +-
mm/memory_hotplug.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
--
2.40.1
Powered by blists - more mailing lists