From: David Hildenbrand <hidden> Date: 2018-12-14 11:10:45
I was recently going over all users of PG_reserved. Short story: it is
difficult and sometimes not really clear if setting/checking for
PG_reserved is only a relict from the past. Easy to break things. I
guess I know have a pretty good idea wh things are like that
nowadays and how they evolved.
I had way more cleanups in this series inititally,
but some architectures take PG_reserved as a way to apply a different
caching strategy (for MMIO pages). So I decided to only include the most
obvious changes (that are less likely to break something). So the big
chunk of manual SetPageReserved users are MMIO/DMA related things on
device buffers.
Most notably, for device memory we will hopefully soon stop setting
PG_reserved. The the documentation has to be updated.
RFC -> V1:
- Add more details to "mm: better document PG_reserved"
- Add "arm64: kdump: No need to mark crashkernel pages manually
PG_reserved"
- Add "ia64: perfmon: Don't mark buffer pages as PG_reserved"
- Added ACKs
David Hildenbrand (9):
agp: efficeon: no need to set PG_reserved on GATT tables
s390/vdso: don't clear PG_reserved
powerpc/vdso: don't clear PG_reserved
riscv/vdso: don't clear PG_reserved
m68k/mm: use __ClearPageReserved()
arm64: kexec: no need to ClearPageReserved()
arm64: kdump: No need to mark crashkernel pages manually PG_reserved
ia64: perfmon: Don't mark buffer pages as PG_reserved
mm: better document PG_reserved
arch/arm64/kernel/machine_kexec.c | 3 +-
arch/arm64/mm/init.c | 27 --------------
arch/ia64/kernel/perfmon.c | 59 +++----------------------------
arch/m68k/mm/memory.c | 2 +-
arch/powerpc/kernel/vdso.c | 2 --
arch/riscv/kernel/vdso.c | 1 -
arch/s390/kernel/vdso.c | 2 --
drivers/char/agp/efficeon-agp.c | 2 --
include/linux/page-flags.h | 33 +++++++++++++++--
9 files changed, 37 insertions(+), 94 deletions(-)
--
2.17.2
From: David Hildenbrand <hidden> Date: 2018-12-14 11:10:48
The l1 GATT page table is kept in a special on-chip page with 64 entries.
We allocate the l2 page table pages via get_zeroed_page() and enter them
into the table. These l2 pages are modified accordingly when
inserting/removing memory via efficeon_insert_memory and
efficeon_remove_memory.
Apart from that, these pages are not exposed or ioremap'ed. We can stop
setting them reserved (propably copied from generic code).
Cc: David Airlie <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Hildenbrand <redacted>
---
drivers/char/agp/efficeon-agp.c | 2 --
1 file changed, 2 deletions(-)
From: David Hildenbrand <hidden> Date: 2018-12-14 11:10:53
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Suggested-by: Martin Schwidefsky <redacted>
Cc: Martin Schwidefsky <redacted>
Cc: Heiko Carstens <redacted>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mike Rapoport <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Kees Cook <redacted>
Cc: Souptick Joarder <redacted>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: David Hildenbrand <redacted>
---
arch/s390/kernel/vdso.c | 2 --
1 file changed, 2 deletions(-)
From: David Hildenbrand <hidden> Date: 2018-12-14 11:10:57
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <redacted>
Cc: Kees Cook <redacted>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Hildenbrand <redacted>
---
arch/powerpc/kernel/vdso.c | 2 --
1 file changed, 2 deletions(-)
From: David Hildenbrand <hidden> Date: 2018-12-14 11:11:00
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Cc: Palmer Dabbelt <redacted>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Tobias Klauser <tklauser@distanz.ch>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Acked-by: Palmer Dabbelt <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
arch/riscv/kernel/vdso.c | 1 -
1 file changed, 1 deletion(-)
From: David Hildenbrand <hidden> Date: 2018-12-14 11:11:04
The PG_reserved flag is cleared from memory that is part of the kernel
image (and therefore marked as PG_reserved). Avoid using PG_reserved
directly.
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Hildenbrand <redacted>
---
arch/m68k/mm/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -51,7 +51,7 @@ void __init init_pointer_table(unsigned long ptable)pr_debug("init_pointer_table: %lx, %x\n",ptable,PD_MARKBITS(dp));/* unreserve the page so it's possible to free that page */-PD_PAGE(dp)->flags&=~(1<<PG_reserved);+__ClearPageReserved(PD_PAGE(dp));init_page_count(PD_PAGE(dp));return;
From: David Hildenbrand <hidden> Date: 2018-12-14 11:11:09
This will be done by free_reserved_page().
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Cc: Bhupesh Sharma <redacted>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <redacted>
Cc: Dave Kleikamp <redacted>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Acked-by: James Morse <james.morse@arm.com>
Signed-off-by: David Hildenbrand <redacted>
---
arch/arm64/kernel/machine_kexec.c | 1 -
1 file changed, 1 deletion(-)
From: David Hildenbrand <hidden> Date: 2018-12-14 11:11:15
The crashkernel is reserved via memblock_reserve(). memblock_free_all()
will call free_low_memory_core_early(), which will go over all reserved
memblocks, marking the pages as PG_reserved.
So manually marking pages as PG_reserved is not necessary, they are
already in the desired state (otherwise they would have been handed over
to the buddy as free pages and bad things would happen).
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Cc: James Morse <james.morse@arm.com>
Cc: Bhupesh Sharma <redacted>
Cc: David Hildenbrand <redacted>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Dave Kleikamp <redacted>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Laura Abbott <redacted>
Cc: Greg Hackmann <redacted>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kristina Martsenko <redacted>
Cc: CHANDAN VN <redacted>
Cc: AKASHI Takahiro <redacted>
Cc: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: David Hildenbrand <redacted>
---
arch/arm64/kernel/machine_kexec.c | 2 +-
arch/arm64/mm/init.c | 27 ---------------------------
2 files changed, 1 insertion(+), 28 deletions(-)
@@ -586,8 +561,6 @@ void __init mem_init(void)/* this will put all unused low memory onto the freelists */memblock_free_all();-kexec_reserve_crashkres_pages();-mem_init_print_info(NULL);/*
From: David Hildenbrand <hidden> Date: 2018-12-14 11:11:24
In the old days, remap_pfn_range() required pages to be marked as
PG_reserved, so they would e.g. never get swapped out. This was required
for special mappings. Nowadays, this is fully handled via the VMA
(VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP inside remap_pfn_range()
to be precise). PG_reserved is no longer required but only a relict from
the past.
So only architecture specific MM handling might require it (e.g. to
detect them as MMIO pages). As there are no architecture specific checks
for PageReserved() apart from MCA handling in ia64code, this can go. Use
simple vzalloc()/vfree() instead.
Note that before calling vzalloc(), size has already been aligned to
PAGE_SIZE, no need to align again.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <redacted>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <redacted>
Cc: David Howells <dhowells@redhat.com>
Cc: Mike Rapoport <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: David Hildenbrand <redacted>
---
arch/ia64/kernel/perfmon.c | 59 +++-----------------------------------
1 file changed, 4 insertions(+), 55 deletions(-)
From: David Hildenbrand <hidden> Date: 2018-12-14 11:11:31
The usage of PG_reserved and how PG_reserved pages are to be treated is
buried deep down in different parts of the kernel. Let's shine some light
onto these details by documenting current users and expected
behavior.
Especially, clarify on the "Some of them might not even exist" case.
These are physical memory gaps that will never be dumped as they
are not marked as IORESOURCE_SYSRAM. PG_reserved does in general not
hinder anybody from dumping or swapping. In some cases, these pages
will not be stored in the hibernation image.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <redacted>
Cc: Pavel Tatashin <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Alexander Duyck <redacted>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Anthony Yznaga <redacted>
Cc: Miles Chen <redacted>
Cc: yi.z.zhang@linux.intel.com
Cc: Dan Williams <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
include/linux/page-flags.h | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
From: Randy Dunlap <hidden> Date: 2018-12-15 00:12:58
On 12/14/18 3:10 AM, David Hildenbrand wrote:
The usage of PG_reserved and how PG_reserved pages are to be treated is
buried deep down in different parts of the kernel. Let's shine some light
onto these details by documenting current users and expected
behavior.
Especially, clarify on the "Some of them might not even exist" case.
These are physical memory gaps that will never be dumped as they
are not marked as IORESOURCE_SYSRAM. PG_reserved does in general not
hinder anybody from dumping or swapping. In some cases, these pages
will not be stored in the hibernation image.
Hi,
Thanks for the doc update.
Comments below.
quoted hunk
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <redacted>
Cc: Pavel Tatashin <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Alexander Duyck <redacted>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Anthony Yznaga <redacted>
Cc: Miles Chen <redacted>
Cc: yi.z.zhang@linux.intel.com
Cc: Dan Williams <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
include/linux/page-flags.h | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
+ * Pages marked as PG_reserved include:
+ * - Pages part of the kernel image (including vDSO) and similar (e.g. BIOS,
+ * initrd, HW tables)
+ * - Pages reserved or allocated early during boot (before the page allocator
+ * was initialized). This includes (depending on the architecture) the
+ * initial vmmap, initial page tables, crashkernel, elfcorehdr, and much
VM map,
+ * much more. Once (if ever) freed, PG_reserved is cleared and they will
+ * be given to the page allocator.
+ * - Pages falling into physical memory gaps - not IORESOURCE_SYSRAM. Trying
+ * to read/write these pages might end badly. Don't touch!
+ * - The zero page(s)
+ * - Pages not added to the page allocator when onlining a section because
+ * they were excluded via the online_page_callback() or because they are
+ * PG_hwpoison.
+ * - Pages allocated in the context of kexec/kdump (loaded kernel image,
+ * control pages, vmcoreinfo)
+ * - MMIO/DMA pages. Some architectures don't allow to ioremap pages that are
+ * not marked PG_reserved (as they might be in use by somebody else who does
+ * not respect the caching strategy).
+ * - Pages part of an offline section (struct pages of offline sections should
+ * not be trusted as they will be initialized when first onlined).
+ * - MCA pages on ia64
+ * - Pages holding CPU notes for POWER Firmware Assisted Dump
+ * - Device memory (e.g. PMEM, DAX, HMM)
+ * Some PG_reserved pages will be excluded from the hibernation image.
+ * PG_reserved does in general not hinder anybody from dumping or swapping
+ * and is no longer required for remap_pfn_range(). ioremap might require it.
+ * Consequently, PG_reserved for a page mapped into user space can indicate
+ * the zero page, the vDSO, MMIO pages or device memory.
*
* The PG_private bitflag is set on pagecache pages if they contain filesystem
* specific data (which is normally at page->private). It can be used by
This will be done by free_reserved_page().
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <redacted>
Cc: Bhupesh Sharma <redacted>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <redacted>
Cc: Dave Kleikamp <redacted>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Acked-by: James Morse <james.morse@arm.com>
Signed-off-by: David Hildenbrand <redacted>
From: David Hildenbrand <hidden> Date: 2018-12-17 09:35:08
On 15.12.18 01:12, Randy Dunlap wrote:
On 12/14/18 3:10 AM, David Hildenbrand wrote:
quoted
The usage of PG_reserved and how PG_reserved pages are to be treated is
buried deep down in different parts of the kernel. Let's shine some light
onto these details by documenting current users and expected
behavior.
Especially, clarify on the "Some of them might not even exist" case.
These are physical memory gaps that will never be dumped as they
are not marked as IORESOURCE_SYSRAM. PG_reserved does in general not
hinder anybody from dumping or swapping. In some cases, these pages
will not be stored in the hibernation image.
Hi,
Thanks for the doc update.
Comments below.
quoted
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <redacted>
Cc: Pavel Tatashin <redacted>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Alexander Duyck <redacted>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Anthony Yznaga <redacted>
Cc: Miles Chen <redacted>
Cc: yi.z.zhang@linux.intel.com
Cc: Dan Williams <redacted>
Signed-off-by: David Hildenbrand <redacted>
---
include/linux/page-flags.h | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
+ * Pages marked as PG_reserved include:
+ * - Pages part of the kernel image (including vDSO) and similar (e.g. BIOS,
+ * initrd, HW tables)
+ * - Pages reserved or allocated early during boot (before the page allocator
+ * was initialized). This includes (depending on the architecture) the
+ * initial vmmap, initial page tables, crashkernel, elfcorehdr, and much
VM map,
This should actually be vmemmap (aka struct pages).
quoted
+ * much more. Once (if ever) freed, PG_reserved is cleared and they will
+ * be given to the page allocator.
+ * - Pages falling into physical memory gaps - not IORESOURCE_SYSRAM. Trying
+ * to read/write these pages might end badly. Don't touch!
+ * - The zero page(s)
+ * - Pages not added to the page allocator when onlining a section because
+ * they were excluded via the online_page_callback() or because they are
+ * PG_hwpoison.
+ * - Pages allocated in the context of kexec/kdump (loaded kernel image,
+ * control pages, vmcoreinfo)
+ * - MMIO/DMA pages. Some architectures don't allow to ioremap pages that are
+ * not marked PG_reserved (as they might be in use by somebody else who does
+ * not respect the caching strategy).
+ * - Pages part of an offline section (struct pages of offline sections should
+ * not be trusted as they will be initialized when first onlined).
+ * - MCA pages on ia64
+ * - Pages holding CPU notes for POWER Firmware Assisted Dump
+ * - Device memory (e.g. PMEM, DAX, HMM)
+ * Some PG_reserved pages will be excluded from the hibernation image.
+ * PG_reserved does in general not hinder anybody from dumping or swapping
+ * and is no longer required for remap_pfn_range(). ioremap might require it.
+ * Consequently, PG_reserved for a page mapped into user space can indicate
+ * the zero page, the vDSO, MMIO pages or device memory.
*
* The PG_private bitflag is set on pagecache pages if they contain filesystem
* specific data (which is normally at page->private). It can be used by
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-12-17 11:38:49
David Hildenbrand [off-list ref] writes:
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <redacted>
Cc: Kees Cook <redacted>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: David Hildenbrand <redacted>
---
arch/powerpc/kernel/vdso.c | 2 --
1 file changed, 2 deletions(-)
Thanks.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers