All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Joerg Roedel <joro@8bytes.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 3/3] mm/vmalloc: Sync unmappings in vunmap_page_range()
Date: Mon, 22 Jul 2019 10:11:15 +0200	[thread overview]
Message-ID: <20190722081115.GH19068@suse.de> (raw)
In-Reply-To: <20190719184652.11391-4-joro@8bytes.org>

Srewed up the subject :(, it needs to be

	"mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()"

of course.

On Fri, Jul 19, 2019 at 08:46:52PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> On x86-32 with PTI enabled, parts of the kernel page-tables
> are not shared between processes. This can cause mappings in
> the vmalloc/ioremap area to persist in some page-tables
> after the region is unmapped and released.
> 
> When the region is re-used the processes with the old
> mappings do not fault in the new mappings but still access
> the old ones.
> 
> This causes undefined behavior, in reality often data
> corruption, kernel oopses and panics and even spontaneous
> reboots.
> 
> Fix this problem by activly syncing unmaps in the
> vmalloc/ioremap area to all page-tables in the system before
> the regions can be re-used.
> 
> References: https://bugzilla.suse.com/show_bug.cgi?id=1118689
> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
> Fixes: 5d72b4fba40ef ('x86, mm: support huge I/O mapping capability I/F')
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  mm/vmalloc.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 4fa8d84599b0..e0fc963acc41 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1258,6 +1258,12 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
>  	if (unlikely(valist == NULL))
>  		return false;
>  
> +	/*
> +	 * First make sure the mappings are removed from all page-tables
> +	 * before they are freed.
> +	 */
> +	vmalloc_sync_all();
> +
>  	/*
>  	 * TODO: to calculate a flush range without looping.
>  	 * The list can be up to lazy_max_pages() elements.
> @@ -3038,6 +3044,9 @@ EXPORT_SYMBOL(remap_vmalloc_range);
>  /*
>   * Implement a stub for vmalloc_sync_all() if the architecture chose not to
>   * have one.
> + *
> + * The purpose of this function is to make sure the vmalloc area
> + * mappings are identical in all page-tables in the system.
>   */
>  void __weak vmalloc_sync_all(void)
>  {
> -- 
> 2.17.1

  reply	other threads:[~2019-07-22  8:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 18:46 [PATCH 0/3 v3] Sync unmappings in vmalloc/ioremap areas Joerg Roedel
2019-07-19 18:46 ` [PATCH 1/3] x86/mm: Check for pfn instead of page in vmalloc_sync_one() Joerg Roedel
2019-07-22  8:22   ` [tip:x86/urgent] " tip-bot for Joerg Roedel
2019-07-19 18:46 ` [PATCH 2/3] x86/mm: Sync also unmappings in vmalloc_sync_all() Joerg Roedel
2019-07-22  8:22   ` [tip:x86/urgent] " tip-bot for 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 [this message]
2019-07-22  8:19     ` Thomas Gleixner
2019-07-22  8:19       ` Thomas Gleixner
2019-07-22  8:29       ` Joerg Roedel
2019-07-22  8:23   ` [tip:x86/urgent] mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy() tip-bot for Joerg Roedel
  -- strict thread matches above, loose matches on Subject: below --
2019-07-17  7:14 [PATCH 0/3 v2] Sync unmappings in vmalloc/ioremap areas Joerg Roedel
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
2019-07-19 12:24           ` Andy Lutomirski
2019-07-19 12:24             ` Andy Lutomirski
2019-07-19 13:00             ` 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:
  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=20190722081115.GH19068@suse.de \
    --to=jroedel@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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 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.