All of
 help / color / mirror / Atom feed
From: Joerg Roedel <>
To: Andy Lutomirski <>
Cc: Joerg Roedel <>,
	Dave Hansen <>,
	Peter Zijlstra <>,
	Thomas Gleixner <>,
	Ingo Molnar <>, Borislav Petkov <>,
	Andrew Morton <>,
	LKML <>,
	Linux-MM <>
Subject: Re: [PATCH 3/3] mm/vmalloc: Sync unmappings in vunmap_page_range()
Date: Fri, 19 Jul 2019 14:21:11 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 18, 2019 at 12:04:49PM -0700, Andy Lutomirski wrote:
> I find it problematic that there is no meaningful documentation as to
> what vmalloc_sync_all() is supposed to do.

Yeah, I found that too, there is no real design around
vmalloc_sync_all(). It looks like it was just added to fit the purpose
on x86-32. That also makes it hard to find all necessary call-sites.

> Which is obviously entirely inapplicable.  If I'm understanding
> correctly, the underlying issue here is that the vmalloc fault
> mechanism can propagate PGD entry *addition*, but nothing (not even
> flush_tlb_kernel_range()) propagates PGD entry *removal*.

Close, the underlying issue is not about PGD, but PMD entry
addition/removal on x86-32 pae systems.

> I find it suspicious that only x86 has this.  How do other
> architectures handle this?

The problem on x86-PAE arises from the !SHARED_KERNEL_PMD case, which was
introduced by the  Xen-PV patches and then re-used for the PTI-x32
enablement to be able to map the LDT into user-space at a fixed address.

Other architectures probably don't have the !SHARED_KERNEL_PMD case (or
do unsharing of kernel page-tables on any level where a huge-page could
be mapped).

> At the very least, I think this series needs a comment in
> vmalloc_sync_all() explaining exactly what the function promises to
> do.

Okay, as it stands, it promises to sync mappings for the vmalloc area
between all PGDs in the system. I will add that as a comment.

> But maybe a better fix is to add code to flush_tlb_kernel_range()
> to sync the vmalloc area if the flushed range overlaps the vmalloc
> area.

That would also cause needless overhead on x86-64 because the vmalloc
area doesn't need syncing there. I can make it x86-32 only, but that is
not a clean solution imo.

> Or, even better, improve x86_32 the way we did x86_64: adjust
> the memory mapping code such that top-level paging entries are never
> deleted in the first place.

There is not enough address space on x86-32 to partition it like on
x86-64. In the default PAE configuration there are _four_ PGD entries,
usually one for the kernel, and then 512 PMD entries. Partitioning
happens on the PMD level, for example there is one entry (2MB of address
space) reserved for the user-space LDT mapping.



  reply	other threads:[~2019-07-19 12:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17  7:14 [PATCH 0/3 v2] Sync unmappings in vmalloc/ioremap areas Joerg Roedel
2019-07-17  7:14 ` [PATCH 1/3] x86/mm: Check for pfn instead of page in vmalloc_sync_one() Joerg Roedel
2019-07-17  7:14 ` [PATCH 2/3] x86/mm: Sync also unmappings " Joerg Roedel
2019-07-17 21:06   ` Dave Hansen
2019-07-18  8:44     ` Joerg Roedel
2019-07-17 21:43   ` Thomas Gleixner
2019-07-17 21:43     ` Thomas Gleixner
2019-07-18  8:46     ` Joerg Roedel
2019-07-18  9:04       ` Thomas Gleixner
2019-07-18  9:04         ` Thomas Gleixner
2019-07-18  9:25         ` Joerg Roedel
2019-07-19 14:01         ` Joerg Roedel
2019-07-19 21:10           ` Thomas Gleixner
2019-07-19 21:10             ` Thomas Gleixner
2019-07-17  7:14 ` [PATCH 3/3] mm/vmalloc: Sync unmappings in vunmap_page_range() Joerg Roedel
2019-07-17 21:24   ` Andy Lutomirski
2019-07-17 21:24     ` Andy Lutomirski
2019-07-18  9:17     ` Joerg Roedel
2019-07-18 19:04       ` Andy Lutomirski
2019-07-18 19:04         ` Andy Lutomirski
2019-07-19 12:21         ` Joerg Roedel [this message]
2019-07-19 12:24           ` Andy Lutomirski
2019-07-19 12:24             ` Andy Lutomirski
2019-07-19 13:00             ` Joerg Roedel
  -- strict thread matches above, loose matches on Subject: below --
2019-07-19 18:46 [PATCH 0/3 v3] Sync unmappings in vmalloc/ioremap areas Joerg Roedel
2019-07-19 18:46 ` [PATCH 3/3] mm/vmalloc: Sync unmappings in vunmap_page_range() Joerg Roedel
2019-07-22  8:11   ` Joerg Roedel
2019-07-22  8:19     ` Thomas Gleixner
2019-07-22  8:19       ` Thomas Gleixner
2019-07-22  8:29       ` Joerg Roedel
2019-07-15 11:02 [PATCH 0/3] Sync unmappings in vmalloc/ioremap areas Joerg Roedel
2019-07-15 11:02 ` [PATCH 3/3] mm/vmalloc: Sync unmappings in vunmap_page_range() Joerg Roedel

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.