All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	linux-mm@kvack.org, Pavel Machek <pavel@ucw.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Airlie <airlied@redhat.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	David Vrabel <david.vrabel@citrix.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction
Date: Fri, 21 Aug 2020 11:51:29 +0200	[thread overview]
Message-ID: <20200821095129.GF3354@suse.de> (raw)
In-Reply-To: <20200821085011.28878-1-chris@chris-wilson.co.uk>

On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote:
> The alloc_vm_area() is another method for drivers to
> vmap/map_kernel_range that uses apply_to_page_range() rather than the
> direct vmalloc walkers. This is missing the page table modification
> tracking, and the ability to synchronize the PTE updates afterwards.
> Provide flush_vm_area() for the users of alloc_vm_area() that assumes
> the worst and ensures that the page directories are correctly flushed
> upon construction.
> 
> The impact is most pronounced on x86_32 due to the delayed set_pmd().
> 
> Reported-by: Pavel Machek <pavel@ucw.cz>
> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")
> References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Joerg Roedel <jroedel@suse.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: <stable@vger.kernel.org> # v5.8+
> ---
>  include/linux/vmalloc.h |  1 +
>  mm/vmalloc.c            | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 0221f852a7e1..a253b27df0ac 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr)
>  
>  /* Allocate/destroy a 'vmalloc' VM area. */
>  extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
> +extern void flush_vm_area(struct vm_struct *area);
>  extern void free_vm_area(struct vm_struct *area);
>  
>  /* for /dev/kmem */
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index b482d240f9a2..c41934486031 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
>  }
>  EXPORT_SYMBOL_GPL(alloc_vm_area);
>  
> +void flush_vm_area(struct vm_struct *area)
> +{
> +	unsigned long addr = (unsigned long)area->addr;
> +
> +	/* apply_to_page_range() doesn't track the damage, assume the worst */
> +	if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED |
> +					 PGTBL_PMD_MODIFIED |
> +					 PGTBL_PUD_MODIFIED |
> +					 PGTBL_P4D_MODIFIED |
> +					 PGTBL_PGD_MODIFIED))
> +		arch_sync_kernel_mappings(addr, addr + area->size);

This should happen in __apply_to_page_range() directly and look like
this:

	if (ARCH_PAGE_TABLE_SYNC_MASK && create)
		arch_sync_kernel_mappings(addr, addr + size);

Or even better, track whether something had to be allocated in the
__apply_to_page_range() path and check for:

	if (ARCH_PAGE_TABLE_SYNC_MASK & mask)


WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <jroedel@suse.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, linux-mm@kvack.org,
	David Vrabel <david.vrabel@citrix.com>,
	Pavel Machek <pavel@ucw.cz>, Dave Airlie <airlied@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction
Date: Fri, 21 Aug 2020 11:51:29 +0200	[thread overview]
Message-ID: <20200821095129.GF3354@suse.de> (raw)
In-Reply-To: <20200821085011.28878-1-chris@chris-wilson.co.uk>

On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote:
> The alloc_vm_area() is another method for drivers to
> vmap/map_kernel_range that uses apply_to_page_range() rather than the
> direct vmalloc walkers. This is missing the page table modification
> tracking, and the ability to synchronize the PTE updates afterwards.
> Provide flush_vm_area() for the users of alloc_vm_area() that assumes
> the worst and ensures that the page directories are correctly flushed
> upon construction.
> 
> The impact is most pronounced on x86_32 due to the delayed set_pmd().
> 
> Reported-by: Pavel Machek <pavel@ucw.cz>
> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")
> References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Joerg Roedel <jroedel@suse.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: <stable@vger.kernel.org> # v5.8+
> ---
>  include/linux/vmalloc.h |  1 +
>  mm/vmalloc.c            | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 0221f852a7e1..a253b27df0ac 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr)
>  
>  /* Allocate/destroy a 'vmalloc' VM area. */
>  extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
> +extern void flush_vm_area(struct vm_struct *area);
>  extern void free_vm_area(struct vm_struct *area);
>  
>  /* for /dev/kmem */
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index b482d240f9a2..c41934486031 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
>  }
>  EXPORT_SYMBOL_GPL(alloc_vm_area);
>  
> +void flush_vm_area(struct vm_struct *area)
> +{
> +	unsigned long addr = (unsigned long)area->addr;
> +
> +	/* apply_to_page_range() doesn't track the damage, assume the worst */
> +	if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED |
> +					 PGTBL_PMD_MODIFIED |
> +					 PGTBL_PUD_MODIFIED |
> +					 PGTBL_P4D_MODIFIED |
> +					 PGTBL_PGD_MODIFIED))
> +		arch_sync_kernel_mappings(addr, addr + area->size);

This should happen in __apply_to_page_range() directly and look like
this:

	if (ARCH_PAGE_TABLE_SYNC_MASK && create)
		arch_sync_kernel_mappings(addr, addr + size);

Or even better, track whether something had to be allocated in the
__apply_to_page_range() path and check for:

	if (ARCH_PAGE_TABLE_SYNC_MASK & mask)

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-08-21  9:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21  8:50 [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction Chris Wilson
2020-08-21  8:50 ` [Intel-gfx] " Chris Wilson
2020-08-21  8:50 ` [PATCH 2/4] drm/i915/gem: Sync the vmap " Chris Wilson
2020-08-21  8:50   ` [Intel-gfx] " Chris Wilson
2020-08-21 12:41   ` Linus Torvalds
2020-08-21 12:41     ` [Intel-gfx] " Linus Torvalds
2020-08-21 12:41     ` Linus Torvalds
2020-08-21 13:01     ` Chris Wilson
2020-08-21 13:01       ` [Intel-gfx] " Chris Wilson
2020-08-21  8:50 ` [PATCH 3/4] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE Chris Wilson
2020-08-21  8:50   ` [Intel-gfx] " Chris Wilson
2020-08-21  8:50 ` [PATCH 4/4] drm/i915/gem: Replace reloc chain with terminator on error unwind Chris Wilson
2020-08-21  8:50   ` [Intel-gfx] " Chris Wilson
2020-08-21  9:14 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction Patchwork
2020-08-21  9:16 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-08-21  9:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-08-21  9:51 ` Joerg Roedel [this message]
2020-08-21  9:51   ` [Intel-gfx] [PATCH 1/4] " Joerg Roedel
2020-08-21  9:54   ` Chris Wilson
2020-08-21  9:54     ` [Intel-gfx] " Chris Wilson
2020-08-21 10:22     ` Joerg Roedel
2020-08-21 10:22       ` [Intel-gfx] " Joerg Roedel
2020-08-21 10:36       ` Chris Wilson
2020-08-21 10:36         ` [Intel-gfx] " Chris Wilson
2020-08-21 10:09 ` [PATCH] mm: Track page table modifications in __apply_to_page_range() construction Joerg Roedel
2020-08-21 10:09   ` [Intel-gfx] " Joerg Roedel
2020-08-21 10:13   ` Chris Wilson
2020-08-21 10:13     ` [Intel-gfx] " Chris Wilson
2020-08-21 10:23     ` Joerg Roedel
2020-08-21 10:23       ` [Intel-gfx] " Joerg Roedel
2020-08-21 10:39       ` Chris Wilson
2020-08-21 10:39         ` [Intel-gfx] " Chris Wilson
2020-08-21 11:38         ` Chris Wilson
2020-08-21 11:38           ` [Intel-gfx] " Chris Wilson
2020-08-21 12:18           ` Joerg Roedel
2020-08-21 12:18             ` [Intel-gfx] " Joerg Roedel
2020-08-21 10:53   ` Greg KH
2020-08-21 10:53     ` [Intel-gfx] " Greg KH
2020-08-21 10:27 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with mm: Track page table modifications in __apply_to_page_range() construction (rev2) Patchwork
2020-08-21 11:33 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction Patchwork

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=20200821095129.GF3354@suse.de \
    --to=jroedel@suse.de \
    --cc=airlied@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=david.vrabel@citrix.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pavel@ucw.cz \
    --cc=rodrigo.vivi@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.