All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 20:07 ` Rick Edgecombe
  0 siblings, 0 replies; 30+ messages in thread
From: Rick Edgecombe @ 2019-05-20 20:07 UTC (permalink / raw)
  To: linux-kernel, peterz, sparclinux, linux-mm, netdev
  Cc: dave.hansen, namit, Rick Edgecombe, Meelis Roos, David S. Miller,
	Borislav Petkov, Andy Lutomirski, Ingo Molnar

Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
vm_unmap_aliases() and fix calculation of the direct map for the
CONFIG_ARCH_HAS_SET_DIRECT_MAP case.

Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
sparc machine. On investigation some issues were noticed:

1. The calculation of the direct map address range to flush was wrong.
This could cause problems on x86 if a RO direct map alias ever got loaded
into the TLB. This shouldn't normally happen, but it could cause the
permissions to remain RO on the direct map alias, and then the page
would return from the page allocator to some other component as RO and
cause a crash.

2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
do on a free operation. Simply flushing the TLB instead of the whole
vm_unmap_alias() operation makes the frees faster and pushes the heavy
work to happen on allocation where it would be more expected.
In addition to the extra work, vm_unmap_alias() takes some locks including
a long hold of vmap_purge_lock, which will make all other
VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.

3. page_address() can have locking on some configurations, so skip calling
this when possible to further speed this up.

Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
Reported-by: Meelis Roos <mroos@linux.ee>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Nadav Amit <namit@vmware.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---

Changes since v1:
 - Update commit message with more detail
 - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case

 mm/vmalloc.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c42872ed82ac..8d03427626dc 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2122,9 +2122,10 @@ static inline void set_area_direct_map(const struct vm_struct *area,
 /* Handle removing and resetting vm mappings related to the vm_struct. */
 static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 {
+	const bool has_set_direct = IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP);
+	const bool flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
 	unsigned long addr = (unsigned long)area->addr;
-	unsigned long start = ULONG_MAX, end = 0;
-	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
+	unsigned long start = addr, end = addr + area->size;
 	int i;
 
 	/*
@@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 	 * This is concerned with resetting the direct map any an vm alias with
 	 * execute permissions, without leaving a RW+X window.
 	 */
-	if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
+	if (flush_reset && !has_set_direct) {
 		set_memory_nx(addr, area->nr_pages);
 		set_memory_rw(addr, area->nr_pages);
 	}
@@ -2146,22 +2147,24 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 
 	/*
 	 * If not deallocating pages, just do the flush of the VM area and
-	 * return.
+	 * return. If the arch doesn't have set_direct_map_(), also skip the
+	 * below work.
 	 */
-	if (!deallocate_pages) {
-		vm_unmap_aliases();
+	if (!deallocate_pages || !has_set_direct) {
+		flush_tlb_kernel_range(start, end);
 		return;
 	}
 
 	/*
 	 * If execution gets here, flush the vm mapping and reset the direct
 	 * map. Find the start and end range of the direct mappings to make sure
-	 * the vm_unmap_aliases() flush includes the direct map.
+	 * the flush_tlb_kernel_range() includes the direct map.
 	 */
 	for (i = 0; i < area->nr_pages; i++) {
-		if (page_address(area->pages[i])) {
+		addr = (unsigned long)page_address(area->pages[i]);
+		if (addr) {
 			start = min(addr, start);
-			end = max(addr, end);
+			end = max(addr + PAGE_SIZE, end);
 		}
 	}
 
@@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 	 * reset the direct map permissions to the default.
 	 */
 	set_area_direct_map(area, set_direct_map_invalid_noflush);
-	_vm_unmap_aliases(start, end, 1);
+	flush_tlb_kernel_range(start, end);
 	set_area_direct_map(area, set_direct_map_default_noflush);
 }
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 30+ messages in thread

* [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 20:07 ` Rick Edgecombe
  0 siblings, 0 replies; 30+ messages in thread
From: Rick Edgecombe @ 2019-05-20 20:07 UTC (permalink / raw)
  To: linux-kernel, peterz, sparclinux, linux-mm, netdev
  Cc: dave.hansen, namit, Rick Edgecombe, Meelis Roos, David S. Miller,
	Borislav Petkov, Andy Lutomirski, Ingo Molnar

Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
vm_unmap_aliases() and fix calculation of the direct map for the
CONFIG_ARCH_HAS_SET_DIRECT_MAP case.

Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
sparc machine. On investigation some issues were noticed:

1. The calculation of the direct map address range to flush was wrong.
This could cause problems on x86 if a RO direct map alias ever got loaded
into the TLB. This shouldn't normally happen, but it could cause the
permissions to remain RO on the direct map alias, and then the page
would return from the page allocator to some other component as RO and
cause a crash.

2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
do on a free operation. Simply flushing the TLB instead of the whole
vm_unmap_alias() operation makes the frees faster and pushes the heavy
work to happen on allocation where it would be more expected.
In addition to the extra work, vm_unmap_alias() takes some locks including
a long hold of vmap_purge_lock, which will make all other
VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.

3. page_address() can have locking on some configurations, so skip calling
this when possible to further speed this up.

Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
Reported-by: Meelis Roos <mroos@linux.ee>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Nadav Amit <namit@vmware.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---

Changes since v1:
 - Update commit message with more detail
 - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case

 mm/vmalloc.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c42872ed82ac..8d03427626dc 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2122,9 +2122,10 @@ static inline void set_area_direct_map(const struct vm_struct *area,
 /* Handle removing and resetting vm mappings related to the vm_struct. */
 static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 {
+	const bool has_set_direct = IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP);
+	const bool flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
 	unsigned long addr = (unsigned long)area->addr;
-	unsigned long start = ULONG_MAX, end = 0;
-	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
+	unsigned long start = addr, end = addr + area->size;
 	int i;
 
 	/*
@@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 	 * This is concerned with resetting the direct map any an vm alias with
 	 * execute permissions, without leaving a RW+X window.
 	 */
-	if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
+	if (flush_reset && !has_set_direct) {
 		set_memory_nx(addr, area->nr_pages);
 		set_memory_rw(addr, area->nr_pages);
 	}
@@ -2146,22 +2147,24 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 
 	/*
 	 * If not deallocating pages, just do the flush of the VM area and
-	 * return.
+	 * return. If the arch doesn't have set_direct_map_(), also skip the
+	 * below work.
 	 */
-	if (!deallocate_pages) {
-		vm_unmap_aliases();
+	if (!deallocate_pages || !has_set_direct) {
+		flush_tlb_kernel_range(start, end);
 		return;
 	}
 
 	/*
 	 * If execution gets here, flush the vm mapping and reset the direct
 	 * map. Find the start and end range of the direct mappings to make sure
-	 * the vm_unmap_aliases() flush includes the direct map.
+	 * the flush_tlb_kernel_range() includes the direct map.
 	 */
 	for (i = 0; i < area->nr_pages; i++) {
-		if (page_address(area->pages[i])) {
+		addr = (unsigned long)page_address(area->pages[i]);
+		if (addr) {
 			start = min(addr, start);
-			end = max(addr, end);
+			end = max(addr + PAGE_SIZE, end);
 		}
 	}
 
@@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 	 * reset the direct map permissions to the default.
 	 */
 	set_area_direct_map(area, set_direct_map_invalid_noflush);
-	_vm_unmap_aliases(start, end, 1);
+	flush_tlb_kernel_range(start, end);
 	set_area_direct_map(area, set_direct_map_default_noflush);
 }
 
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-20 20:07 ` Rick Edgecombe
@ 2019-05-20 21:25   ` Andy Lutomirski
  -1 siblings, 0 replies; 30+ messages in thread
From: Andy Lutomirski @ 2019-05-20 21:25 UTC (permalink / raw)
  To: Rick Edgecombe
  Cc: linux-kernel, peterz, sparclinux, linux-mm, netdev, dave.hansen,
	namit, Meelis Roos, David S. Miller, Borislav Petkov,
	Andy Lutomirski, Ingo Molnar




> On May 20, 2019, at 1:07 PM, Rick Edgecombe <rick.p.edgecombe@intel.com> wrote:
> 
> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> 
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
> sparc machine. On investigation some issues were noticed:
> 

Can you split this into a few (3?) patches, each fixing one issue?

> 1. The calculation of the direct map address range to flush was wrong.
> This could cause problems on x86 if a RO direct map alias ever got loaded
> into the TLB. This shouldn't normally happen, but it could cause the
> permissions to remain RO on the direct map alias, and then the page
> would return from the page allocator to some other component as RO and
> cause a crash.
> 
> 2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
> do on a free operation. Simply flushing the TLB instead of the whole
> vm_unmap_alias() operation makes the frees faster and pushes the heavy
> work to happen on allocation where it would be more expected.
> In addition to the extra work, vm_unmap_alias() takes some locks including
> a long hold of vmap_purge_lock, which will make all other
> VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> 
> 3. page_address() can have locking on some configurations, so skip calling
> this when possible to further speed this up.
> 
> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
> Reported-by: Meelis Roos <mroos@linux.ee>
> Cc: Meelis Roos <mroos@linux.ee>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Nadav Amit <namit@vmware.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> ---
> 
> Changes since v1:
> - Update commit message with more detail
> - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case
> 
> mm/vmalloc.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index c42872ed82ac..8d03427626dc 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2122,9 +2122,10 @@ static inline void set_area_direct_map(const struct vm_struct *area,
> /* Handle removing and resetting vm mappings related to the vm_struct. */
> static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> {
> +    const bool has_set_direct = IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP);
> +    const bool flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
>    unsigned long addr = (unsigned long)area->addr;
> -    unsigned long start = ULONG_MAX, end = 0;
> -    int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
> +    unsigned long start = addr, end = addr + area->size;
>    int i;
> 
>    /*
> @@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
>     * This is concerned with resetting the direct map any an vm alias with
>     * execute permissions, without leaving a RW+X window.
>     */
> -    if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> +    if (flush_reset && !has_set_direct) {
>        set_memory_nx(addr, area->nr_pages);
>        set_memory_rw(addr, area->nr_pages);
>    }
> @@ -2146,22 +2147,24 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> 
>    /*
>     * If not deallocating pages, just do the flush of the VM area and
> -     * return.
> +     * return. If the arch doesn't have set_direct_map_(), also skip the
> +     * below work.
>     */
> -    if (!deallocate_pages) {
> -        vm_unmap_aliases();
> +    if (!deallocate_pages || !has_set_direct) {
> +        flush_tlb_kernel_range(start, end);
>        return;
>    }
> 
>    /*
>     * If execution gets here, flush the vm mapping and reset the direct
>     * map. Find the start and end range of the direct mappings to make sure
> -     * the vm_unmap_aliases() flush includes the direct map.
> +     * the flush_tlb_kernel_range() includes the direct map.
>     */
>    for (i = 0; i < area->nr_pages; i++) {
> -        if (page_address(area->pages[i])) {
> +        addr = (unsigned long)page_address(area->pages[i]);
> +        if (addr) {
>            start = min(addr, start);
> -            end = max(addr, end);
> +            end = max(addr + PAGE_SIZE, end);
>        }
>    }
> 
> @@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
>     * reset the direct map permissions to the default.
>     */
>    set_area_direct_map(area, set_direct_map_invalid_noflush);
> -    _vm_unmap_aliases(start, end, 1);
> +    flush_tlb_kernel_range(start, end);
>    set_area_direct_map(area, set_direct_map_default_noflush);
> }
> 
> -- 
> 2.20.1
> 

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 21:25   ` Andy Lutomirski
  0 siblings, 0 replies; 30+ messages in thread
From: Andy Lutomirski @ 2019-05-20 21:25 UTC (permalink / raw)
  To: Rick Edgecombe
  Cc: linux-kernel, peterz, sparclinux, linux-mm, netdev, dave.hansen,
	namit, Meelis Roos, David S. Miller, Borislav Petkov,
	Andy Lutomirski, Ingo Molnar




> On May 20, 2019, at 1:07 PM, Rick Edgecombe <rick.p.edgecombe@intel.com> wrote:
> 
> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> 
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
> sparc machine. On investigation some issues were noticed:
> 

Can you split this into a few (3?) patches, each fixing one issue?

> 1. The calculation of the direct map address range to flush was wrong.
> This could cause problems on x86 if a RO direct map alias ever got loaded
> into the TLB. This shouldn't normally happen, but it could cause the
> permissions to remain RO on the direct map alias, and then the page
> would return from the page allocator to some other component as RO and
> cause a crash.
> 
> 2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
> do on a free operation. Simply flushing the TLB instead of the whole
> vm_unmap_alias() operation makes the frees faster and pushes the heavy
> work to happen on allocation where it would be more expected.
> In addition to the extra work, vm_unmap_alias() takes some locks including
> a long hold of vmap_purge_lock, which will make all other
> VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> 
> 3. page_address() can have locking on some configurations, so skip calling
> this when possible to further speed this up.
> 
> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
> Reported-by: Meelis Roos <mroos@linux.ee>
> Cc: Meelis Roos <mroos@linux.ee>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Nadav Amit <namit@vmware.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> ---
> 
> Changes since v1:
> - Update commit message with more detail
> - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case
> 
> mm/vmalloc.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index c42872ed82ac..8d03427626dc 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2122,9 +2122,10 @@ static inline void set_area_direct_map(const struct vm_struct *area,
> /* Handle removing and resetting vm mappings related to the vm_struct. */
> static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> {
> +    const bool has_set_direct = IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP);
> +    const bool flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
>    unsigned long addr = (unsigned long)area->addr;
> -    unsigned long start = ULONG_MAX, end = 0;
> -    int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
> +    unsigned long start = addr, end = addr + area->size;
>    int i;
> 
>    /*
> @@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
>     * This is concerned with resetting the direct map any an vm alias with
>     * execute permissions, without leaving a RW+X window.
>     */
> -    if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> +    if (flush_reset && !has_set_direct) {
>        set_memory_nx(addr, area->nr_pages);
>        set_memory_rw(addr, area->nr_pages);
>    }
> @@ -2146,22 +2147,24 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> 
>    /*
>     * If not deallocating pages, just do the flush of the VM area and
> -     * return.
> +     * return. If the arch doesn't have set_direct_map_(), also skip the
> +     * below work.
>     */
> -    if (!deallocate_pages) {
> -        vm_unmap_aliases();
> +    if (!deallocate_pages || !has_set_direct) {
> +        flush_tlb_kernel_range(start, end);
>        return;
>    }
> 
>    /*
>     * If execution gets here, flush the vm mapping and reset the direct
>     * map. Find the start and end range of the direct mappings to make sure
> -     * the vm_unmap_aliases() flush includes the direct map.
> +     * the flush_tlb_kernel_range() includes the direct map.
>     */
>    for (i = 0; i < area->nr_pages; i++) {
> -        if (page_address(area->pages[i])) {
> +        addr = (unsigned long)page_address(area->pages[i]);
> +        if (addr) {
>            start = min(addr, start);
> -            end = max(addr, end);
> +            end = max(addr + PAGE_SIZE, end);
>        }
>    }
> 
> @@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
>     * reset the direct map permissions to the default.
>     */
>    set_area_direct_map(area, set_direct_map_invalid_noflush);
> -    _vm_unmap_aliases(start, end, 1);
> +    flush_tlb_kernel_range(start, end);
>    set_area_direct_map(area, set_direct_map_default_noflush);
> }
> 
> -- 
> 2.20.1
> 

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-20 20:07 ` Rick Edgecombe
@ 2019-05-20 21:36   ` Meelis Roos
  -1 siblings, 0 replies; 30+ messages in thread
From: Meelis Roos @ 2019-05-20 21:36 UTC (permalink / raw)
  To: Rick Edgecombe, linux-kernel, peterz, sparclinux, linux-mm, netdev
  Cc: dave.hansen, namit, Meelis Roos, David S. Miller,
	Borislav Petkov, Andy Lutomirski, Ingo Molnar

> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> 
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
> sparc machine. On investigation some issues were noticed:
> 
> 1. The calculation of the direct map address range to flush was wrong.
> This could cause problems on x86 if a RO direct map alias ever got loaded
> into the TLB. This shouldn't normally happen, but it could cause the
> permissions to remain RO on the direct map alias, and then the page
> would return from the page allocator to some other component as RO and
> cause a crash.
> 
> 2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
> do on a free operation. Simply flushing the TLB instead of the whole
> vm_unmap_alias() operation makes the frees faster and pushes the heavy
> work to happen on allocation where it would be more expected.
> In addition to the extra work, vm_unmap_alias() takes some locks including
> a long hold of vmap_purge_lock, which will make all other
> VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> 
> 3. page_address() can have locking on some configurations, so skip calling
> this when possible to further speed this up.
> 
> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
> Reported-by: Meelis Roos<mroos@linux.ee>
> Cc: Meelis Roos<mroos@linux.ee>
> Cc: Peter Zijlstra<peterz@infradead.org>
> Cc: "David S. Miller"<davem@davemloft.net>
> Cc: Dave Hansen<dave.hansen@intel.com>
> Cc: Borislav Petkov<bp@alien8.de>
> Cc: Andy Lutomirski<luto@kernel.org>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: Nadav Amit<namit@vmware.com>
> Signed-off-by: Rick Edgecombe<rick.p.edgecombe@intel.com>
> ---
> 
> Changes since v1:
>   - Update commit message with more detail
>   - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case

It does not work on my V445 where the initial problem happened.

[   46.582633] systemd[1]: Detected architecture sparc64.

Welcome to Debian GNU/Linux 10 (buster)!

[   46.759048] systemd[1]: Set hostname to <v445>.
[   46.831383] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[   67.989695] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[   68.074706] rcu:     0-...!: (0 ticks this GP) idle=5c6/1/0x4000000000000000 softirq=33/33 fqs=0
[   68.198443] rcu:     2-...!: (0 ticks this GP) idle=e7e/1/0x4000000000000000 softirq=67/67 fqs=0
[   68.322198]  (detected by 1, t=5252 jiffies, g=-939, q=108)
[   68.402204]   CPU[  0]: TSTATE[0000000080001603] TPC[000000000043f298] TNPC[000000000043f29c] TASK[systemd-debug-g:89]
[   68.556001]              TPC[smp_synchronize_tick_client+0x18/0x1a0] O7[0xfff000010000691c] I7[xcall_sync_tick+0x1c/0x2c] RPC[alloc_set_pte+0xf4/0x300]
[   68.750973]   CPU[  2]: TSTATE[0000000080001600] TPC[000000000043f298] TNPC[000000000043f29c] TASK[systemd-cryptse:88]
[   68.904741]              TPC[smp_synchronize_tick_client+0x18/0x1a0] O7[filemap_map_pages+0x3cc/0x3e0] I7[xcall_sync_tick+0x1c/0x2c] RPC[handle_mm_fault+0xa0/0x180]
[   69.115991] rcu: rcu_sched kthread starved for 5252 jiffies! g-939 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3
[   69.262239] rcu: RCU grace-period kthread stack dump:
[   69.334741] rcu_sched       I    0    10      2 0x06000000
[   69.413495] Call Trace:
[   69.448501]  [000000000093325c] schedule+0x1c/0xc0
[   69.517253]  [0000000000936c74] schedule_timeout+0x154/0x260
[   69.598514]  [00000000004b65a4] rcu_gp_kthread+0x4e4/0xac0
[   69.677261]  [000000000047ecfc] kthread+0xfc/0x120
[   69.746018]  [00000000004060a4] ret_from_fork+0x1c/0x2c
[   69.821014]  [0000000000000000] 0x0

and hangs here, software watchdog kicks in soon.

-- 
Meelis Roos

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 21:36   ` Meelis Roos
  0 siblings, 0 replies; 30+ messages in thread
From: Meelis Roos @ 2019-05-20 21:36 UTC (permalink / raw)
  To: Rick Edgecombe, linux-kernel, peterz, sparclinux, linux-mm, netdev
  Cc: dave.hansen, namit, Meelis Roos, David S. Miller,
	Borislav Petkov, Andy Lutomirski, Ingo Molnar

> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> 
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
> sparc machine. On investigation some issues were noticed:
> 
> 1. The calculation of the direct map address range to flush was wrong.
> This could cause problems on x86 if a RO direct map alias ever got loaded
> into the TLB. This shouldn't normally happen, but it could cause the
> permissions to remain RO on the direct map alias, and then the page
> would return from the page allocator to some other component as RO and
> cause a crash.
> 
> 2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to
> do on a free operation. Simply flushing the TLB instead of the whole
> vm_unmap_alias() operation makes the frees faster and pushes the heavy
> work to happen on allocation where it would be more expected.
> In addition to the extra work, vm_unmap_alias() takes some locks including
> a long hold of vmap_purge_lock, which will make all other
> VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> 
> 3. page_address() can have locking on some configurations, so skip calling
> this when possible to further speed this up.
> 
> Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")
> Reported-by: Meelis Roos<mroos@linux.ee>
> Cc: Meelis Roos<mroos@linux.ee>
> Cc: Peter Zijlstra<peterz@infradead.org>
> Cc: "David S. Miller"<davem@davemloft.net>
> Cc: Dave Hansen<dave.hansen@intel.com>
> Cc: Borislav Petkov<bp@alien8.de>
> Cc: Andy Lutomirski<luto@kernel.org>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: Nadav Amit<namit@vmware.com>
> Signed-off-by: Rick Edgecombe<rick.p.edgecombe@intel.com>
> ---
> 
> Changes since v1:
>   - Update commit message with more detail
>   - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case

It does not work on my V445 where the initial problem happened.

[   46.582633] systemd[1]: Detected architecture sparc64.

Welcome to Debian GNU/Linux 10 (buster)!

[   46.759048] systemd[1]: Set hostname to <v445>.
[   46.831383] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[   67.989695] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[   68.074706] rcu:     0-...!: (0 ticks this GP) idle\6/1/0x4000000000000000 softirq3/33 fqs=0
[   68.198443] rcu:     2-...!: (0 ticks this GP) idleçe/1/0x4000000000000000 softirqg/67 fqs=0
[   68.322198]  (detected by 1, tR52 jiffies, g=-939, q\x108)
[   68.402204]   CPU[  0]: TSTATE[0000000080001603] TPC[000000000043f298] TNPC[000000000043f29c] TASK[systemd-debug-g:89]
[   68.556001]              TPC[smp_synchronize_tick_client+0x18/0x1a0] O7[0xfff000010000691c] I7[xcall_sync_tick+0x1c/0x2c] RPC[alloc_set_pte+0xf4/0x300]
[   68.750973]   CPU[  2]: TSTATE[0000000080001600] TPC[000000000043f298] TNPC[000000000043f29c] TASK[systemd-cryptse:88]
[   68.904741]              TPC[smp_synchronize_tick_client+0x18/0x1a0] O7[filemap_map_pages+0x3cc/0x3e0] I7[xcall_sync_tick+0x1c/0x2c] RPC[handle_mm_fault+0xa0/0x180]
[   69.115991] rcu: rcu_sched kthread starved for 5252 jiffies! g-939 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3
[   69.262239] rcu: RCU grace-period kthread stack dump:
[   69.334741] rcu_sched       I    0    10      2 0x06000000
[   69.413495] Call Trace:
[   69.448501]  [000000000093325c] schedule+0x1c/0xc0
[   69.517253]  [0000000000936c74] schedule_timeout+0x154/0x260
[   69.598514]  [00000000004b65a4] rcu_gp_kthread+0x4e4/0xac0
[   69.677261]  [000000000047ecfc] kthread+0xfc/0x120
[   69.746018]  [00000000004060a4] ret_from_fork+0x1c/0x2c
[   69.821014]  [0000000000000000] 0x0

and hangs here, software watchdog kicks in soon.

-- 
Meelis Roos

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-20 21:25   ` Andy Lutomirski
@ 2019-05-20 21:48     ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-20 21:48 UTC (permalink / raw)
  To: luto
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto,
	netdev, Hansen, Dave, bp, davem, sparclinux

On Mon, 2019-05-20 at 14:25 -0700, Andy Lutomirski wrote:
> 
> 
> > On May 20, 2019, at 1:07 PM, Rick Edgecombe <
> > rick.p.edgecombe@intel.com> wrote:
> > 
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
> > CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> > 
> > Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag
> > on a
> > sparc machine. On investigation some issues were noticed:
> > 
> 
> Can you split this into a few (3?) patches, each fixing one issue?
Sure, I just did one because because it was all in the same function
and the address range calculation needs to be done differently for pure
TLB flush, so its kind of intertwined.

> > 1. The calculation of the direct map address range to flush was
> > wrong.
> > This could cause problems on x86 if a RO direct map alias ever got
> > loaded
> > into the TLB. This shouldn't normally happen, but it could cause
> > the
> > permissions to remain RO on the direct map alias, and then the page
> > would return from the page allocator to some other component as RO
> > and
> > cause a crash.
> > 
> > 2. Calling vm_unmap_alias() on vfree could potentially be a lot of
> > work to
> > do on a free operation. Simply flushing the TLB instead of the
> > whole
> > vm_unmap_alias() operation makes the frees faster and pushes the
> > heavy
> > work to happen on allocation where it would be more expected.
> > In addition to the extra work, vm_unmap_alias() takes some locks
> > including
> > a long hold of vmap_purge_lock, which will make all other
> > VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> > 
> > 3. page_address() can have locking on some configurations, so skip
> > calling
> > this when possible to further speed this up.
> > 
> > Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special
> > permsissions")
> > Reported-by: Meelis Roos <mroos@linux.ee>
> > Cc: Meelis Roos <mroos@linux.ee>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Dave Hansen <dave.hansen@intel.com>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Nadav Amit <namit@vmware.com>
> > Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > ---
> > 
> > Changes since v1:
> > - Update commit message with more detail
> > - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case
> > 
> > mm/vmalloc.c | 23 +++++++++++++----------
> > 1 file changed, 13 insertions(+), 10 deletions(-)
> > 
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index c42872ed82ac..8d03427626dc 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2122,9 +2122,10 @@ static inline void set_area_direct_map(const
> > struct vm_struct *area,
> > /* Handle removing and resetting vm mappings related to the
> > vm_struct. */
> > static void vm_remove_mappings(struct vm_struct *area, int
> > deallocate_pages)
> > {
> > +    const bool has_set_direct =
> > IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP);
> > +    const bool flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
> >    unsigned long addr = (unsigned long)area->addr;
> > -    unsigned long start = ULONG_MAX, end = 0;
> > -    int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
> > +    unsigned long start = addr, end = addr + area->size;
> >    int i;
> > 
> >    /*
> > @@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct
> > vm_struct *area, int deallocate_pages)
> >     * This is concerned with resetting the direct map any an vm
> > alias with
> >     * execute permissions, without leaving a RW+X window.
> >     */
> > -    if (flush_reset &&
> > !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> > +    if (flush_reset && !has_set_direct) {
> >        set_memory_nx(addr, area->nr_pages);
> >        set_memory_rw(addr, area->nr_pages);
> >    }
> > @@ -2146,22 +2147,24 @@ static void vm_remove_mappings(struct
> > vm_struct *area, int deallocate_pages)
> > 
> >    /*
> >     * If not deallocating pages, just do the flush of the VM area
> > and
> > -     * return.
> > +     * return. If the arch doesn't have set_direct_map_(), also
> > skip the
> > +     * below work.
> >     */
> > -    if (!deallocate_pages) {
> > -        vm_unmap_aliases();
> > +    if (!deallocate_pages || !has_set_direct) {
> > +        flush_tlb_kernel_range(start, end);
> >        return;
> >    }
> > 
> >    /*
> >     * If execution gets here, flush the vm mapping and reset the
> > direct
> >     * map. Find the start and end range of the direct mappings to
> > make sure
> > -     * the vm_unmap_aliases() flush includes the direct map.
> > +     * the flush_tlb_kernel_range() includes the direct map.
> >     */
> >    for (i = 0; i < area->nr_pages; i++) {
> > -        if (page_address(area->pages[i])) {
> > +        addr = (unsigned long)page_address(area->pages[i]);
> > +        if (addr) {
> >            start = min(addr, start);
> > -            end = max(addr, end);
> > +            end = max(addr + PAGE_SIZE, end);
> >        }
> >    }
> > 
> > @@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct
> > vm_struct *area, int deallocate_pages)
> >     * reset the direct map permissions to the default.
> >     */
> >    set_area_direct_map(area, set_direct_map_invalid_noflush);
> > -    _vm_unmap_aliases(start, end, 1);
> > +    flush_tlb_kernel_range(start, end);
> >    set_area_direct_map(area, set_direct_map_default_noflush);
> > }
> > 
> > -- 
> > 2.20.1
> > 

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 21:48     ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-20 21:48 UTC (permalink / raw)
  To: luto
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto,
	netdev, Hansen, Dave, bp, davem, sparclinux

T24gTW9uLCAyMDE5LTA1LTIwIGF0IDE0OjI1IC0wNzAwLCBBbmR5IEx1dG9taXJza2kgd3JvdGU6
DQo+IA0KPiANCj4gPiBPbiBNYXkgMjAsIDIwMTksIGF0IDE6MDcgUE0sIFJpY2sgRWRnZWNvbWJl
IDwNCj4gPiByaWNrLnAuZWRnZWNvbWJlQGludGVsLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4gU3dp
dGNoIFZNX0ZMVVNIX1JFU0VUX1BFUk1TIHRvIHVzZSBhIHJlZ3VsYXIgVExCIGZsdXNoIGludGVh
ZCBvZg0KPiA+IHZtX3VubWFwX2FsaWFzZXMoKSBhbmQgZml4IGNhbGN1bGF0aW9uIG9mIHRoZSBk
aXJlY3QgbWFwIGZvciB0aGUNCj4gPiBDT05GSUdfQVJDSF9IQVNfU0VUX0RJUkVDVF9NQVAgY2Fz
ZS4NCj4gPiANCj4gPiBNZWVsaXMgUm9vcyByZXBvcnRlZCBpc3N1ZXMgd2l0aCB0aGUgbmV3IFZN
X0ZMVVNIX1JFU0VUX1BFUk1TIGZsYWcNCj4gPiBvbiBhDQo+ID4gc3BhcmMgbWFjaGluZS4gT24g
aW52ZXN0aWdhdGlvbiBzb21lIGlzc3VlcyB3ZXJlIG5vdGljZWQ6DQo+ID4gDQo+IA0KPiBDYW4g
eW91IHNwbGl0IHRoaXMgaW50byBhIGZldyAoMz8pIHBhdGNoZXMsIGVhY2ggZml4aW5nIG9uZSBp
c3N1ZT8NClN1cmUsIEkganVzdCBkaWQgb25lIGJlY2F1c2UgYmVjYXVzZSBpdCB3YXMgYWxsIGlu
IHRoZSBzYW1lIGZ1bmN0aW9uDQphbmQgdGhlIGFkZHJlc3MgcmFuZ2UgY2FsY3VsYXRpb24gbmVl
ZHMgdG8gYmUgZG9uZSBkaWZmZXJlbnRseSBmb3IgcHVyZQ0KVExCIGZsdXNoLCBzbyBpdHMga2lu
ZCBvZiBpbnRlcnR3aW5lZC4NCg0KPiA+IDEuIFRoZSBjYWxjdWxhdGlvbiBvZiB0aGUgZGlyZWN0
IG1hcCBhZGRyZXNzIHJhbmdlIHRvIGZsdXNoIHdhcw0KPiA+IHdyb25nLg0KPiA+IFRoaXMgY291
bGQgY2F1c2UgcHJvYmxlbXMgb24geDg2IGlmIGEgUk8gZGlyZWN0IG1hcCBhbGlhcyBldmVyIGdv
dA0KPiA+IGxvYWRlZA0KPiA+IGludG8gdGhlIFRMQi4gVGhpcyBzaG91bGRuJ3Qgbm9ybWFsbHkg
aGFwcGVuLCBidXQgaXQgY291bGQgY2F1c2UNCj4gPiB0aGUNCj4gPiBwZXJtaXNzaW9ucyB0byBy
ZW1haW4gUk8gb24gdGhlIGRpcmVjdCBtYXAgYWxpYXMsIGFuZCB0aGVuIHRoZSBwYWdlDQo+ID4g
d291bGQgcmV0dXJuIGZyb20gdGhlIHBhZ2UgYWxsb2NhdG9yIHRvIHNvbWUgb3RoZXIgY29tcG9u
ZW50IGFzIFJPDQo+ID4gYW5kDQo+ID4gY2F1c2UgYSBjcmFzaC4NCj4gPiANCj4gPiAyLiBDYWxs
aW5nIHZtX3VubWFwX2FsaWFzKCkgb24gdmZyZWUgY291bGQgcG90ZW50aWFsbHkgYmUgYSBsb3Qg
b2YNCj4gPiB3b3JrIHRvDQo+ID4gZG8gb24gYSBmcmVlIG9wZXJhdGlvbi4gU2ltcGx5IGZsdXNo
aW5nIHRoZSBUTEIgaW5zdGVhZCBvZiB0aGUNCj4gPiB3aG9sZQ0KPiA+IHZtX3VubWFwX2FsaWFz
KCkgb3BlcmF0aW9uIG1ha2VzIHRoZSBmcmVlcyBmYXN0ZXIgYW5kIHB1c2hlcyB0aGUNCj4gPiBo
ZWF2eQ0KPiA+IHdvcmsgdG8gaGFwcGVuIG9uIGFsbG9jYXRpb24gd2hlcmUgaXQgd291bGQgYmUg
bW9yZSBleHBlY3RlZC4NCj4gPiBJbiBhZGRpdGlvbiB0byB0aGUgZXh0cmEgd29yaywgdm1fdW5t
YXBfYWxpYXMoKSB0YWtlcyBzb21lIGxvY2tzDQo+ID4gaW5jbHVkaW5nDQo+ID4gYSBsb25nIGhv
bGQgb2Ygdm1hcF9wdXJnZV9sb2NrLCB3aGljaCB3aWxsIG1ha2UgYWxsIG90aGVyDQo+ID4gVk1f
RkxVU0hfUkVTRVRfUEVSTVMgdmZyZWVzIHdhaXQgd2hpbGUgdGhlIHB1cmdlIG9wZXJhdGlvbiBo
YXBwZW5zLg0KPiA+IA0KPiA+IDMuIHBhZ2VfYWRkcmVzcygpIGNhbiBoYXZlIGxvY2tpbmcgb24g
c29tZSBjb25maWd1cmF0aW9ucywgc28gc2tpcA0KPiA+IGNhbGxpbmcNCj4gPiB0aGlzIHdoZW4g
cG9zc2libGUgdG8gZnVydGhlciBzcGVlZCB0aGlzIHVwLg0KPiA+IA0KPiA+IEZpeGVzOiA4Njhi
MTA0ZDczNzkgKCJtbS92bWFsbG9jOiBBZGQgZmxhZyBmb3IgZnJlZWluZyBvZiBzcGVjaWFsDQo+
ID4gcGVybXNpc3Npb25zIikNCj4gPiBSZXBvcnRlZC1ieTogTWVlbGlzIFJvb3MgPG1yb29zQGxp
bnV4LmVlPg0KPiA+IENjOiBNZWVsaXMgUm9vcyA8bXJvb3NAbGludXguZWU+DQo+ID4gQ2M6IFBl
dGVyIFppamxzdHJhIDxwZXRlcnpAaW5mcmFkZWFkLm9yZz4NCj4gPiBDYzogIkRhdmlkIFMuIE1p
bGxlciIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+DQo+ID4gQ2M6IERhdmUgSGFuc2VuIDxkYXZlLmhh
bnNlbkBpbnRlbC5jb20+DQo+ID4gQ2M6IEJvcmlzbGF2IFBldGtvdiA8YnBAYWxpZW44LmRlPg0K
PiA+IENjOiBBbmR5IEx1dG9taXJza2kgPGx1dG9Aa2VybmVsLm9yZz4NCj4gPiBDYzogSW5nbyBN
b2xuYXIgPG1pbmdvQHJlZGhhdC5jb20+DQo+ID4gQ2M6IE5hZGF2IEFtaXQgPG5hbWl0QHZtd2Fy
ZS5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogUmljayBFZGdlY29tYmUgPHJpY2sucC5lZGdlY29t
YmVAaW50ZWwuY29tPg0KPiA+IC0tLQ0KPiA+IA0KPiA+IENoYW5nZXMgc2luY2UgdjE6DQo+ID4g
LSBVcGRhdGUgY29tbWl0IG1lc3NhZ2Ugd2l0aCBtb3JlIGRldGFpbA0KPiA+IC0gRml4IGZsdXNo
IGVuZCByYW5nZSBvbiAhQ09ORklHX0FSQ0hfSEFTX1NFVF9ESVJFQ1RfTUFQIGNhc2UNCj4gPiAN
Cj4gPiBtbS92bWFsbG9jLmMgfCAyMyArKysrKysrKysrKysrLS0tLS0tLS0tLQ0KPiA+IDEgZmls
ZSBjaGFuZ2VkLCAxMyBpbnNlcnRpb25zKCspLCAxMCBkZWxldGlvbnMoLSkNCj4gPiANCj4gPiBk
aWZmIC0tZ2l0IGEvbW0vdm1hbGxvYy5jIGIvbW0vdm1hbGxvYy5jDQo+ID4gaW5kZXggYzQyODcy
ZWQ4MmFjLi44ZDAzNDI3NjI2ZGMgMTAwNjQ0DQo+ID4gLS0tIGEvbW0vdm1hbGxvYy5jDQo+ID4g
KysrIGIvbW0vdm1hbGxvYy5jDQo+ID4gQEAgLTIxMjIsOSArMjEyMiwxMCBAQCBzdGF0aWMgaW5s
aW5lIHZvaWQgc2V0X2FyZWFfZGlyZWN0X21hcChjb25zdA0KPiA+IHN0cnVjdCB2bV9zdHJ1Y3Qg
KmFyZWEsDQo+ID4gLyogSGFuZGxlIHJlbW92aW5nIGFuZCByZXNldHRpbmcgdm0gbWFwcGluZ3Mg
cmVsYXRlZCB0byB0aGUNCj4gPiB2bV9zdHJ1Y3QuICovDQo+ID4gc3RhdGljIHZvaWQgdm1fcmVt
b3ZlX21hcHBpbmdzKHN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEsIGludA0KPiA+IGRlYWxsb2NhdGVf
cGFnZXMpDQo+ID4gew0KPiA+ICsgICAgY29uc3QgYm9vbCBoYXNfc2V0X2RpcmVjdCA9DQo+ID4g
SVNfRU5BQkxFRChDT05GSUdfQVJDSF9IQVNfU0VUX0RJUkVDVF9NQVApOw0KPiA+ICsgICAgY29u
c3QgYm9vbCBmbHVzaF9yZXNldCA9IGFyZWEtPmZsYWdzICYgVk1fRkxVU0hfUkVTRVRfUEVSTVM7
DQo+ID4gICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVkIGxvbmcpYXJlYS0+YWRkcjsN
Cj4gPiAtICAgIHVuc2lnbmVkIGxvbmcgc3RhcnQgPSBVTE9OR19NQVgsIGVuZCA9IDA7DQo+ID4g
LSAgICBpbnQgZmx1c2hfcmVzZXQgPSBhcmVhLT5mbGFncyAmIFZNX0ZMVVNIX1JFU0VUX1BFUk1T
Ow0KPiA+ICsgICAgdW5zaWduZWQgbG9uZyBzdGFydCA9IGFkZHIsIGVuZCA9IGFkZHIgKyBhcmVh
LT5zaXplOw0KPiA+ICAgIGludCBpOw0KPiA+IA0KPiA+ICAgIC8qDQo+ID4gQEAgLTIxMzMsNyAr
MjEzNCw3IEBAIHN0YXRpYyB2b2lkIHZtX3JlbW92ZV9tYXBwaW5ncyhzdHJ1Y3QNCj4gPiB2bV9z
dHJ1Y3QgKmFyZWEsIGludCBkZWFsbG9jYXRlX3BhZ2VzKQ0KPiA+ICAgICAqIFRoaXMgaXMgY29u
Y2VybmVkIHdpdGggcmVzZXR0aW5nIHRoZSBkaXJlY3QgbWFwIGFueSBhbiB2bQ0KPiA+IGFsaWFz
IHdpdGgNCj4gPiAgICAgKiBleGVjdXRlIHBlcm1pc3Npb25zLCB3aXRob3V0IGxlYXZpbmcgYSBS
VytYIHdpbmRvdy4NCj4gPiAgICAgKi8NCj4gPiAtICAgIGlmIChmbHVzaF9yZXNldCAmJg0KPiA+
ICFJU19FTkFCTEVEKENPTkZJR19BUkNIX0hBU19TRVRfRElSRUNUX01BUCkpIHsNCj4gPiArICAg
IGlmIChmbHVzaF9yZXNldCAmJiAhaGFzX3NldF9kaXJlY3QpIHsNCj4gPiAgICAgICAgc2V0X21l
bW9yeV9ueChhZGRyLCBhcmVhLT5ucl9wYWdlcyk7DQo+ID4gICAgICAgIHNldF9tZW1vcnlfcnco
YWRkciwgYXJlYS0+bnJfcGFnZXMpOw0KPiA+ICAgIH0NCj4gPiBAQCAtMjE0NiwyMiArMjE0Nywy
NCBAQCBzdGF0aWMgdm9pZCB2bV9yZW1vdmVfbWFwcGluZ3Moc3RydWN0DQo+ID4gdm1fc3RydWN0
ICphcmVhLCBpbnQgZGVhbGxvY2F0ZV9wYWdlcykNCj4gPiANCj4gPiAgICAvKg0KPiA+ICAgICAq
IElmIG5vdCBkZWFsbG9jYXRpbmcgcGFnZXMsIGp1c3QgZG8gdGhlIGZsdXNoIG9mIHRoZSBWTSBh
cmVhDQo+ID4gYW5kDQo+ID4gLSAgICAgKiByZXR1cm4uDQo+ID4gKyAgICAgKiByZXR1cm4uIElm
IHRoZSBhcmNoIGRvZXNuJ3QgaGF2ZSBzZXRfZGlyZWN0X21hcF8oKSwgYWxzbw0KPiA+IHNraXAg
dGhlDQo+ID4gKyAgICAgKiBiZWxvdyB3b3JrLg0KPiA+ICAgICAqLw0KPiA+IC0gICAgaWYgKCFk
ZWFsbG9jYXRlX3BhZ2VzKSB7DQo+ID4gLSAgICAgICAgdm1fdW5tYXBfYWxpYXNlcygpOw0KPiA+
ICsgICAgaWYgKCFkZWFsbG9jYXRlX3BhZ2VzIHx8ICFoYXNfc2V0X2RpcmVjdCkgew0KPiA+ICsg
ICAgICAgIGZsdXNoX3RsYl9rZXJuZWxfcmFuZ2Uoc3RhcnQsIGVuZCk7DQo+ID4gICAgICAgIHJl
dHVybjsNCj4gPiAgICB9DQo+ID4gDQo+ID4gICAgLyoNCj4gPiAgICAgKiBJZiBleGVjdXRpb24g
Z2V0cyBoZXJlLCBmbHVzaCB0aGUgdm0gbWFwcGluZyBhbmQgcmVzZXQgdGhlDQo+ID4gZGlyZWN0
DQo+ID4gICAgICogbWFwLiBGaW5kIHRoZSBzdGFydCBhbmQgZW5kIHJhbmdlIG9mIHRoZSBkaXJl
Y3QgbWFwcGluZ3MgdG8NCj4gPiBtYWtlIHN1cmUNCj4gPiAtICAgICAqIHRoZSB2bV91bm1hcF9h
bGlhc2VzKCkgZmx1c2ggaW5jbHVkZXMgdGhlIGRpcmVjdCBtYXAuDQo+ID4gKyAgICAgKiB0aGUg
Zmx1c2hfdGxiX2tlcm5lbF9yYW5nZSgpIGluY2x1ZGVzIHRoZSBkaXJlY3QgbWFwLg0KPiA+ICAg
ICAqLw0KPiA+ICAgIGZvciAoaSA9IDA7IGkgPCBhcmVhLT5ucl9wYWdlczsgaSsrKSB7DQo+ID4g
LSAgICAgICAgaWYgKHBhZ2VfYWRkcmVzcyhhcmVhLT5wYWdlc1tpXSkpIHsNCj4gPiArICAgICAg
ICBhZGRyID0gKHVuc2lnbmVkIGxvbmcpcGFnZV9hZGRyZXNzKGFyZWEtPnBhZ2VzW2ldKTsNCj4g
PiArICAgICAgICBpZiAoYWRkcikgew0KPiA+ICAgICAgICAgICAgc3RhcnQgPSBtaW4oYWRkciwg
c3RhcnQpOw0KPiA+IC0gICAgICAgICAgICBlbmQgPSBtYXgoYWRkciwgZW5kKTsNCj4gPiArICAg
ICAgICAgICAgZW5kID0gbWF4KGFkZHIgKyBQQUdFX1NJWkUsIGVuZCk7DQo+ID4gICAgICAgIH0N
Cj4gPiAgICB9DQo+ID4gDQo+ID4gQEAgLTIxNzEsNyArMjE3NCw3IEBAIHN0YXRpYyB2b2lkIHZt
X3JlbW92ZV9tYXBwaW5ncyhzdHJ1Y3QNCj4gPiB2bV9zdHJ1Y3QgKmFyZWEsIGludCBkZWFsbG9j
YXRlX3BhZ2VzKQ0KPiA+ICAgICAqIHJlc2V0IHRoZSBkaXJlY3QgbWFwIHBlcm1pc3Npb25zIHRv
IHRoZSBkZWZhdWx0Lg0KPiA+ICAgICAqLw0KPiA+ICAgIHNldF9hcmVhX2RpcmVjdF9tYXAoYXJl
YSwgc2V0X2RpcmVjdF9tYXBfaW52YWxpZF9ub2ZsdXNoKTsNCj4gPiAtICAgIF92bV91bm1hcF9h
bGlhc2VzKHN0YXJ0LCBlbmQsIDEpOw0KPiA+ICsgICAgZmx1c2hfdGxiX2tlcm5lbF9yYW5nZShz
dGFydCwgZW5kKTsNCj4gPiAgICBzZXRfYXJlYV9kaXJlY3RfbWFwKGFyZWEsIHNldF9kaXJlY3Rf
bWFwX2RlZmF1bHRfbm9mbHVzaCk7DQo+ID4gfQ0KPiA+IA0KPiA+IC0tIA0KPiA+IDIuMjAuMQ0K
PiA+IA0K

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-20 21:36   ` Meelis Roos
@ 2019-05-20 22:17     ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-20 22:17 UTC (permalink / raw)
  To: linux-mm, linux-kernel, peterz, mroos, netdev, sparclinux
  Cc: bp, davem, luto, mingo, namit, Hansen, Dave

On Tue, 2019-05-21 at 00:36 +0300, Meelis Roos wrote:
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
> > CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> > 
> > Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag
> > on a
> > sparc machine. On investigation some issues were noticed:
> > 
> > 1. The calculation of the direct map address range to flush was
> > wrong.
> > This could cause problems on x86 if a RO direct map alias ever got
> > loaded
> > into the TLB. This shouldn't normally happen, but it could cause
> > the
> > permissions to remain RO on the direct map alias, and then the page
> > would return from the page allocator to some other component as RO
> > and
> > cause a crash.
> > 
> > 2. Calling vm_unmap_alias() on vfree could potentially be a lot of
> > work to
> > do on a free operation. Simply flushing the TLB instead of the
> > whole
> > vm_unmap_alias() operation makes the frees faster and pushes the
> > heavy
> > work to happen on allocation where it would be more expected.
> > In addition to the extra work, vm_unmap_alias() takes some locks
> > including
> > a long hold of vmap_purge_lock, which will make all other
> > VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> > 
> > 3. page_address() can have locking on some configurations, so skip
> > calling
> > this when possible to further speed this up.
> > 
> > Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special
> > permsissions")
> > Reported-by: Meelis Roos<mroos@linux.ee>
> > Cc: Meelis Roos<mroos@linux.ee>
> > Cc: Peter Zijlstra<peterz@infradead.org>
> > Cc: "David S. Miller"<davem@davemloft.net>
> > Cc: Dave Hansen<dave.hansen@intel.com>
> > Cc: Borislav Petkov<bp@alien8.de>
> > Cc: Andy Lutomirski<luto@kernel.org>
> > Cc: Ingo Molnar<mingo@redhat.com>
> > Cc: Nadav Amit<namit@vmware.com>
> > Signed-off-by: Rick Edgecombe<rick.p.edgecombe@intel.com>
> > ---
> > 
> > Changes since v1:
> >   - Update commit message with more detail
> >   - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case
> 
> It does not work on my V445 where the initial problem happened.
> 
Thanks for testing. So I guess that suggests it's the TLB flush causing
the problem on sparc and not any lazy purge deadlock. I had sent Meelis
another test patch that just flushed the entire 0 to ULONG_MAX range to
try to always the get the "flush all" logic and apprently it didn't
boot mostly either. It also showed that it's not getting stuck anywhere
in the vm_remove_alias() function. Something just hangs later.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 22:17     ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-20 22:17 UTC (permalink / raw)
  To: linux-mm, linux-kernel, peterz, mroos, netdev, sparclinux
  Cc: bp, davem, luto, mingo, namit, Hansen, Dave

T24gVHVlLCAyMDE5LTA1LTIxIGF0IDAwOjM2ICswMzAwLCBNZWVsaXMgUm9vcyB3cm90ZToNCj4g
PiBTd2l0Y2ggVk1fRkxVU0hfUkVTRVRfUEVSTVMgdG8gdXNlIGEgcmVndWxhciBUTEIgZmx1c2gg
aW50ZWFkIG9mDQo+ID4gdm1fdW5tYXBfYWxpYXNlcygpIGFuZCBmaXggY2FsY3VsYXRpb24gb2Yg
dGhlIGRpcmVjdCBtYXAgZm9yIHRoZQ0KPiA+IENPTkZJR19BUkNIX0hBU19TRVRfRElSRUNUX01B
UCBjYXNlLg0KPiA+IA0KPiA+IE1lZWxpcyBSb29zIHJlcG9ydGVkIGlzc3VlcyB3aXRoIHRoZSBu
ZXcgVk1fRkxVU0hfUkVTRVRfUEVSTVMgZmxhZw0KPiA+IG9uIGENCj4gPiBzcGFyYyBtYWNoaW5l
LiBPbiBpbnZlc3RpZ2F0aW9uIHNvbWUgaXNzdWVzIHdlcmUgbm90aWNlZDoNCj4gPiANCj4gPiAx
LiBUaGUgY2FsY3VsYXRpb24gb2YgdGhlIGRpcmVjdCBtYXAgYWRkcmVzcyByYW5nZSB0byBmbHVz
aCB3YXMNCj4gPiB3cm9uZy4NCj4gPiBUaGlzIGNvdWxkIGNhdXNlIHByb2JsZW1zIG9uIHg4NiBp
ZiBhIFJPIGRpcmVjdCBtYXAgYWxpYXMgZXZlciBnb3QNCj4gPiBsb2FkZWQNCj4gPiBpbnRvIHRo
ZSBUTEIuIFRoaXMgc2hvdWxkbid0IG5vcm1hbGx5IGhhcHBlbiwgYnV0IGl0IGNvdWxkIGNhdXNl
DQo+ID4gdGhlDQo+ID4gcGVybWlzc2lvbnMgdG8gcmVtYWluIFJPIG9uIHRoZSBkaXJlY3QgbWFw
IGFsaWFzLCBhbmQgdGhlbiB0aGUgcGFnZQ0KPiA+IHdvdWxkIHJldHVybiBmcm9tIHRoZSBwYWdl
IGFsbG9jYXRvciB0byBzb21lIG90aGVyIGNvbXBvbmVudCBhcyBSTw0KPiA+IGFuZA0KPiA+IGNh
dXNlIGEgY3Jhc2guDQo+ID4gDQo+ID4gMi4gQ2FsbGluZyB2bV91bm1hcF9hbGlhcygpIG9uIHZm
cmVlIGNvdWxkIHBvdGVudGlhbGx5IGJlIGEgbG90IG9mDQo+ID4gd29yayB0bw0KPiA+IGRvIG9u
IGEgZnJlZSBvcGVyYXRpb24uIFNpbXBseSBmbHVzaGluZyB0aGUgVExCIGluc3RlYWQgb2YgdGhl
DQo+ID4gd2hvbGUNCj4gPiB2bV91bm1hcF9hbGlhcygpIG9wZXJhdGlvbiBtYWtlcyB0aGUgZnJl
ZXMgZmFzdGVyIGFuZCBwdXNoZXMgdGhlDQo+ID4gaGVhdnkNCj4gPiB3b3JrIHRvIGhhcHBlbiBv
biBhbGxvY2F0aW9uIHdoZXJlIGl0IHdvdWxkIGJlIG1vcmUgZXhwZWN0ZWQuDQo+ID4gSW4gYWRk
aXRpb24gdG8gdGhlIGV4dHJhIHdvcmssIHZtX3VubWFwX2FsaWFzKCkgdGFrZXMgc29tZSBsb2Nr
cw0KPiA+IGluY2x1ZGluZw0KPiA+IGEgbG9uZyBob2xkIG9mIHZtYXBfcHVyZ2VfbG9jaywgd2hp
Y2ggd2lsbCBtYWtlIGFsbCBvdGhlcg0KPiA+IFZNX0ZMVVNIX1JFU0VUX1BFUk1TIHZmcmVlcyB3
YWl0IHdoaWxlIHRoZSBwdXJnZSBvcGVyYXRpb24gaGFwcGVucy4NCj4gPiANCj4gPiAzLiBwYWdl
X2FkZHJlc3MoKSBjYW4gaGF2ZSBsb2NraW5nIG9uIHNvbWUgY29uZmlndXJhdGlvbnMsIHNvIHNr
aXANCj4gPiBjYWxsaW5nDQo+ID4gdGhpcyB3aGVuIHBvc3NpYmxlIHRvIGZ1cnRoZXIgc3BlZWQg
dGhpcyB1cC4NCj4gPiANCj4gPiBGaXhlczogODY4YjEwNGQ3Mzc5ICgibW0vdm1hbGxvYzogQWRk
IGZsYWcgZm9yIGZyZWVpbmcgb2Ygc3BlY2lhbA0KPiA+IHBlcm1zaXNzaW9ucyIpDQo+ID4gUmVw
b3J0ZWQtYnk6IE1lZWxpcyBSb29zPG1yb29zQGxpbnV4LmVlPg0KPiA+IENjOiBNZWVsaXMgUm9v
czxtcm9vc0BsaW51eC5lZT4NCj4gPiBDYzogUGV0ZXIgWmlqbHN0cmE8cGV0ZXJ6QGluZnJhZGVh
ZC5vcmc+DQo+ID4gQ2M6ICJEYXZpZCBTLiBNaWxsZXIiPGRhdmVtQGRhdmVtbG9mdC5uZXQ+DQo+
ID4gQ2M6IERhdmUgSGFuc2VuPGRhdmUuaGFuc2VuQGludGVsLmNvbT4NCj4gPiBDYzogQm9yaXNs
YXYgUGV0a292PGJwQGFsaWVuOC5kZT4NCj4gPiBDYzogQW5keSBMdXRvbWlyc2tpPGx1dG9Aa2Vy
bmVsLm9yZz4NCj4gPiBDYzogSW5nbyBNb2xuYXI8bWluZ29AcmVkaGF0LmNvbT4NCj4gPiBDYzog
TmFkYXYgQW1pdDxuYW1pdEB2bXdhcmUuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFJpY2sgRWRn
ZWNvbWJlPHJpY2sucC5lZGdlY29tYmVAaW50ZWwuY29tPg0KPiA+IC0tLQ0KPiA+IA0KPiA+IENo
YW5nZXMgc2luY2UgdjE6DQo+ID4gICAtIFVwZGF0ZSBjb21taXQgbWVzc2FnZSB3aXRoIG1vcmUg
ZGV0YWlsDQo+ID4gICAtIEZpeCBmbHVzaCBlbmQgcmFuZ2Ugb24gIUNPTkZJR19BUkNIX0hBU19T
RVRfRElSRUNUX01BUCBjYXNlDQo+IA0KPiBJdCBkb2VzIG5vdCB3b3JrIG9uIG15IFY0NDUgd2hl
cmUgdGhlIGluaXRpYWwgcHJvYmxlbSBoYXBwZW5lZC4NCj4gDQpUaGFua3MgZm9yIHRlc3Rpbmcu
IFNvIEkgZ3Vlc3MgdGhhdCBzdWdnZXN0cyBpdCdzIHRoZSBUTEIgZmx1c2ggY2F1c2luZw0KdGhl
IHByb2JsZW0gb24gc3BhcmMgYW5kIG5vdCBhbnkgbGF6eSBwdXJnZSBkZWFkbG9jay4gSSBoYWQg
c2VudCBNZWVsaXMNCmFub3RoZXIgdGVzdCBwYXRjaCB0aGF0IGp1c3QgZmx1c2hlZCB0aGUgZW50
aXJlIDAgdG8gVUxPTkdfTUFYIHJhbmdlIHRvDQp0cnkgdG8gYWx3YXlzIHRoZSBnZXQgdGhlICJm
bHVzaCBhbGwiIGxvZ2ljIGFuZCBhcHByZW50bHkgaXQgZGlkbid0DQpib290IG1vc3RseSBlaXRo
ZXIuIEl0IGFsc28gc2hvd2VkIHRoYXQgaXQncyBub3QgZ2V0dGluZyBzdHVjayBhbnl3aGVyZQ0K
aW4gdGhlIHZtX3JlbW92ZV9hbGlhcygpIGZ1bmN0aW9uLiBTb21ldGhpbmcganVzdCBoYW5ncyBs
YXRlci4NCg0KDQo

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-20 22:17     ` Edgecombe, Rick P
@ 2019-05-20 22:48       ` David Miller
  -1 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-20 22:48 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-mm, linux-kernel, peterz, mroos, netdev, sparclinux, bp,
	luto, mingo, namit, dave.hansen

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Mon, 20 May 2019 22:17:49 +0000

> Thanks for testing. So I guess that suggests it's the TLB flush causing
> the problem on sparc and not any lazy purge deadlock. I had sent Meelis
> another test patch that just flushed the entire 0 to ULONG_MAX range to
> try to always the get the "flush all" logic and apprently it didn't
> boot mostly either. It also showed that it's not getting stuck anywhere
> in the vm_remove_alias() function. Something just hangs later.

I wonder if an address is making it to the TLB flush routines which is
not page aligned.  Or a TLB flush is being done before the callsites
are patched properly for the given cpu type.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-20 22:48       ` David Miller
  0 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-20 22:48 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-mm, linux-kernel, peterz, mroos, netdev, sparclinux, bp,
	luto, mingo, namit, dave.hansen

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Mon, 20 May 2019 22:17:49 +0000

> Thanks for testing. So I guess that suggests it's the TLB flush causing
> the problem on sparc and not any lazy purge deadlock. I had sent Meelis
> another test patch that just flushed the entire 0 to ULONG_MAX range to
> try to always the get the "flush all" logic and apprently it didn't
> boot mostly either. It also showed that it's not getting stuck anywhere
> in the vm_remove_alias() function. Something just hangs later.

I wonder if an address is making it to the TLB flush routines which is
not page aligned.  Or a TLB flush is being done before the callsites
are patched properly for the given cpu type.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-20 22:48       ` David Miller
@ 2019-05-21  0:20         ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-21  0:20 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

On Mon, 2019-05-20 at 15:48 -0700, David Miller wrote:
> From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> Date: Mon, 20 May 2019 22:17:49 +0000
> 
> > Thanks for testing. So I guess that suggests it's the TLB flush
> > causing
> > the problem on sparc and not any lazy purge deadlock. I had sent
> > Meelis
> > another test patch that just flushed the entire 0 to ULONG_MAX
> > range to
> > try to always the get the "flush all" logic and apprently it didn't
> > boot mostly either. It also showed that it's not getting stuck
> > anywhere
> > in the vm_remove_alias() function. Something just hangs later.
> 
> I wonder if an address is making it to the TLB flush routines which
> is
> not page aligned.
I think vmalloc should force PAGE_SIZE alignment, but will double check
nothing got screwed up.

> Or a TLB flush is being done before the callsites
> are patched properly for the given cpu type.
Any idea how I could log when this is done? It looks like it's done
really early in boot assembly. This behavior shouldn't happen until
modules or BPF are being freed.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-21  0:20         ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-21  0:20 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

T24gTW9uLCAyMDE5LTA1LTIwIGF0IDE1OjQ4IC0wNzAwLCBEYXZpZCBNaWxsZXIgd3JvdGU6DQo+
IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2sucC5lZGdlY29tYmVAaW50ZWwuY29tPg0K
PiBEYXRlOiBNb24sIDIwIE1heSAyMDE5IDIyOjE3OjQ5ICswMDAwDQo+IA0KPiA+IFRoYW5rcyBm
b3IgdGVzdGluZy4gU28gSSBndWVzcyB0aGF0IHN1Z2dlc3RzIGl0J3MgdGhlIFRMQiBmbHVzaA0K
PiA+IGNhdXNpbmcNCj4gPiB0aGUgcHJvYmxlbSBvbiBzcGFyYyBhbmQgbm90IGFueSBsYXp5IHB1
cmdlIGRlYWRsb2NrLiBJIGhhZCBzZW50DQo+ID4gTWVlbGlzDQo+ID4gYW5vdGhlciB0ZXN0IHBh
dGNoIHRoYXQganVzdCBmbHVzaGVkIHRoZSBlbnRpcmUgMCB0byBVTE9OR19NQVgNCj4gPiByYW5n
ZSB0bw0KPiA+IHRyeSB0byBhbHdheXMgdGhlIGdldCB0aGUgImZsdXNoIGFsbCIgbG9naWMgYW5k
IGFwcHJlbnRseSBpdCBkaWRuJ3QNCj4gPiBib290IG1vc3RseSBlaXRoZXIuIEl0IGFsc28gc2hv
d2VkIHRoYXQgaXQncyBub3QgZ2V0dGluZyBzdHVjaw0KPiA+IGFueXdoZXJlDQo+ID4gaW4gdGhl
IHZtX3JlbW92ZV9hbGlhcygpIGZ1bmN0aW9uLiBTb21ldGhpbmcganVzdCBoYW5ncyBsYXRlci4N
Cj4gDQo+IEkgd29uZGVyIGlmIGFuIGFkZHJlc3MgaXMgbWFraW5nIGl0IHRvIHRoZSBUTEIgZmx1
c2ggcm91dGluZXMgd2hpY2gNCj4gaXMNCj4gbm90IHBhZ2UgYWxpZ25lZC4NCkkgdGhpbmsgdm1h
bGxvYyBzaG91bGQgZm9yY2UgUEFHRV9TSVpFIGFsaWdubWVudCwgYnV0IHdpbGwgZG91YmxlIGNo
ZWNrDQpub3RoaW5nIGdvdCBzY3Jld2VkIHVwLg0KDQo+IE9yIGEgVExCIGZsdXNoIGlzIGJlaW5n
IGRvbmUgYmVmb3JlIHRoZSBjYWxsc2l0ZXMNCj4gYXJlIHBhdGNoZWQgcHJvcGVybHkgZm9yIHRo
ZSBnaXZlbiBjcHUgdHlwZS4NCkFueSBpZGVhIGhvdyBJIGNvdWxkIGxvZyB3aGVuIHRoaXMgaXMg
ZG9uZT8gSXQgbG9va3MgbGlrZSBpdCdzIGRvbmUNCnJlYWxseSBlYXJseSBpbiBib290IGFzc2Vt
Ymx5LiBUaGlzIGJlaGF2aW9yIHNob3VsZG4ndCBoYXBwZW4gdW50aWwNCm1vZHVsZXMgb3IgQlBG
IGFyZSBiZWluZyBmcmVlZC4NCg=

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-21  0:20         ` Edgecombe, Rick P
@ 2019-05-21  0:33           ` David Miller
  -1 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-21  0:33 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, dave.hansen, sparclinux

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Tue, 21 May 2019 00:20:13 +0000

> This behavior shouldn't happen until modules or BPF are being freed.

Then that would rule out my theory.

The only thing left is whether the permissions are actually set
properly.  If they aren't we'll take an exception when the BPF program
is run and I'm not %100 sure that kernel execute permission violations
are totally handled cleanly.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-21  0:33           ` David Miller
  0 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-21  0:33 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, dave.hansen, sparclinux

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Tue, 21 May 2019 00:20:13 +0000

> This behavior shouldn't happen until modules or BPF are being freed.

Then that would rule out my theory.

The only thing left is whether the permissions are actually set
properly.  If they aren't we'll take an exception when the BPF program
is run and I'm not %100 sure that kernel execute permission violations
are totally handled cleanly.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-21  0:33           ` David Miller
@ 2019-05-21  1:20             ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-21  1:20 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

On Mon, 2019-05-20 at 20:33 -0400, David Miller wrote:
> From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> Date: Tue, 21 May 2019 00:20:13 +0000
> 
> > This behavior shouldn't happen until modules or BPF are being
> > freed.
> 
> Then that would rule out my theory.
> 
> The only thing left is whether the permissions are actually set
> properly.  If they aren't we'll take an exception when the BPF
> program
> is run and I'm not %100 sure that kernel execute permission
> violations
> are totally handled cleanly.
Permissions shouldn't be affected with this except on free. But reading
the code it looked like sparc had all PAGE_KERNEL as executable and no
set_memory_() implementations. Is there some places where permissions
are being set?

Should it handle executing an unmapped page gracefully? Because this
change is causing that to happen much earlier. If something was relying
on a cached translation to execute something it could find the mapping
disappear.










^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-21  1:20             ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-21  1:20 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

T24gTW9uLCAyMDE5LTA1LTIwIGF0IDIwOjMzIC0wNDAwLCBEYXZpZCBNaWxsZXIgd3JvdGU6DQo+
IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2sucC5lZGdlY29tYmVAaW50ZWwuY29tPg0K
PiBEYXRlOiBUdWUsIDIxIE1heSAyMDE5IDAwOjIwOjEzICswMDAwDQo+IA0KPiA+IFRoaXMgYmVo
YXZpb3Igc2hvdWxkbid0IGhhcHBlbiB1bnRpbCBtb2R1bGVzIG9yIEJQRiBhcmUgYmVpbmcNCj4g
PiBmcmVlZC4NCj4gDQo+IFRoZW4gdGhhdCB3b3VsZCBydWxlIG91dCBteSB0aGVvcnkuDQo+IA0K
PiBUaGUgb25seSB0aGluZyBsZWZ0IGlzIHdoZXRoZXIgdGhlIHBlcm1pc3Npb25zIGFyZSBhY3R1
YWxseSBzZXQNCj4gcHJvcGVybHkuICBJZiB0aGV5IGFyZW4ndCB3ZSdsbCB0YWtlIGFuIGV4Y2Vw
dGlvbiB3aGVuIHRoZSBCUEYNCj4gcHJvZ3JhbQ0KPiBpcyBydW4gYW5kIEknbSBub3QgJTEwMCBz
dXJlIHRoYXQga2VybmVsIGV4ZWN1dGUgcGVybWlzc2lvbg0KPiB2aW9sYXRpb25zDQo+IGFyZSB0
b3RhbGx5IGhhbmRsZWQgY2xlYW5seS4NClBlcm1pc3Npb25zIHNob3VsZG4ndCBiZSBhZmZlY3Rl
ZCB3aXRoIHRoaXMgZXhjZXB0IG9uIGZyZWUuIEJ1dCByZWFkaW5nDQp0aGUgY29kZSBpdCBsb29r
ZWQgbGlrZSBzcGFyYyBoYWQgYWxsIFBBR0VfS0VSTkVMIGFzIGV4ZWN1dGFibGUgYW5kIG5vDQpz
ZXRfbWVtb3J5XygpIGltcGxlbWVudGF0aW9ucy4gSXMgdGhlcmUgc29tZSBwbGFjZXMgd2hlcmUg
cGVybWlzc2lvbnMNCmFyZSBiZWluZyBzZXQ/DQoNClNob3VsZCBpdCBoYW5kbGUgZXhlY3V0aW5n
IGFuIHVubWFwcGVkIHBhZ2UgZ3JhY2VmdWxseT8gQmVjYXVzZSB0aGlzDQpjaGFuZ2UgaXMgY2F1
c2luZyB0aGF0IHRvIGhhcHBlbiBtdWNoIGVhcmxpZXIuIElmIHNvbWV0aGluZyB3YXMgcmVseWlu
Zw0Kb24gYSBjYWNoZWQgdHJhbnNsYXRpb24gdG8gZXhlY3V0ZSBzb21ldGhpbmcgaXQgY291bGQg
ZmluZCB0aGUgbWFwcGluZw0KZGlzYXBwZWFyLg0KDQoNCg0KDQoNCg0KDQoNCg0K

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-21  1:20             ` Edgecombe, Rick P
@ 2019-05-21  1:43               ` David Miller
  -1 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-21  1:43 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, dave.hansen, sparclinux

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Tue, 21 May 2019 01:20:33 +0000

> Should it handle executing an unmapped page gracefully? Because this
> change is causing that to happen much earlier. If something was relying
> on a cached translation to execute something it could find the mapping
> disappear.

Does this work by not mapping any kernel mappings at the beginning,
and then filling in the BPF mappings in response to faults?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-21  1:43               ` David Miller
  0 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-21  1:43 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, dave.hansen, sparclinux

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Tue, 21 May 2019 01:20:33 +0000

> Should it handle executing an unmapped page gracefully? Because this
> change is causing that to happen much earlier. If something was relying
> on a cached translation to execute something it could find the mapping
> disappear.

Does this work by not mapping any kernel mappings at the beginning,
and then filling in the BPF mappings in response to faults?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-21  1:43               ` David Miller
@ 2019-05-21  1:59                 ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-21  1:59 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> Date: Tue, 21 May 2019 01:20:33 +0000
> 
> > Should it handle executing an unmapped page gracefully? Because
> > this
> > change is causing that to happen much earlier. If something was
> > relying
> > on a cached translation to execute something it could find the
> > mapping
> > disappear.
> 
> Does this work by not mapping any kernel mappings at the beginning,
> and then filling in the BPF mappings in response to faults?
No, nothing too fancy. It just flushes the vm mapping immediatly in
vfree for execute (and RO) mappings. The only thing that happens around
allocation time is setting of a new flag to tell vmalloc to do the
flush.

The problem before was that the pages would be freed before the execute
mapping was flushed. So then when the pages got recycled, random,
sometimes coming from userspace, data would be mapped as executable in
the kernel by the un-flushed tlb entries.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-21  1:59                 ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-21  1:59 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

T24gTW9uLCAyMDE5LTA1LTIwIGF0IDE4OjQzIC0wNzAwLCBEYXZpZCBNaWxsZXIgd3JvdGU6DQo+
IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2sucC5lZGdlY29tYmVAaW50ZWwuY29tPg0K
PiBEYXRlOiBUdWUsIDIxIE1heSAyMDE5IDAxOjIwOjMzICswMDAwDQo+IA0KPiA+IFNob3VsZCBp
dCBoYW5kbGUgZXhlY3V0aW5nIGFuIHVubWFwcGVkIHBhZ2UgZ3JhY2VmdWxseT8gQmVjYXVzZQ0K
PiA+IHRoaXMNCj4gPiBjaGFuZ2UgaXMgY2F1c2luZyB0aGF0IHRvIGhhcHBlbiBtdWNoIGVhcmxp
ZXIuIElmIHNvbWV0aGluZyB3YXMNCj4gPiByZWx5aW5nDQo+ID4gb24gYSBjYWNoZWQgdHJhbnNs
YXRpb24gdG8gZXhlY3V0ZSBzb21ldGhpbmcgaXQgY291bGQgZmluZCB0aGUNCj4gPiBtYXBwaW5n
DQo+ID4gZGlzYXBwZWFyLg0KPiANCj4gRG9lcyB0aGlzIHdvcmsgYnkgbm90IG1hcHBpbmcgYW55
IGtlcm5lbCBtYXBwaW5ncyBhdCB0aGUgYmVnaW5uaW5nLA0KPiBhbmQgdGhlbiBmaWxsaW5nIGlu
IHRoZSBCUEYgbWFwcGluZ3MgaW4gcmVzcG9uc2UgdG8gZmF1bHRzPw0KTm8sIG5vdGhpbmcgdG9v
IGZhbmN5LiBJdCBqdXN0IGZsdXNoZXMgdGhlIHZtIG1hcHBpbmcgaW1tZWRpYXRseSBpbg0KdmZy
ZWUgZm9yIGV4ZWN1dGUgKGFuZCBSTykgbWFwcGluZ3MuIFRoZSBvbmx5IHRoaW5nIHRoYXQgaGFw
cGVucyBhcm91bmQNCmFsbG9jYXRpb24gdGltZSBpcyBzZXR0aW5nIG9mIGEgbmV3IGZsYWcgdG8g
dGVsbCB2bWFsbG9jIHRvIGRvIHRoZQ0KZmx1c2guDQoNClRoZSBwcm9ibGVtIGJlZm9yZSB3YXMg
dGhhdCB0aGUgcGFnZXMgd291bGQgYmUgZnJlZWQgYmVmb3JlIHRoZSBleGVjdXRlDQptYXBwaW5n
IHdhcyBmbHVzaGVkLiBTbyB0aGVuIHdoZW4gdGhlIHBhZ2VzIGdvdCByZWN5Y2xlZCwgcmFuZG9t
LA0Kc29tZXRpbWVzIGNvbWluZyBmcm9tIHVzZXJzcGFjZSwgZGF0YSB3b3VsZCBiZSBtYXBwZWQg
YXMgZXhlY3V0YWJsZSBpbg0KdGhlIGtlcm5lbCBieSB0aGUgdW4tZmx1c2hlZCB0bGIgZW50cmll
cy4NCg0KDQo

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-21  1:59                 ` Edgecombe, Rick P
@ 2019-05-22 17:40                   ` David Miller
  -1 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-22 17:40 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, dave.hansen, sparclinux

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Tue, 21 May 2019 01:59:54 +0000

> On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
>> From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
>> Date: Tue, 21 May 2019 01:20:33 +0000
>> 
>> > Should it handle executing an unmapped page gracefully? Because
>> > this
>> > change is causing that to happen much earlier. If something was
>> > relying
>> > on a cached translation to execute something it could find the
>> > mapping
>> > disappear.
>> 
>> Does this work by not mapping any kernel mappings at the beginning,
>> and then filling in the BPF mappings in response to faults?
> No, nothing too fancy. It just flushes the vm mapping immediatly in
> vfree for execute (and RO) mappings. The only thing that happens around
> allocation time is setting of a new flag to tell vmalloc to do the
> flush.
> 
> The problem before was that the pages would be freed before the execute
> mapping was flushed. So then when the pages got recycled, random,
> sometimes coming from userspace, data would be mapped as executable in
> the kernel by the un-flushed tlb entries.

If I am to understand things correctly, there was a case where 'end'
could be smaller than 'start' when doing a range flush.  That would
definitely kill some of the sparc64 TLB flush routines.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-22 17:40                   ` David Miller
  0 siblings, 0 replies; 30+ messages in thread
From: David Miller @ 2019-05-22 17:40 UTC (permalink / raw)
  To: rick.p.edgecombe
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, dave.hansen, sparclinux

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: Tue, 21 May 2019 01:59:54 +0000

> On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
>> From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
>> Date: Tue, 21 May 2019 01:20:33 +0000
>> 
>> > Should it handle executing an unmapped page gracefully? Because
>> > this
>> > change is causing that to happen much earlier. If something was
>> > relying
>> > on a cached translation to execute something it could find the
>> > mapping
>> > disappear.
>> 
>> Does this work by not mapping any kernel mappings at the beginning,
>> and then filling in the BPF mappings in response to faults?
> No, nothing too fancy. It just flushes the vm mapping immediatly in
> vfree for execute (and RO) mappings. The only thing that happens around
> allocation time is setting of a new flag to tell vmalloc to do the
> flush.
> 
> The problem before was that the pages would be freed before the execute
> mapping was flushed. So then when the pages got recycled, random,
> sometimes coming from userspace, data would be mapped as executable in
> the kernel by the un-flushed tlb entries.

If I am to understand things correctly, there was a case where 'end'
could be smaller than 'start' when doing a range flush.  That would
definitely kill some of the sparc64 TLB flush routines.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-22 17:40                   ` David Miller
@ 2019-05-22 19:26                     ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-22 19:26 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> Date: Tue, 21 May 2019 01:59:54 +0000
> 
> > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> > > Date: Tue, 21 May 2019 01:20:33 +0000
> > > 
> > > > Should it handle executing an unmapped page gracefully? Because
> > > > this
> > > > change is causing that to happen much earlier. If something was
> > > > relying
> > > > on a cached translation to execute something it could find the
> > > > mapping
> > > > disappear.
> > > 
> > > Does this work by not mapping any kernel mappings at the
> > > beginning,
> > > and then filling in the BPF mappings in response to faults?
> > No, nothing too fancy. It just flushes the vm mapping immediatly in
> > vfree for execute (and RO) mappings. The only thing that happens
> > around
> > allocation time is setting of a new flag to tell vmalloc to do the
> > flush.
> > 
> > The problem before was that the pages would be freed before the
> > execute
> > mapping was flushed. So then when the pages got recycled, random,
> > sometimes coming from userspace, data would be mapped as executable
> > in
> > the kernel by the un-flushed tlb entries.
> 
> If I am to understand things correctly, there was a case where 'end'
> could be smaller than 'start' when doing a range flush.  That would
> definitely kill some of the sparc64 TLB flush routines.

Ok, thanks.

The patch at the beginning of this thread doesn't have that behavior
though and it apparently still hung. I asked if Meelis could test with
this feature disabled and DEBUG_PAGEALLOC on, since it flushes on every
vfree and is not new logic, and also with a patch that logs exact TLB
flush ranges and fault addresses on top of the kernel having this
issue. Hopefully that will shed some light.

Sorry for all the noise and speculation on this. It has been difficult
to debug remotely with a tester and developer in different time zones.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-22 19:26                     ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-22 19:26 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

T24gV2VkLCAyMDE5LTA1LTIyIGF0IDEwOjQwIC0wNzAwLCBEYXZpZCBNaWxsZXIgd3JvdGU6DQo+
IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2sucC5lZGdlY29tYmVAaW50ZWwuY29tPg0K
PiBEYXRlOiBUdWUsIDIxIE1heSAyMDE5IDAxOjU5OjU0ICswMDAwDQo+IA0KPiA+IE9uIE1vbiwg
MjAxOS0wNS0yMCBhdCAxODo0MyAtMDcwMCwgRGF2aWQgTWlsbGVyIHdyb3RlOg0KPiA+ID4gRnJv
bTogIkVkZ2Vjb21iZSwgUmljayBQIiA8cmljay5wLmVkZ2Vjb21iZUBpbnRlbC5jb20+DQo+ID4g
PiBEYXRlOiBUdWUsIDIxIE1heSAyMDE5IDAxOjIwOjMzICswMDAwDQo+ID4gPiANCj4gPiA+ID4g
U2hvdWxkIGl0IGhhbmRsZSBleGVjdXRpbmcgYW4gdW5tYXBwZWQgcGFnZSBncmFjZWZ1bGx5PyBC
ZWNhdXNlDQo+ID4gPiA+IHRoaXMNCj4gPiA+ID4gY2hhbmdlIGlzIGNhdXNpbmcgdGhhdCB0byBo
YXBwZW4gbXVjaCBlYXJsaWVyLiBJZiBzb21ldGhpbmcgd2FzDQo+ID4gPiA+IHJlbHlpbmcNCj4g
PiA+ID4gb24gYSBjYWNoZWQgdHJhbnNsYXRpb24gdG8gZXhlY3V0ZSBzb21ldGhpbmcgaXQgY291
bGQgZmluZCB0aGUNCj4gPiA+ID4gbWFwcGluZw0KPiA+ID4gPiBkaXNhcHBlYXIuDQo+ID4gPiAN
Cj4gPiA+IERvZXMgdGhpcyB3b3JrIGJ5IG5vdCBtYXBwaW5nIGFueSBrZXJuZWwgbWFwcGluZ3Mg
YXQgdGhlDQo+ID4gPiBiZWdpbm5pbmcsDQo+ID4gPiBhbmQgdGhlbiBmaWxsaW5nIGluIHRoZSBC
UEYgbWFwcGluZ3MgaW4gcmVzcG9uc2UgdG8gZmF1bHRzPw0KPiA+IE5vLCBub3RoaW5nIHRvbyBm
YW5jeS4gSXQganVzdCBmbHVzaGVzIHRoZSB2bSBtYXBwaW5nIGltbWVkaWF0bHkgaW4NCj4gPiB2
ZnJlZSBmb3IgZXhlY3V0ZSAoYW5kIFJPKSBtYXBwaW5ncy4gVGhlIG9ubHkgdGhpbmcgdGhhdCBo
YXBwZW5zDQo+ID4gYXJvdW5kDQo+ID4gYWxsb2NhdGlvbiB0aW1lIGlzIHNldHRpbmcgb2YgYSBu
ZXcgZmxhZyB0byB0ZWxsIHZtYWxsb2MgdG8gZG8gdGhlDQo+ID4gZmx1c2guDQo+ID4gDQo+ID4g
VGhlIHByb2JsZW0gYmVmb3JlIHdhcyB0aGF0IHRoZSBwYWdlcyB3b3VsZCBiZSBmcmVlZCBiZWZv
cmUgdGhlDQo+ID4gZXhlY3V0ZQ0KPiA+IG1hcHBpbmcgd2FzIGZsdXNoZWQuIFNvIHRoZW4gd2hl
biB0aGUgcGFnZXMgZ290IHJlY3ljbGVkLCByYW5kb20sDQo+ID4gc29tZXRpbWVzIGNvbWluZyBm
cm9tIHVzZXJzcGFjZSwgZGF0YSB3b3VsZCBiZSBtYXBwZWQgYXMgZXhlY3V0YWJsZQ0KPiA+IGlu
DQo+ID4gdGhlIGtlcm5lbCBieSB0aGUgdW4tZmx1c2hlZCB0bGIgZW50cmllcy4NCj4gDQo+IElm
IEkgYW0gdG8gdW5kZXJzdGFuZCB0aGluZ3MgY29ycmVjdGx5LCB0aGVyZSB3YXMgYSBjYXNlIHdo
ZXJlICdlbmQnDQo+IGNvdWxkIGJlIHNtYWxsZXIgdGhhbiAnc3RhcnQnIHdoZW4gZG9pbmcgYSBy
YW5nZSBmbHVzaC4gIFRoYXQgd291bGQNCj4gZGVmaW5pdGVseSBraWxsIHNvbWUgb2YgdGhlIHNw
YXJjNjQgVExCIGZsdXNoIHJvdXRpbmVzLg0KDQpPaywgdGhhbmtzLg0KDQpUaGUgcGF0Y2ggYXQg
dGhlIGJlZ2lubmluZyBvZiB0aGlzIHRocmVhZCBkb2Vzbid0IGhhdmUgdGhhdCBiZWhhdmlvcg0K
dGhvdWdoIGFuZCBpdCBhcHBhcmVudGx5IHN0aWxsIGh1bmcuIEkgYXNrZWQgaWYgTWVlbGlzIGNv
dWxkIHRlc3Qgd2l0aA0KdGhpcyBmZWF0dXJlIGRpc2FibGVkIGFuZCBERUJVR19QQUdFQUxMT0Mg
b24sIHNpbmNlIGl0IGZsdXNoZXMgb24gZXZlcnkNCnZmcmVlIGFuZCBpcyBub3QgbmV3IGxvZ2lj
LCBhbmQgYWxzbyB3aXRoIGEgcGF0Y2ggdGhhdCBsb2dzIGV4YWN0IFRMQg0KZmx1c2ggcmFuZ2Vz
IGFuZCBmYXVsdCBhZGRyZXNzZXMgb24gdG9wIG9mIHRoZSBrZXJuZWwgaGF2aW5nIHRoaXMNCmlz
c3VlLiBIb3BlZnVsbHkgdGhhdCB3aWxsIHNoZWQgc29tZSBsaWdodC4NCg0KU29ycnkgZm9yIGFs
bCB0aGUgbm9pc2UgYW5kIHNwZWN1bGF0aW9uIG9uIHRoaXMuIEl0IGhhcyBiZWVuIGRpZmZpY3Vs
dA0KdG8gZGVidWcgcmVtb3RlbHkgd2l0aCBhIHRlc3RlciBhbmQgZGV2ZWxvcGVyIGluIGRpZmZl
cmVudCB0aW1lIHpvbmVzLg0KDQoNCg=

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-22 19:26                     ` Edgecombe, Rick P
@ 2019-05-22 22:40                       ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-22 22:40 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> > Date: Tue, 21 May 2019 01:59:54 +0000
> > 
> > > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > > From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> > > > Date: Tue, 21 May 2019 01:20:33 +0000
> > > > 
> > > > > Should it handle executing an unmapped page gracefully?
> > > > > Because
> > > > > this
> > > > > change is causing that to happen much earlier. If something
> > > > > was
> > > > > relying
> > > > > on a cached translation to execute something it could find
> > > > > the
> > > > > mapping
> > > > > disappear.
> > > > 
> > > > Does this work by not mapping any kernel mappings at the
> > > > beginning,
> > > > and then filling in the BPF mappings in response to faults?
> > > No, nothing too fancy. It just flushes the vm mapping immediatly
> > > in
> > > vfree for execute (and RO) mappings. The only thing that happens
> > > around
> > > allocation time is setting of a new flag to tell vmalloc to do
> > > the
> > > flush.
> > > 
> > > The problem before was that the pages would be freed before the
> > > execute
> > > mapping was flushed. So then when the pages got recycled, random,
> > > sometimes coming from userspace, data would be mapped as
> > > executable
> > > in
> > > the kernel by the un-flushed tlb entries.
> > 
> > If I am to understand things correctly, there was a case where
> > 'end'
> > could be smaller than 'start' when doing a range flush.  That would
> > definitely kill some of the sparc64 TLB flush routines.
> 
> Ok, thanks.
> 
> The patch at the beginning of this thread doesn't have that behavior
> though and it apparently still hung. I asked if Meelis could test
> with
> this feature disabled and DEBUG_PAGEALLOC on, since it flushes on
> every
> vfree and is not new logic, and also with a patch that logs exact TLB
> flush ranges and fault addresses on top of the kernel having this
> issue. Hopefully that will shed some light.
> 
> Sorry for all the noise and speculation on this. It has been
> difficult
> to debug remotely with a tester and developer in different time
> zones.
> 
> 
Ok, so with a patch to disable setting the new vmalloc flush flag on
architectures that have normal memory as executable (includes sparc),
boot succeeds.

With this disable patch and DEBUG_PAGEALLOC on, it hangs earlier than
before. Going from clues in other logs, it looks like it hangs right at
the first normal vfree.

Thanks for all the testing Meelis!

So it seems like other, not new, TLB flushes also trigger the hang.

From earlier logs provided, this vfree would be the first call to
flush_tlb_kernel_range(), and before any BPF allocations appear in the
logs. So I am suspecting some other cause than the bisected patch at
this point, but I guess it's not fully conclusive.

It could be informative to bisect upstream again with the
DEBUG_PAGEALLOC configs on, to see if it indeed points to an earlier
commit.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-22 22:40                       ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-22 22:40 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

T24gV2VkLCAyMDE5LTA1LTIyIGF0IDEyOjI2IC0wNzAwLCBSaWNrIEVkZ2Vjb21iZSB3cm90ZToN
Cj4gT24gV2VkLCAyMDE5LTA1LTIyIGF0IDEwOjQwIC0wNzAwLCBEYXZpZCBNaWxsZXIgd3JvdGU6
DQo+ID4gRnJvbTogIkVkZ2Vjb21iZSwgUmljayBQIiA8cmljay5wLmVkZ2Vjb21iZUBpbnRlbC5j
b20+DQo+ID4gRGF0ZTogVHVlLCAyMSBNYXkgMjAxOSAwMTo1OTo1NCArMDAwMA0KPiA+IA0KPiA+
ID4gT24gTW9uLCAyMDE5LTA1LTIwIGF0IDE4OjQzIC0wNzAwLCBEYXZpZCBNaWxsZXIgd3JvdGU6
DQo+ID4gPiA+IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2sucC5lZGdlY29tYmVAaW50
ZWwuY29tPg0KPiA+ID4gPiBEYXRlOiBUdWUsIDIxIE1heSAyMDE5IDAxOjIwOjMzICswMDAwDQo+
ID4gPiA+IA0KPiA+ID4gPiA+IFNob3VsZCBpdCBoYW5kbGUgZXhlY3V0aW5nIGFuIHVubWFwcGVk
IHBhZ2UgZ3JhY2VmdWxseT8NCj4gPiA+ID4gPiBCZWNhdXNlDQo+ID4gPiA+ID4gdGhpcw0KPiA+
ID4gPiA+IGNoYW5nZSBpcyBjYXVzaW5nIHRoYXQgdG8gaGFwcGVuIG11Y2ggZWFybGllci4gSWYg
c29tZXRoaW5nDQo+ID4gPiA+ID4gd2FzDQo+ID4gPiA+ID4gcmVseWluZw0KPiA+ID4gPiA+IG9u
IGEgY2FjaGVkIHRyYW5zbGF0aW9uIHRvIGV4ZWN1dGUgc29tZXRoaW5nIGl0IGNvdWxkIGZpbmQN
Cj4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiBtYXBwaW5nDQo+ID4gPiA+ID4gZGlzYXBwZWFyLg0K
PiA+ID4gPiANCj4gPiA+ID4gRG9lcyB0aGlzIHdvcmsgYnkgbm90IG1hcHBpbmcgYW55IGtlcm5l
bCBtYXBwaW5ncyBhdCB0aGUNCj4gPiA+ID4gYmVnaW5uaW5nLA0KPiA+ID4gPiBhbmQgdGhlbiBm
aWxsaW5nIGluIHRoZSBCUEYgbWFwcGluZ3MgaW4gcmVzcG9uc2UgdG8gZmF1bHRzPw0KPiA+ID4g
Tm8sIG5vdGhpbmcgdG9vIGZhbmN5LiBJdCBqdXN0IGZsdXNoZXMgdGhlIHZtIG1hcHBpbmcgaW1t
ZWRpYXRseQ0KPiA+ID4gaW4NCj4gPiA+IHZmcmVlIGZvciBleGVjdXRlIChhbmQgUk8pIG1hcHBp
bmdzLiBUaGUgb25seSB0aGluZyB0aGF0IGhhcHBlbnMNCj4gPiA+IGFyb3VuZA0KPiA+ID4gYWxs
b2NhdGlvbiB0aW1lIGlzIHNldHRpbmcgb2YgYSBuZXcgZmxhZyB0byB0ZWxsIHZtYWxsb2MgdG8g
ZG8NCj4gPiA+IHRoZQ0KPiA+ID4gZmx1c2guDQo+ID4gPiANCj4gPiA+IFRoZSBwcm9ibGVtIGJl
Zm9yZSB3YXMgdGhhdCB0aGUgcGFnZXMgd291bGQgYmUgZnJlZWQgYmVmb3JlIHRoZQ0KPiA+ID4g
ZXhlY3V0ZQ0KPiA+ID4gbWFwcGluZyB3YXMgZmx1c2hlZC4gU28gdGhlbiB3aGVuIHRoZSBwYWdl
cyBnb3QgcmVjeWNsZWQsIHJhbmRvbSwNCj4gPiA+IHNvbWV0aW1lcyBjb21pbmcgZnJvbSB1c2Vy
c3BhY2UsIGRhdGEgd291bGQgYmUgbWFwcGVkIGFzDQo+ID4gPiBleGVjdXRhYmxlDQo+ID4gPiBp
bg0KPiA+ID4gdGhlIGtlcm5lbCBieSB0aGUgdW4tZmx1c2hlZCB0bGIgZW50cmllcy4NCj4gPiAN
Cj4gPiBJZiBJIGFtIHRvIHVuZGVyc3RhbmQgdGhpbmdzIGNvcnJlY3RseSwgdGhlcmUgd2FzIGEg
Y2FzZSB3aGVyZQ0KPiA+ICdlbmQnDQo+ID4gY291bGQgYmUgc21hbGxlciB0aGFuICdzdGFydCcg
d2hlbiBkb2luZyBhIHJhbmdlIGZsdXNoLiAgVGhhdCB3b3VsZA0KPiA+IGRlZmluaXRlbHkga2ls
bCBzb21lIG9mIHRoZSBzcGFyYzY0IFRMQiBmbHVzaCByb3V0aW5lcy4NCj4gDQo+IE9rLCB0aGFu
a3MuDQo+IA0KPiBUaGUgcGF0Y2ggYXQgdGhlIGJlZ2lubmluZyBvZiB0aGlzIHRocmVhZCBkb2Vz
bid0IGhhdmUgdGhhdCBiZWhhdmlvcg0KPiB0aG91Z2ggYW5kIGl0IGFwcGFyZW50bHkgc3RpbGwg
aHVuZy4gSSBhc2tlZCBpZiBNZWVsaXMgY291bGQgdGVzdA0KPiB3aXRoDQo+IHRoaXMgZmVhdHVy
ZSBkaXNhYmxlZCBhbmQgREVCVUdfUEFHRUFMTE9DIG9uLCBzaW5jZSBpdCBmbHVzaGVzIG9uDQo+
IGV2ZXJ5DQo+IHZmcmVlIGFuZCBpcyBub3QgbmV3IGxvZ2ljLCBhbmQgYWxzbyB3aXRoIGEgcGF0
Y2ggdGhhdCBsb2dzIGV4YWN0IFRMQg0KPiBmbHVzaCByYW5nZXMgYW5kIGZhdWx0IGFkZHJlc3Nl
cyBvbiB0b3Agb2YgdGhlIGtlcm5lbCBoYXZpbmcgdGhpcw0KPiBpc3N1ZS4gSG9wZWZ1bGx5IHRo
YXQgd2lsbCBzaGVkIHNvbWUgbGlnaHQuDQo+IA0KPiBTb3JyeSBmb3IgYWxsIHRoZSBub2lzZSBh
bmQgc3BlY3VsYXRpb24gb24gdGhpcy4gSXQgaGFzIGJlZW4NCj4gZGlmZmljdWx0DQo+IHRvIGRl
YnVnIHJlbW90ZWx5IHdpdGggYSB0ZXN0ZXIgYW5kIGRldmVsb3BlciBpbiBkaWZmZXJlbnQgdGlt
ZQ0KPiB6b25lcy4NCj4gDQo+IA0KT2ssIHNvIHdpdGggYSBwYXRjaCB0byBkaXNhYmxlIHNldHRp
bmcgdGhlIG5ldyB2bWFsbG9jIGZsdXNoIGZsYWcgb24NCmFyY2hpdGVjdHVyZXMgdGhhdCBoYXZl
IG5vcm1hbCBtZW1vcnkgYXMgZXhlY3V0YWJsZSAoaW5jbHVkZXMgc3BhcmMpLA0KYm9vdCBzdWNj
ZWVkcy4NCg0KV2l0aCB0aGlzIGRpc2FibGUgcGF0Y2ggYW5kIERFQlVHX1BBR0VBTExPQyBvbiwg
aXQgaGFuZ3MgZWFybGllciB0aGFuDQpiZWZvcmUuIEdvaW5nIGZyb20gY2x1ZXMgaW4gb3RoZXIg
bG9ncywgaXQgbG9va3MgbGlrZSBpdCBoYW5ncyByaWdodCBhdA0KdGhlIGZpcnN0IG5vcm1hbCB2
ZnJlZS4NCg0KVGhhbmtzIGZvciBhbGwgdGhlIHRlc3RpbmcgTWVlbGlzIQ0KDQpTbyBpdCBzZWVt
cyBsaWtlIG90aGVyLCBub3QgbmV3LCBUTEIgZmx1c2hlcyBhbHNvIHRyaWdnZXIgdGhlIGhhbmcu
DQoNCkZyb20gZWFybGllciBsb2dzIHByb3ZpZGVkLCB0aGlzIHZmcmVlIHdvdWxkIGJlIHRoZSBm
aXJzdCBjYWxsIHRvDQpmbHVzaF90bGJfa2VybmVsX3JhbmdlKCksIGFuZCBiZWZvcmUgYW55IEJQ
RiBhbGxvY2F0aW9ucyBhcHBlYXIgaW4gdGhlDQpsb2dzLiBTbyBJIGFtIHN1c3BlY3Rpbmcgc29t
ZSBvdGhlciBjYXVzZSB0aGFuIHRoZSBiaXNlY3RlZCBwYXRjaCBhdA0KdGhpcyBwb2ludCwgYnV0
IEkgZ3Vlc3MgaXQncyBub3QgZnVsbHkgY29uY2x1c2l2ZS4NCg0KSXQgY291bGQgYmUgaW5mb3Jt
YXRpdmUgdG8gYmlzZWN0IHVwc3RyZWFtIGFnYWluIHdpdGggdGhlDQpERUJVR19QQUdFQUxMT0Mg
Y29uZmlncyBvbiwgdG8gc2VlIGlmIGl0IGluZGVlZCBwb2ludHMgdG8gYW4gZWFybGllcg0KY29t
bWl0Lg0K

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
  2019-05-22 22:40                       ` Edgecombe, Rick P
@ 2019-05-24 15:50                         ` Edgecombe, Rick P
  -1 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-24 15:50 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

On Wed, 2019-05-22 at 15:40 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> > On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > > From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> > > Date: Tue, 21 May 2019 01:59:54 +0000
> > > 
> > > > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > > > From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
> > > > > Date: Tue, 21 May 2019 01:20:33 +0000
> > > > > 
> > > > > > Should it handle executing an unmapped page gracefully?
> > > > > > Because
> > > > > > this
> > > > > > change is causing that to happen much earlier. If something
> > > > > > was
> > > > > > relying
> > > > > > on a cached translation to execute something it could find
> > > > > > the
> > > > > > mapping
> > > > > > disappear.
> > > > > 
> > > > > Does this work by not mapping any kernel mappings at the
> > > > > beginning,
> > > > > and then filling in the BPF mappings in response to faults?
> > > > No, nothing too fancy. It just flushes the vm mapping
> > > > immediatly
> > > > in
> > > > vfree for execute (and RO) mappings. The only thing that
> > > > happens
> > > > around
> > > > allocation time is setting of a new flag to tell vmalloc to do
> > > > the
> > > > flush.
> > > > 
> > > > The problem before was that the pages would be freed before the
> > > > execute
> > > > mapping was flushed. So then when the pages got recycled,
> > > > random,
> > > > sometimes coming from userspace, data would be mapped as
> > > > executable
> > > > in
> > > > the kernel by the un-flushed tlb entries.
> > > 
> > > If I am to understand things correctly, there was a case where
> > > 'end'
> > > could be smaller than 'start' when doing a range flush.  That
> > > would
> > > definitely kill some of the sparc64 TLB flush routines.
> > 
> > Ok, thanks.
> > 
> > The patch at the beginning of this thread doesn't have that
> > behavior
> > though and it apparently still hung. I asked if Meelis could test
> > with
> > this feature disabled and DEBUG_PAGEALLOC on, since it flushes on
> > every
> > vfree and is not new logic, and also with a patch that logs exact
> > TLB
> > flush ranges and fault addresses on top of the kernel having this
> > issue. Hopefully that will shed some light.
> > 
> > Sorry for all the noise and speculation on this. It has been
> > difficult
> > to debug remotely with a tester and developer in different time
> > zones.
> > 
> > 
> Ok, so with a patch to disable setting the new vmalloc flush flag on
> architectures that have normal memory as executable (includes sparc),
> boot succeeds.
> 
> With this disable patch and DEBUG_PAGEALLOC on, it hangs earlier than
> before. Going from clues in other logs, it looks like it hangs right
> at
> the first normal vfree.
> 
> Thanks for all the testing Meelis!
> 
> So it seems like other, not new, TLB flushes also trigger the hang.
> 
> From earlier logs provided, this vfree would be the first call to
> flush_tlb_kernel_range(), and before any BPF allocations appear in
> the
> logs. So I am suspecting some other cause than the bisected patch at
> this point, but I guess it's not fully conclusive.
> 
> It could be informative to bisect upstream again with the
> DEBUG_PAGEALLOC configs on, to see if it indeed points to an earlier
> commit.

So now Meelis has found that the commit before any of my vmalloc
changes also hangs during boot with DEBUG_PAGEALLOC on. It does this
shortly after the first vfree, which DEBUG_PAGEALLOC would of course
make trigger a flush_tlb_kernel_range() on the allocation just like my
vmalloc changes do on certain vmallocs. The upstream code calls
vm_unmap_aliases() instead of the flush_tlb_kernel_range() directly,
but we also tested a version that called the flush directly on just the
allocation and it also hung. So it seems like issues flushing vmallocs
on this platform exist outside my commits.

How do people feel about calling this a sparc specific issue uncovered
by my patch instead of caused by it at this point?

If people agree with this assesment, it of course still seems like the
new changes turn the root cause into a more impactful issue for this
specific combination. On the other hand I am not the right person to
fix the root cause for several reasons including no hardware access. 

Otherwise I could submit a patch to disable this for sparc since it
doesn't really get a security benefit from it anyway. What do people
think?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: [PATCH v2] vmalloc: Fix issues with flush flag
@ 2019-05-24 15:50                         ` Edgecombe, Rick P
  0 siblings, 0 replies; 30+ messages in thread
From: Edgecombe, Rick P @ 2019-05-24 15:50 UTC (permalink / raw)
  To: davem
  Cc: linux-kernel, peterz, linux-mm, mroos, mingo, namit, luto, bp,
	netdev, Hansen, Dave, sparclinux

T24gV2VkLCAyMDE5LTA1LTIyIGF0IDE1OjQwIC0wNzAwLCBSaWNrIEVkZ2Vjb21iZSB3cm90ZToN
Cj4gT24gV2VkLCAyMDE5LTA1LTIyIGF0IDEyOjI2IC0wNzAwLCBSaWNrIEVkZ2Vjb21iZSB3cm90
ZToNCj4gPiBPbiBXZWQsIDIwMTktMDUtMjIgYXQgMTA6NDAgLTA3MDAsIERhdmlkIE1pbGxlciB3
cm90ZToNCj4gPiA+IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2sucC5lZGdlY29tYmVA
aW50ZWwuY29tPg0KPiA+ID4gRGF0ZTogVHVlLCAyMSBNYXkgMjAxOSAwMTo1OTo1NCArMDAwMA0K
PiA+ID4gDQo+ID4gPiA+IE9uIE1vbiwgMjAxOS0wNS0yMCBhdCAxODo0MyAtMDcwMCwgRGF2aWQg
TWlsbGVyIHdyb3RlOg0KPiA+ID4gPiA+IEZyb206ICJFZGdlY29tYmUsIFJpY2sgUCIgPHJpY2su
cC5lZGdlY29tYmVAaW50ZWwuY29tPg0KPiA+ID4gPiA+IERhdGU6IFR1ZSwgMjEgTWF5IDIwMTkg
MDE6MjA6MzMgKzAwMDANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IFNob3VsZCBpdCBoYW5kbGUg
ZXhlY3V0aW5nIGFuIHVubWFwcGVkIHBhZ2UgZ3JhY2VmdWxseT8NCj4gPiA+ID4gPiA+IEJlY2F1
c2UNCj4gPiA+ID4gPiA+IHRoaXMNCj4gPiA+ID4gPiA+IGNoYW5nZSBpcyBjYXVzaW5nIHRoYXQg
dG8gaGFwcGVuIG11Y2ggZWFybGllci4gSWYgc29tZXRoaW5nDQo+ID4gPiA+ID4gPiB3YXMNCj4g
PiA+ID4gPiA+IHJlbHlpbmcNCj4gPiA+ID4gPiA+IG9uIGEgY2FjaGVkIHRyYW5zbGF0aW9uIHRv
IGV4ZWN1dGUgc29tZXRoaW5nIGl0IGNvdWxkIGZpbmQNCj4gPiA+ID4gPiA+IHRoZQ0KPiA+ID4g
PiA+ID4gbWFwcGluZw0KPiA+ID4gPiA+ID4gZGlzYXBwZWFyLg0KPiA+ID4gPiA+IA0KPiA+ID4g
PiA+IERvZXMgdGhpcyB3b3JrIGJ5IG5vdCBtYXBwaW5nIGFueSBrZXJuZWwgbWFwcGluZ3MgYXQg
dGhlDQo+ID4gPiA+ID4gYmVnaW5uaW5nLA0KPiA+ID4gPiA+IGFuZCB0aGVuIGZpbGxpbmcgaW4g
dGhlIEJQRiBtYXBwaW5ncyBpbiByZXNwb25zZSB0byBmYXVsdHM/DQo+ID4gPiA+IE5vLCBub3Ro
aW5nIHRvbyBmYW5jeS4gSXQganVzdCBmbHVzaGVzIHRoZSB2bSBtYXBwaW5nDQo+ID4gPiA+IGlt
bWVkaWF0bHkNCj4gPiA+ID4gaW4NCj4gPiA+ID4gdmZyZWUgZm9yIGV4ZWN1dGUgKGFuZCBSTykg
bWFwcGluZ3MuIFRoZSBvbmx5IHRoaW5nIHRoYXQNCj4gPiA+ID4gaGFwcGVucw0KPiA+ID4gPiBh
cm91bmQNCj4gPiA+ID4gYWxsb2NhdGlvbiB0aW1lIGlzIHNldHRpbmcgb2YgYSBuZXcgZmxhZyB0
byB0ZWxsIHZtYWxsb2MgdG8gZG8NCj4gPiA+ID4gdGhlDQo+ID4gPiA+IGZsdXNoLg0KPiA+ID4g
PiANCj4gPiA+ID4gVGhlIHByb2JsZW0gYmVmb3JlIHdhcyB0aGF0IHRoZSBwYWdlcyB3b3VsZCBi
ZSBmcmVlZCBiZWZvcmUgdGhlDQo+ID4gPiA+IGV4ZWN1dGUNCj4gPiA+ID4gbWFwcGluZyB3YXMg
Zmx1c2hlZC4gU28gdGhlbiB3aGVuIHRoZSBwYWdlcyBnb3QgcmVjeWNsZWQsDQo+ID4gPiA+IHJh
bmRvbSwNCj4gPiA+ID4gc29tZXRpbWVzIGNvbWluZyBmcm9tIHVzZXJzcGFjZSwgZGF0YSB3b3Vs
ZCBiZSBtYXBwZWQgYXMNCj4gPiA+ID4gZXhlY3V0YWJsZQ0KPiA+ID4gPiBpbg0KPiA+ID4gPiB0
aGUga2VybmVsIGJ5IHRoZSB1bi1mbHVzaGVkIHRsYiBlbnRyaWVzLg0KPiA+ID4gDQo+ID4gPiBJ
ZiBJIGFtIHRvIHVuZGVyc3RhbmQgdGhpbmdzIGNvcnJlY3RseSwgdGhlcmUgd2FzIGEgY2FzZSB3
aGVyZQ0KPiA+ID4gJ2VuZCcNCj4gPiA+IGNvdWxkIGJlIHNtYWxsZXIgdGhhbiAnc3RhcnQnIHdo
ZW4gZG9pbmcgYSByYW5nZSBmbHVzaC4gIFRoYXQNCj4gPiA+IHdvdWxkDQo+ID4gPiBkZWZpbml0
ZWx5IGtpbGwgc29tZSBvZiB0aGUgc3BhcmM2NCBUTEIgZmx1c2ggcm91dGluZXMuDQo+ID4gDQo+
ID4gT2ssIHRoYW5rcy4NCj4gPiANCj4gPiBUaGUgcGF0Y2ggYXQgdGhlIGJlZ2lubmluZyBvZiB0
aGlzIHRocmVhZCBkb2Vzbid0IGhhdmUgdGhhdA0KPiA+IGJlaGF2aW9yDQo+ID4gdGhvdWdoIGFu
ZCBpdCBhcHBhcmVudGx5IHN0aWxsIGh1bmcuIEkgYXNrZWQgaWYgTWVlbGlzIGNvdWxkIHRlc3QN
Cj4gPiB3aXRoDQo+ID4gdGhpcyBmZWF0dXJlIGRpc2FibGVkIGFuZCBERUJVR19QQUdFQUxMT0Mg
b24sIHNpbmNlIGl0IGZsdXNoZXMgb24NCj4gPiBldmVyeQ0KPiA+IHZmcmVlIGFuZCBpcyBub3Qg
bmV3IGxvZ2ljLCBhbmQgYWxzbyB3aXRoIGEgcGF0Y2ggdGhhdCBsb2dzIGV4YWN0DQo+ID4gVExC
DQo+ID4gZmx1c2ggcmFuZ2VzIGFuZCBmYXVsdCBhZGRyZXNzZXMgb24gdG9wIG9mIHRoZSBrZXJu
ZWwgaGF2aW5nIHRoaXMNCj4gPiBpc3N1ZS4gSG9wZWZ1bGx5IHRoYXQgd2lsbCBzaGVkIHNvbWUg
bGlnaHQuDQo+ID4gDQo+ID4gU29ycnkgZm9yIGFsbCB0aGUgbm9pc2UgYW5kIHNwZWN1bGF0aW9u
IG9uIHRoaXMuIEl0IGhhcyBiZWVuDQo+ID4gZGlmZmljdWx0DQo+ID4gdG8gZGVidWcgcmVtb3Rl
bHkgd2l0aCBhIHRlc3RlciBhbmQgZGV2ZWxvcGVyIGluIGRpZmZlcmVudCB0aW1lDQo+ID4gem9u
ZXMuDQo+ID4gDQo+ID4gDQo+IE9rLCBzbyB3aXRoIGEgcGF0Y2ggdG8gZGlzYWJsZSBzZXR0aW5n
IHRoZSBuZXcgdm1hbGxvYyBmbHVzaCBmbGFnIG9uDQo+IGFyY2hpdGVjdHVyZXMgdGhhdCBoYXZl
IG5vcm1hbCBtZW1vcnkgYXMgZXhlY3V0YWJsZSAoaW5jbHVkZXMgc3BhcmMpLA0KPiBib290IHN1
Y2NlZWRzLg0KPiANCj4gV2l0aCB0aGlzIGRpc2FibGUgcGF0Y2ggYW5kIERFQlVHX1BBR0VBTExP
QyBvbiwgaXQgaGFuZ3MgZWFybGllciB0aGFuDQo+IGJlZm9yZS4gR29pbmcgZnJvbSBjbHVlcyBp
biBvdGhlciBsb2dzLCBpdCBsb29rcyBsaWtlIGl0IGhhbmdzIHJpZ2h0DQo+IGF0DQo+IHRoZSBm
aXJzdCBub3JtYWwgdmZyZWUuDQo+IA0KPiBUaGFua3MgZm9yIGFsbCB0aGUgdGVzdGluZyBNZWVs
aXMhDQo+IA0KPiBTbyBpdCBzZWVtcyBsaWtlIG90aGVyLCBub3QgbmV3LCBUTEIgZmx1c2hlcyBh
bHNvIHRyaWdnZXIgdGhlIGhhbmcuDQo+IA0KPiBGcm9tIGVhcmxpZXIgbG9ncyBwcm92aWRlZCwg
dGhpcyB2ZnJlZSB3b3VsZCBiZSB0aGUgZmlyc3QgY2FsbCB0bw0KPiBmbHVzaF90bGJfa2VybmVs
X3JhbmdlKCksIGFuZCBiZWZvcmUgYW55IEJQRiBhbGxvY2F0aW9ucyBhcHBlYXIgaW4NCj4gdGhl
DQo+IGxvZ3MuIFNvIEkgYW0gc3VzcGVjdGluZyBzb21lIG90aGVyIGNhdXNlIHRoYW4gdGhlIGJp
c2VjdGVkIHBhdGNoIGF0DQo+IHRoaXMgcG9pbnQsIGJ1dCBJIGd1ZXNzIGl0J3Mgbm90IGZ1bGx5
IGNvbmNsdXNpdmUuDQo+IA0KPiBJdCBjb3VsZCBiZSBpbmZvcm1hdGl2ZSB0byBiaXNlY3QgdXBz
dHJlYW0gYWdhaW4gd2l0aCB0aGUNCj4gREVCVUdfUEFHRUFMTE9DIGNvbmZpZ3Mgb24sIHRvIHNl
ZSBpZiBpdCBpbmRlZWQgcG9pbnRzIHRvIGFuIGVhcmxpZXINCj4gY29tbWl0Lg0KDQpTbyBub3cg
TWVlbGlzIGhhcyBmb3VuZCB0aGF0IHRoZSBjb21taXQgYmVmb3JlIGFueSBvZiBteSB2bWFsbG9j
DQpjaGFuZ2VzIGFsc28gaGFuZ3MgZHVyaW5nIGJvb3Qgd2l0aCBERUJVR19QQUdFQUxMT0Mgb24u
IEl0IGRvZXMgdGhpcw0Kc2hvcnRseSBhZnRlciB0aGUgZmlyc3QgdmZyZWUsIHdoaWNoIERFQlVH
X1BBR0VBTExPQyB3b3VsZCBvZiBjb3Vyc2UNCm1ha2UgdHJpZ2dlciBhIGZsdXNoX3RsYl9rZXJu
ZWxfcmFuZ2UoKSBvbiB0aGUgYWxsb2NhdGlvbiBqdXN0IGxpa2UgbXkNCnZtYWxsb2MgY2hhbmdl
cyBkbyBvbiBjZXJ0YWluIHZtYWxsb2NzLiBUaGUgdXBzdHJlYW0gY29kZSBjYWxscw0Kdm1fdW5t
YXBfYWxpYXNlcygpIGluc3RlYWQgb2YgdGhlIGZsdXNoX3RsYl9rZXJuZWxfcmFuZ2UoKSBkaXJl
Y3RseSwNCmJ1dCB3ZSBhbHNvIHRlc3RlZCBhIHZlcnNpb24gdGhhdCBjYWxsZWQgdGhlIGZsdXNo
IGRpcmVjdGx5IG9uIGp1c3QgdGhlDQphbGxvY2F0aW9uIGFuZCBpdCBhbHNvIGh1bmcuIFNvIGl0
IHNlZW1zIGxpa2UgaXNzdWVzIGZsdXNoaW5nIHZtYWxsb2NzDQpvbiB0aGlzIHBsYXRmb3JtIGV4
aXN0IG91dHNpZGUgbXkgY29tbWl0cy4NCg0KSG93IGRvIHBlb3BsZSBmZWVsIGFib3V0IGNhbGxp
bmcgdGhpcyBhIHNwYXJjIHNwZWNpZmljIGlzc3VlIHVuY292ZXJlZA0KYnkgbXkgcGF0Y2ggaW5z
dGVhZCBvZiBjYXVzZWQgYnkgaXQgYXQgdGhpcyBwb2ludD8NCg0KSWYgcGVvcGxlIGFncmVlIHdp
dGggdGhpcyBhc3Nlc21lbnQsIGl0IG9mIGNvdXJzZSBzdGlsbCBzZWVtcyBsaWtlIHRoZQ0KbmV3
IGNoYW5nZXMgdHVybiB0aGUgcm9vdCBjYXVzZSBpbnRvIGEgbW9yZSBpbXBhY3RmdWwgaXNzdWUg
Zm9yIHRoaXMNCnNwZWNpZmljIGNvbWJpbmF0aW9uLiBPbiB0aGUgb3RoZXIgaGFuZCBJIGFtIG5v
dCB0aGUgcmlnaHQgcGVyc29uIHRvDQpmaXggdGhlIHJvb3QgY2F1c2UgZm9yIHNldmVyYWwgcmVh
c29ucyBpbmNsdWRpbmcgbm8gaGFyZHdhcmUgYWNjZXNzLiANCg0KT3RoZXJ3aXNlIEkgY291bGQg
c3VibWl0IGEgcGF0Y2ggdG8gZGlzYWJsZSB0aGlzIGZvciBzcGFyYyBzaW5jZSBpdA0KZG9lc24n
dCByZWFsbHkgZ2V0IGEgc2VjdXJpdHkgYmVuZWZpdCBmcm9tIGl0IGFueXdheS4gV2hhdCBkbyBw
ZW9wbGUNCnRoaW5rPw0K

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2019-05-24 15:50 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-20 20:07 [PATCH v2] vmalloc: Fix issues with flush flag Rick Edgecombe
2019-05-20 20:07 ` Rick Edgecombe
2019-05-20 21:25 ` Andy Lutomirski
2019-05-20 21:25   ` Andy Lutomirski
2019-05-20 21:48   ` Edgecombe, Rick P
2019-05-20 21:48     ` Edgecombe, Rick P
2019-05-20 21:36 ` Meelis Roos
2019-05-20 21:36   ` Meelis Roos
2019-05-20 22:17   ` Edgecombe, Rick P
2019-05-20 22:17     ` Edgecombe, Rick P
2019-05-20 22:48     ` David Miller
2019-05-20 22:48       ` David Miller
2019-05-21  0:20       ` Edgecombe, Rick P
2019-05-21  0:20         ` Edgecombe, Rick P
2019-05-21  0:33         ` David Miller
2019-05-21  0:33           ` David Miller
2019-05-21  1:20           ` Edgecombe, Rick P
2019-05-21  1:20             ` Edgecombe, Rick P
2019-05-21  1:43             ` David Miller
2019-05-21  1:43               ` David Miller
2019-05-21  1:59               ` Edgecombe, Rick P
2019-05-21  1:59                 ` Edgecombe, Rick P
2019-05-22 17:40                 ` David Miller
2019-05-22 17:40                   ` David Miller
2019-05-22 19:26                   ` Edgecombe, Rick P
2019-05-22 19:26                     ` Edgecombe, Rick P
2019-05-22 22:40                     ` Edgecombe, Rick P
2019-05-22 22:40                       ` Edgecombe, Rick P
2019-05-24 15:50                       ` Edgecombe, Rick P
2019-05-24 15:50                         ` Edgecombe, Rick P

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.