linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap()
@ 2022-12-22 19:00 Uladzislau Rezki (Sony)
  2022-12-22 19:00 ` [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram() Uladzislau Rezki (Sony)
                   ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Uladzislau Rezki (Sony) @ 2022-12-22 19:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-mm, LKML, Baoquan He, Lorenzo Stoakes, Christoph Hellwig,
	Matthew Wilcox, Nicholas Piggin, Uladzislau Rezki,
	Oleksiy Avramchenko, Roman Gushchin

Currently the __vunmap() path calls __find_vmap_area() twice. Once on
entry to check that the area exists, then inside the remove_vm_area()
function which also performs a new search for the VA.

In order to improvie it from a performance point of view we split
remove_vm_area() into two new parts:
  - find_unlink_vmap_area() that does a search and unlink from tree;
  - __remove_vm_area() that removes without searching.

In this case there is no any functional change for remove_vm_area()
whereas vm_remove_mappings(), where a second search happens, switches
to the __remove_vm_area() variant where the already detached VA is
passed as a parameter, so there is no need to find it again.

Performance wise, i use test_vmalloc.sh with 32 threads doing alloc
free on a 64-CPUs-x86_64-box:

perf without this patch:
-   31.41%     0.50%  vmalloc_test/10  [kernel.vmlinux]    [k] __vunmap
   - 30.92% __vunmap
      - 17.67% _raw_spin_lock
           native_queued_spin_lock_slowpath
      - 12.33% remove_vm_area
         - 11.79% free_vmap_area_noflush
            - 11.18% _raw_spin_lock
                 native_queued_spin_lock_slowpath
        0.76% free_unref_page

perf with this patch:
-   11.35%     0.13%  vmalloc_test/14  [kernel.vmlinux]    [k] __vunmap
   - 11.23% __vunmap
      - 8.28% find_unlink_vmap_area
         - 7.95% _raw_spin_lock
              7.44% native_queued_spin_lock_slowpath
      - 1.93% free_vmap_area_noflush
         - 0.56% _raw_spin_lock
              0.53% native_queued_spin_lock_slowpath
        0.60% __vunmap_range_noflush

__vunmap() consumes around ~20% less CPU cycles on this test.

v2 -> v3:
- update commit message;
- rename the vm_remove_mappings() to the va_remove_mappings();
- move va-unlinking to the callers so the free_vmap_area_noflush()
  now expects a VA that has been disconnected;
- eliminate a local variable in the remove_vm_area().

Reported-by: Roman Gushchin <roman.gushchin@linux.dev>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
 mm/vmalloc.c | 77 ++++++++++++++++++++++++++++++++--------------------
 1 file changed, 47 insertions(+), 30 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 9e30f0b39203..eb91ecaa7277 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1815,9 +1815,9 @@ static void drain_vmap_area_work(struct work_struct *work)
 }
 
 /*
- * Free a vmap area, caller ensuring that the area has been unmapped
- * and flush_cache_vunmap had been called for the correct range
- * previously.
+ * Free a vmap area, caller ensuring that the area has been unmapped,
+ * unlinked and flush_cache_vunmap had been called for the correct
+ * range previously.
  */
 static void free_vmap_area_noflush(struct vmap_area *va)
 {
@@ -1825,9 +1825,8 @@ static void free_vmap_area_noflush(struct vmap_area *va)
 	unsigned long va_start = va->va_start;
 	unsigned long nr_lazy;
 
-	spin_lock(&vmap_area_lock);
-	unlink_va(va, &vmap_area_root);
-	spin_unlock(&vmap_area_lock);
+	if (WARN_ON_ONCE(!list_empty(&va->list)))
+		return;
 
 	nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >>
 				PAGE_SHIFT, &vmap_lazy_nr);
@@ -1871,6 +1870,19 @@ struct vmap_area *find_vmap_area(unsigned long addr)
 	return va;
 }
 
+static struct vmap_area *find_unlink_vmap_area(unsigned long addr)
+{
+	struct vmap_area *va;
+
+	spin_lock(&vmap_area_lock);
+	va = __find_vmap_area(addr, &vmap_area_root);
+	if (va)
+		unlink_va(va, &vmap_area_root);
+	spin_unlock(&vmap_area_lock);
+
+	return va;
+}
+
 /*** Per cpu kva allocator ***/
 
 /*
@@ -2015,6 +2027,10 @@ static void free_vmap_block(struct vmap_block *vb)
 	tmp = xa_erase(&vmap_blocks, addr_to_vb_idx(vb->va->va_start));
 	BUG_ON(tmp != vb);
 
+	spin_lock(&vmap_area_lock);
+	unlink_va(vb->va, &vmap_area_root);
+	spin_unlock(&vmap_area_lock);
+
 	free_vmap_area_noflush(vb->va);
 	kfree_rcu(vb, rcu_head);
 }
@@ -2591,6 +2607,20 @@ struct vm_struct *find_vm_area(const void *addr)
 	return va->vm;
 }
 
+static struct vm_struct *__remove_vm_area(struct vmap_area *va)
+{
+	struct vm_struct *vm;
+
+	if (!va || !va->vm)
+		return NULL;
+
+	vm = va->vm;
+	kasan_free_module_shadow(vm);
+	free_unmap_vmap_area(va);
+
+	return vm;
+}
+
 /**
  * remove_vm_area - find and remove a continuous kernel virtual area
  * @addr:	    base address
@@ -2603,26 +2633,10 @@ struct vm_struct *find_vm_area(const void *addr)
  */
 struct vm_struct *remove_vm_area(const void *addr)
 {
-	struct vmap_area *va;
-
 	might_sleep();
 
-	spin_lock(&vmap_area_lock);
-	va = __find_vmap_area((unsigned long)addr, &vmap_area_root);
-	if (va && va->vm) {
-		struct vm_struct *vm = va->vm;
-
-		va->vm = NULL;
-		spin_unlock(&vmap_area_lock);
-
-		kasan_free_module_shadow(vm);
-		free_unmap_vmap_area(va);
-
-		return vm;
-	}
-
-	spin_unlock(&vmap_area_lock);
-	return NULL;
+	return __remove_vm_area(
+		find_unlink_vmap_area((unsigned long) addr));
 }
 
 static inline void set_area_direct_map(const struct vm_struct *area,
@@ -2636,16 +2650,17 @@ static inline void set_area_direct_map(const struct vm_struct *area,
 			set_direct_map(area->pages[i]);
 }
 
-/* Handle removing and resetting vm mappings related to the vm_struct. */
-static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
+/* Handle removing and resetting vm mappings related to the VA's vm_struct. */
+static void va_remove_mappings(struct vmap_area *va, int deallocate_pages)
 {
+	struct vm_struct *area = va->vm;
 	unsigned long start = ULONG_MAX, end = 0;
 	unsigned int page_order = vm_area_page_order(area);
 	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
 	int flush_dmap = 0;
 	int i;
 
-	remove_vm_area(area->addr);
+	__remove_vm_area(va);
 
 	/* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */
 	if (!flush_reset)
@@ -2690,6 +2705,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
 static void __vunmap(const void *addr, int deallocate_pages)
 {
 	struct vm_struct *area;
+	struct vmap_area *va;
 
 	if (!addr)
 		return;
@@ -2698,19 +2714,20 @@ static void __vunmap(const void *addr, int deallocate_pages)
 			addr))
 		return;
 
-	area = find_vm_area(addr);
-	if (unlikely(!area)) {
+	va = find_unlink_vmap_area((unsigned long)addr);
+	if (unlikely(!va)) {
 		WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
 				addr);
 		return;
 	}
 
+	area = va->vm;
 	debug_check_no_locks_freed(area->addr, get_vm_area_size(area));
 	debug_check_no_obj_freed(area->addr, get_vm_area_size(area));
 
 	kasan_poison_vmalloc(area->addr, get_vm_area_size(area));
 
-	vm_remove_mappings(area, deallocate_pages);
+	va_remove_mappings(va, deallocate_pages);
 
 	if (deallocate_pages) {
 		int i;
-- 
2.30.2


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

* [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-22 19:00 [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Uladzislau Rezki (Sony)
@ 2022-12-22 19:00 ` Uladzislau Rezki (Sony)
  2022-12-23  8:21   ` Christoph Hellwig
  2022-12-22 19:00 ` [PATCH v3 3/3] mm: vmalloc: Replace BUG_ON() by WARN_ON_ONCE() Uladzislau Rezki (Sony)
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 14+ messages in thread
From: Uladzislau Rezki (Sony) @ 2022-12-22 19:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-mm, LKML, Baoquan He, Lorenzo Stoakes, Christoph Hellwig,
	Matthew Wilcox, Nicholas Piggin, Uladzislau Rezki,
	Oleksiy Avramchenko, Christoph Hellwig

Switch from find_vmap_area() to find_unlink_vmap_area() to prevent
a double access to the vmap_area_lock: one for finding area, second
time is for unlinking from a tree.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index eb91ecaa7277..70e5000b9d68 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2252,7 +2252,7 @@ void vm_unmap_ram(const void *mem, unsigned int count)
 		return;
 	}
 
-	va = find_vmap_area(addr);
+	va = find_unlink_vmap_area(addr);
 	BUG_ON(!va);
 	debug_check_no_locks_freed((void *)va->va_start,
 				    (va->va_end - va->va_start));
-- 
2.30.2


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

* [PATCH v3 3/3] mm: vmalloc: Replace BUG_ON() by WARN_ON_ONCE()
  2022-12-22 19:00 [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Uladzislau Rezki (Sony)
  2022-12-22 19:00 ` [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram() Uladzislau Rezki (Sony)
@ 2022-12-22 19:00 ` Uladzislau Rezki (Sony)
  2022-12-23  8:21   ` Christoph Hellwig
  2022-12-22 20:06 ` [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Lorenzo Stoakes
  2022-12-23  8:19 ` Christoph Hellwig
  3 siblings, 1 reply; 14+ messages in thread
From: Uladzislau Rezki (Sony) @ 2022-12-22 19:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-mm, LKML, Baoquan He, Lorenzo Stoakes, Christoph Hellwig,
	Matthew Wilcox, Nicholas Piggin, Uladzislau Rezki,
	Oleksiy Avramchenko

Currently a vm_unmap_ram() functions triggers a BUG() if an area
is not found. Replace it by the WARN_ON_ONCE() error message and
keep machine alive instead of stopping it.

The worst case is a memory leaking.

Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
 mm/vmalloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 70e5000b9d68..09a9b93b32ca 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2253,7 +2253,9 @@ void vm_unmap_ram(const void *mem, unsigned int count)
 	}
 
 	va = find_unlink_vmap_area(addr);
-	BUG_ON(!va);
+	if (WARN_ON_ONCE(!va))
+		return;
+
 	debug_check_no_locks_freed((void *)va->va_start,
 				    (va->va_end - va->va_start));
 	free_unmap_vmap_area(va);
-- 
2.30.2


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

* Re: [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap()
  2022-12-22 19:00 [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Uladzislau Rezki (Sony)
  2022-12-22 19:00 ` [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram() Uladzislau Rezki (Sony)
  2022-12-22 19:00 ` [PATCH v3 3/3] mm: vmalloc: Replace BUG_ON() by WARN_ON_ONCE() Uladzislau Rezki (Sony)
@ 2022-12-22 20:06 ` Lorenzo Stoakes
  2022-12-23 16:42   ` Uladzislau Rezki
  2022-12-23  8:19 ` Christoph Hellwig
  3 siblings, 1 reply; 14+ messages in thread
From: Lorenzo Stoakes @ 2022-12-22 20:06 UTC (permalink / raw)
  To: Uladzislau Rezki (Sony)
  Cc: Andrew Morton, linux-mm, LKML, Baoquan He, Christoph Hellwig,
	Matthew Wilcox, Nicholas Piggin, Oleksiy Avramchenko,
	Roman Gushchin

n Thu, Dec 22, 2022 at 08:00:20PM +0100, Uladzislau Rezki (Sony) wrote:
> Currently the __vunmap() path calls __find_vmap_area() twice. Once on
> entry to check that the area exists, then inside the remove_vm_area()
> function which also performs a new search for the VA.
>
> In order to improvie it from a performance point of view we split
> remove_vm_area() into two new parts:
>   - find_unlink_vmap_area() that does a search and unlink from tree;
>   - __remove_vm_area() that removes without searching.
>
> In this case there is no any functional change for remove_vm_area()
> whereas vm_remove_mappings(), where a second search happens, switches
> to the __remove_vm_area() variant where the already detached VA is
> passed as a parameter, so there is no need to find it again.
>
> Performance wise, i use test_vmalloc.sh with 32 threads doing alloc
> free on a 64-CPUs-x86_64-box:
>
> perf without this patch:
> -   31.41%     0.50%  vmalloc_test/10  [kernel.vmlinux]    [k] __vunmap
>    - 30.92% __vunmap
>       - 17.67% _raw_spin_lock
>            native_queued_spin_lock_slowpath
>       - 12.33% remove_vm_area
>          - 11.79% free_vmap_area_noflush
>             - 11.18% _raw_spin_lock
>                  native_queued_spin_lock_slowpath
>         0.76% free_unref_page
>
> perf with this patch:
> -   11.35%     0.13%  vmalloc_test/14  [kernel.vmlinux]    [k] __vunmap
>    - 11.23% __vunmap
>       - 8.28% find_unlink_vmap_area
>          - 7.95% _raw_spin_lock
>               7.44% native_queued_spin_lock_slowpath
>       - 1.93% free_vmap_area_noflush
>          - 0.56% _raw_spin_lock
>               0.53% native_queued_spin_lock_slowpath
>         0.60% __vunmap_range_noflush
>
> __vunmap() consumes around ~20% less CPU cycles on this test.
>
> v2 -> v3:
> - update commit message;
> - rename the vm_remove_mappings() to the va_remove_mappings();
> - move va-unlinking to the callers so the free_vmap_area_noflush()
>   now expects a VA that has been disconnected;
> - eliminate a local variable in the remove_vm_area().
>
> Reported-by: Roman Gushchin <roman.gushchin@linux.dev>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> ---
>  mm/vmalloc.c | 77 ++++++++++++++++++++++++++++++++--------------------
>  1 file changed, 47 insertions(+), 30 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 9e30f0b39203..eb91ecaa7277 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1815,9 +1815,9 @@ static void drain_vmap_area_work(struct work_struct *work)
>  }
>
>  /*
> - * Free a vmap area, caller ensuring that the area has been unmapped
> - * and flush_cache_vunmap had been called for the correct range
> - * previously.
> + * Free a vmap area, caller ensuring that the area has been unmapped,
> + * unlinked and flush_cache_vunmap had been called for the correct
> + * range previously.
>   */
>  static void free_vmap_area_noflush(struct vmap_area *va)
>  {
> @@ -1825,9 +1825,8 @@ static void free_vmap_area_noflush(struct vmap_area *va)
>  	unsigned long va_start = va->va_start;
>  	unsigned long nr_lazy;
>
> -	spin_lock(&vmap_area_lock);
> -	unlink_va(va, &vmap_area_root);
> -	spin_unlock(&vmap_area_lock);
> +	if (WARN_ON_ONCE(!list_empty(&va->list)))
> +		return;
>
>  	nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >>
>  				PAGE_SHIFT, &vmap_lazy_nr);
> @@ -1871,6 +1870,19 @@ struct vmap_area *find_vmap_area(unsigned long addr)
>  	return va;
>  }
>
> +static struct vmap_area *find_unlink_vmap_area(unsigned long addr)
> +{
> +	struct vmap_area *va;
> +
> +	spin_lock(&vmap_area_lock);
> +	va = __find_vmap_area(addr, &vmap_area_root);
> +	if (va)
> +		unlink_va(va, &vmap_area_root);
> +	spin_unlock(&vmap_area_lock);
> +
> +	return va;
> +}
> +
>  /*** Per cpu kva allocator ***/
>
>  /*
> @@ -2015,6 +2027,10 @@ static void free_vmap_block(struct vmap_block *vb)
>  	tmp = xa_erase(&vmap_blocks, addr_to_vb_idx(vb->va->va_start));
>  	BUG_ON(tmp != vb);
>
> +	spin_lock(&vmap_area_lock);
> +	unlink_va(vb->va, &vmap_area_root);
> +	spin_unlock(&vmap_area_lock);
> +
>  	free_vmap_area_noflush(vb->va);
>  	kfree_rcu(vb, rcu_head);
>  }
> @@ -2591,6 +2607,20 @@ struct vm_struct *find_vm_area(const void *addr)
>  	return va->vm;
>  }
>
> +static struct vm_struct *__remove_vm_area(struct vmap_area *va)
> +{
> +	struct vm_struct *vm;
> +
> +	if (!va || !va->vm)
> +		return NULL;
> +
> +	vm = va->vm;
> +	kasan_free_module_shadow(vm);
> +	free_unmap_vmap_area(va);
> +
> +	return vm;
> +}
> +
>  /**
>   * remove_vm_area - find and remove a continuous kernel virtual area
>   * @addr:	    base address
> @@ -2603,26 +2633,10 @@ struct vm_struct *find_vm_area(const void *addr)
>   */
>  struct vm_struct *remove_vm_area(const void *addr)
>  {
> -	struct vmap_area *va;
> -
>  	might_sleep();
>
> -	spin_lock(&vmap_area_lock);
> -	va = __find_vmap_area((unsigned long)addr, &vmap_area_root);
> -	if (va && va->vm) {
> -		struct vm_struct *vm = va->vm;
> -
> -		va->vm = NULL;
> -		spin_unlock(&vmap_area_lock);
> -
> -		kasan_free_module_shadow(vm);
> -		free_unmap_vmap_area(va);
> -
> -		return vm;
> -	}
> -
> -	spin_unlock(&vmap_area_lock);
> -	return NULL;
> +	return __remove_vm_area(
> +		find_unlink_vmap_area((unsigned long) addr));
>  }
>
>  static inline void set_area_direct_map(const struct vm_struct *area,
> @@ -2636,16 +2650,17 @@ static inline void set_area_direct_map(const struct vm_struct *area,
>  			set_direct_map(area->pages[i]);
>  }
>
> -/* Handle removing and resetting vm mappings related to the vm_struct. */
> -static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> +/* Handle removing and resetting vm mappings related to the VA's vm_struct. */
> +static void va_remove_mappings(struct vmap_area *va, int deallocate_pages)
>  {
> +	struct vm_struct *area = va->vm;
>  	unsigned long start = ULONG_MAX, end = 0;
>  	unsigned int page_order = vm_area_page_order(area);
>  	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
>  	int flush_dmap = 0;
>  	int i;
>
> -	remove_vm_area(area->addr);
> +	__remove_vm_area(va);
>
>  	/* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */
>  	if (!flush_reset)
> @@ -2690,6 +2705,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
>  static void __vunmap(const void *addr, int deallocate_pages)
>  {
>  	struct vm_struct *area;
> +	struct vmap_area *va;
>
>  	if (!addr)
>  		return;
> @@ -2698,19 +2714,20 @@ static void __vunmap(const void *addr, int deallocate_pages)
>  			addr))
>  		return;
>
> -	area = find_vm_area(addr);
> -	if (unlikely(!area)) {
> +	va = find_unlink_vmap_area((unsigned long)addr);
> +	if (unlikely(!va)) {
>  		WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
>  				addr);
>  		return;
>  	}
>
> +	area = va->vm;
>  	debug_check_no_locks_freed(area->addr, get_vm_area_size(area));
>  	debug_check_no_obj_freed(area->addr, get_vm_area_size(area));
>
>  	kasan_poison_vmalloc(area->addr, get_vm_area_size(area));
>
> -	vm_remove_mappings(area, deallocate_pages);
> +	va_remove_mappings(va, deallocate_pages);
>
>  	if (deallocate_pages) {
>  		int i;
> --
> 2.30.2
>

All looks good to me! Great work! Feel free to add the below to all patches in series:-

Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>

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

* Re: [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap()
  2022-12-22 19:00 [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Uladzislau Rezki (Sony)
                   ` (2 preceding siblings ...)
  2022-12-22 20:06 ` [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Lorenzo Stoakes
@ 2022-12-23  8:19 ` Christoph Hellwig
  2022-12-23 16:43   ` Uladzislau Rezki
  3 siblings, 1 reply; 14+ messages in thread
From: Christoph Hellwig @ 2022-12-23  8:19 UTC (permalink / raw)
  To: Uladzislau Rezki (Sony)
  Cc: Andrew Morton, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Christoph Hellwig, Matthew Wilcox, Nicholas Piggin,
	Oleksiy Avramchenko, Roman Gushchin

On Thu, Dec 22, 2022 at 08:00:20PM +0100, Uladzislau Rezki (Sony) wrote:
> @@ -1825,9 +1825,8 @@ static void free_vmap_area_noflush(struct vmap_area *va)
>  	unsigned long va_start = va->va_start;
>  	unsigned long nr_lazy;
>  
> -	spin_lock(&vmap_area_lock);
> -	unlink_va(va, &vmap_area_root);
> -	spin_unlock(&vmap_area_lock);
> +	if (WARN_ON_ONCE(!list_empty(&va->list)))
> +		return;

I'd just drop this check as the function is not exported.

Otherwise looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

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

* Re: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-22 19:00 ` [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram() Uladzislau Rezki (Sony)
@ 2022-12-23  8:21   ` Christoph Hellwig
  2022-12-23 16:41     ` Uladzislau Rezki
  0 siblings, 1 reply; 14+ messages in thread
From: Christoph Hellwig @ 2022-12-23  8:21 UTC (permalink / raw)
  To: Uladzislau Rezki (Sony)
  Cc: Andrew Morton, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Christoph Hellwig, Matthew Wilcox, Nicholas Piggin,
	Oleksiy Avramchenko, Christoph Hellwig

On Thu, Dec 22, 2022 at 08:00:21PM +0100, Uladzislau Rezki (Sony) wrote:
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2252,7 +2252,7 @@ void vm_unmap_ram(const void *mem, unsigned int count)
>  		return;
>  	}
>  
> -	va = find_vmap_area(addr);
> +	va = find_unlink_vmap_area(addr);
>  	BUG_ON(!va);
>  	debug_check_no_locks_freed((void *)va->va_start,
>  				    (va->va_end - va->va_start));

Don't we also need to remove the manual unlink that was done
here previously?   Actually it seems like that manual unlink is missing
after patch 1, creating a bisection hazard.  So either add it there,
or just fold this patch into the previous one.

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

* Re: [PATCH v3 3/3] mm: vmalloc: Replace BUG_ON() by WARN_ON_ONCE()
  2022-12-22 19:00 ` [PATCH v3 3/3] mm: vmalloc: Replace BUG_ON() by WARN_ON_ONCE() Uladzislau Rezki (Sony)
@ 2022-12-23  8:21   ` Christoph Hellwig
  0 siblings, 0 replies; 14+ messages in thread
From: Christoph Hellwig @ 2022-12-23  8:21 UTC (permalink / raw)
  To: Uladzislau Rezki (Sony)
  Cc: Andrew Morton, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Christoph Hellwig, Matthew Wilcox, Nicholas Piggin,
	Oleksiy Avramchenko

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

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

* Re: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-23  8:21   ` Christoph Hellwig
@ 2022-12-23 16:41     ` Uladzislau Rezki
  2022-12-28 23:47       ` Andrew Morton
  0 siblings, 1 reply; 14+ messages in thread
From: Uladzislau Rezki @ 2022-12-23 16:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Uladzislau Rezki (Sony),
	Andrew Morton, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Matthew Wilcox, Nicholas Piggin, Oleksiy Avramchenko,
	Christoph Hellwig

> On Thu, Dec 22, 2022 at 08:00:21PM +0100, Uladzislau Rezki (Sony) wrote:
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2252,7 +2252,7 @@ void vm_unmap_ram(const void *mem, unsigned int count)
> >  		return;
> >  	}
> >  
> > -	va = find_vmap_area(addr);
> > +	va = find_unlink_vmap_area(addr);
> >  	BUG_ON(!va);
> >  	debug_check_no_locks_freed((void *)va->va_start,
> >  				    (va->va_end - va->va_start));
> 
> Don't we also need to remove the manual unlink that was done
> here previously?   Actually it seems like that manual unlink is missing
> after patch 1, creating a bisection hazard.  So either add it there,
> or just fold this patch into the previous one.
>
Right. In terms of bisection it is not so good. I think folding is the
best.

Andrew, could you please fold this patch into the:

[PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() ?

or should i send a v4 instead?

Thank you in advance!

--
Uladzislau Rezki

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

* Re: [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap()
  2022-12-22 20:06 ` [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Lorenzo Stoakes
@ 2022-12-23 16:42   ` Uladzislau Rezki
  0 siblings, 0 replies; 14+ messages in thread
From: Uladzislau Rezki @ 2022-12-23 16:42 UTC (permalink / raw)
  To: Lorenzo Stoakes
  Cc: Uladzislau Rezki (Sony),
	Andrew Morton, linux-mm, LKML, Baoquan He, Christoph Hellwig,
	Matthew Wilcox, Nicholas Piggin, Oleksiy Avramchenko,
	Roman Gushchin

On Thu, Dec 22, 2022 at 08:06:11PM +0000, Lorenzo Stoakes wrote:
> n Thu, Dec 22, 2022 at 08:00:20PM +0100, Uladzislau Rezki (Sony) wrote:
> > Currently the __vunmap() path calls __find_vmap_area() twice. Once on
> > entry to check that the area exists, then inside the remove_vm_area()
> > function which also performs a new search for the VA.
> >
> > In order to improvie it from a performance point of view we split
> > remove_vm_area() into two new parts:
> >   - find_unlink_vmap_area() that does a search and unlink from tree;
> >   - __remove_vm_area() that removes without searching.
> >
> > In this case there is no any functional change for remove_vm_area()
> > whereas vm_remove_mappings(), where a second search happens, switches
> > to the __remove_vm_area() variant where the already detached VA is
> > passed as a parameter, so there is no need to find it again.
> >
> > Performance wise, i use test_vmalloc.sh with 32 threads doing alloc
> > free on a 64-CPUs-x86_64-box:
> >
> > perf without this patch:
> > -   31.41%     0.50%  vmalloc_test/10  [kernel.vmlinux]    [k] __vunmap
> >    - 30.92% __vunmap
> >       - 17.67% _raw_spin_lock
> >            native_queued_spin_lock_slowpath
> >       - 12.33% remove_vm_area
> >          - 11.79% free_vmap_area_noflush
> >             - 11.18% _raw_spin_lock
> >                  native_queued_spin_lock_slowpath
> >         0.76% free_unref_page
> >
> > perf with this patch:
> > -   11.35%     0.13%  vmalloc_test/14  [kernel.vmlinux]    [k] __vunmap
> >    - 11.23% __vunmap
> >       - 8.28% find_unlink_vmap_area
> >          - 7.95% _raw_spin_lock
> >               7.44% native_queued_spin_lock_slowpath
> >       - 1.93% free_vmap_area_noflush
> >          - 0.56% _raw_spin_lock
> >               0.53% native_queued_spin_lock_slowpath
> >         0.60% __vunmap_range_noflush
> >
> > __vunmap() consumes around ~20% less CPU cycles on this test.
> >
> > v2 -> v3:
> > - update commit message;
> > - rename the vm_remove_mappings() to the va_remove_mappings();
> > - move va-unlinking to the callers so the free_vmap_area_noflush()
> >   now expects a VA that has been disconnected;
> > - eliminate a local variable in the remove_vm_area().
> >
> > Reported-by: Roman Gushchin <roman.gushchin@linux.dev>
> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > ---
> >  mm/vmalloc.c | 77 ++++++++++++++++++++++++++++++++--------------------
> >  1 file changed, 47 insertions(+), 30 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 9e30f0b39203..eb91ecaa7277 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1815,9 +1815,9 @@ static void drain_vmap_area_work(struct work_struct *work)
> >  }
> >
> >  /*
> > - * Free a vmap area, caller ensuring that the area has been unmapped
> > - * and flush_cache_vunmap had been called for the correct range
> > - * previously.
> > + * Free a vmap area, caller ensuring that the area has been unmapped,
> > + * unlinked and flush_cache_vunmap had been called for the correct
> > + * range previously.
> >   */
> >  static void free_vmap_area_noflush(struct vmap_area *va)
> >  {
> > @@ -1825,9 +1825,8 @@ static void free_vmap_area_noflush(struct vmap_area *va)
> >  	unsigned long va_start = va->va_start;
> >  	unsigned long nr_lazy;
> >
> > -	spin_lock(&vmap_area_lock);
> > -	unlink_va(va, &vmap_area_root);
> > -	spin_unlock(&vmap_area_lock);
> > +	if (WARN_ON_ONCE(!list_empty(&va->list)))
> > +		return;
> >
> >  	nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >>
> >  				PAGE_SHIFT, &vmap_lazy_nr);
> > @@ -1871,6 +1870,19 @@ struct vmap_area *find_vmap_area(unsigned long addr)
> >  	return va;
> >  }
> >
> > +static struct vmap_area *find_unlink_vmap_area(unsigned long addr)
> > +{
> > +	struct vmap_area *va;
> > +
> > +	spin_lock(&vmap_area_lock);
> > +	va = __find_vmap_area(addr, &vmap_area_root);
> > +	if (va)
> > +		unlink_va(va, &vmap_area_root);
> > +	spin_unlock(&vmap_area_lock);
> > +
> > +	return va;
> > +}
> > +
> >  /*** Per cpu kva allocator ***/
> >
> >  /*
> > @@ -2015,6 +2027,10 @@ static void free_vmap_block(struct vmap_block *vb)
> >  	tmp = xa_erase(&vmap_blocks, addr_to_vb_idx(vb->va->va_start));
> >  	BUG_ON(tmp != vb);
> >
> > +	spin_lock(&vmap_area_lock);
> > +	unlink_va(vb->va, &vmap_area_root);
> > +	spin_unlock(&vmap_area_lock);
> > +
> >  	free_vmap_area_noflush(vb->va);
> >  	kfree_rcu(vb, rcu_head);
> >  }
> > @@ -2591,6 +2607,20 @@ struct vm_struct *find_vm_area(const void *addr)
> >  	return va->vm;
> >  }
> >
> > +static struct vm_struct *__remove_vm_area(struct vmap_area *va)
> > +{
> > +	struct vm_struct *vm;
> > +
> > +	if (!va || !va->vm)
> > +		return NULL;
> > +
> > +	vm = va->vm;
> > +	kasan_free_module_shadow(vm);
> > +	free_unmap_vmap_area(va);
> > +
> > +	return vm;
> > +}
> > +
> >  /**
> >   * remove_vm_area - find and remove a continuous kernel virtual area
> >   * @addr:	    base address
> > @@ -2603,26 +2633,10 @@ struct vm_struct *find_vm_area(const void *addr)
> >   */
> >  struct vm_struct *remove_vm_area(const void *addr)
> >  {
> > -	struct vmap_area *va;
> > -
> >  	might_sleep();
> >
> > -	spin_lock(&vmap_area_lock);
> > -	va = __find_vmap_area((unsigned long)addr, &vmap_area_root);
> > -	if (va && va->vm) {
> > -		struct vm_struct *vm = va->vm;
> > -
> > -		va->vm = NULL;
> > -		spin_unlock(&vmap_area_lock);
> > -
> > -		kasan_free_module_shadow(vm);
> > -		free_unmap_vmap_area(va);
> > -
> > -		return vm;
> > -	}
> > -
> > -	spin_unlock(&vmap_area_lock);
> > -	return NULL;
> > +	return __remove_vm_area(
> > +		find_unlink_vmap_area((unsigned long) addr));
> >  }
> >
> >  static inline void set_area_direct_map(const struct vm_struct *area,
> > @@ -2636,16 +2650,17 @@ static inline void set_area_direct_map(const struct vm_struct *area,
> >  			set_direct_map(area->pages[i]);
> >  }
> >
> > -/* Handle removing and resetting vm mappings related to the vm_struct. */
> > -static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> > +/* Handle removing and resetting vm mappings related to the VA's vm_struct. */
> > +static void va_remove_mappings(struct vmap_area *va, int deallocate_pages)
> >  {
> > +	struct vm_struct *area = va->vm;
> >  	unsigned long start = ULONG_MAX, end = 0;
> >  	unsigned int page_order = vm_area_page_order(area);
> >  	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
> >  	int flush_dmap = 0;
> >  	int i;
> >
> > -	remove_vm_area(area->addr);
> > +	__remove_vm_area(va);
> >
> >  	/* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */
> >  	if (!flush_reset)
> > @@ -2690,6 +2705,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
> >  static void __vunmap(const void *addr, int deallocate_pages)
> >  {
> >  	struct vm_struct *area;
> > +	struct vmap_area *va;
> >
> >  	if (!addr)
> >  		return;
> > @@ -2698,19 +2714,20 @@ static void __vunmap(const void *addr, int deallocate_pages)
> >  			addr))
> >  		return;
> >
> > -	area = find_vm_area(addr);
> > -	if (unlikely(!area)) {
> > +	va = find_unlink_vmap_area((unsigned long)addr);
> > +	if (unlikely(!va)) {
> >  		WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
> >  				addr);
> >  		return;
> >  	}
> >
> > +	area = va->vm;
> >  	debug_check_no_locks_freed(area->addr, get_vm_area_size(area));
> >  	debug_check_no_obj_freed(area->addr, get_vm_area_size(area));
> >
> >  	kasan_poison_vmalloc(area->addr, get_vm_area_size(area));
> >
> > -	vm_remove_mappings(area, deallocate_pages);
> > +	va_remove_mappings(va, deallocate_pages);
> >
> >  	if (deallocate_pages) {
> >  		int i;
> > --
> > 2.30.2
> >
> 
> All looks good to me! Great work! Feel free to add the below to all patches in series:-
> 
> Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>
>
Added :)

Thank you for review!

--
Uladzislau Rezki

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

* Re: [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap()
  2022-12-23  8:19 ` Christoph Hellwig
@ 2022-12-23 16:43   ` Uladzislau Rezki
  0 siblings, 0 replies; 14+ messages in thread
From: Uladzislau Rezki @ 2022-12-23 16:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Uladzislau Rezki (Sony),
	Andrew Morton, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Matthew Wilcox, Nicholas Piggin, Oleksiy Avramchenko,
	Roman Gushchin

On Fri, Dec 23, 2022 at 12:19:26AM -0800, Christoph Hellwig wrote:
> On Thu, Dec 22, 2022 at 08:00:20PM +0100, Uladzislau Rezki (Sony) wrote:
> > @@ -1825,9 +1825,8 @@ static void free_vmap_area_noflush(struct vmap_area *va)
> >  	unsigned long va_start = va->va_start;
> >  	unsigned long nr_lazy;
> >  
> > -	spin_lock(&vmap_area_lock);
> > -	unlink_va(va, &vmap_area_root);
> > -	spin_unlock(&vmap_area_lock);
> > +	if (WARN_ON_ONCE(!list_empty(&va->list)))
> > +		return;
> 
> I'd just drop this check as the function is not exported.
> 
>
> Otherwise looks good:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
Thanks!


--
Uladzislau Rezki

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

* Re: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-23 16:41     ` Uladzislau Rezki
@ 2022-12-28 23:47       ` Andrew Morton
  2022-12-29 12:47         ` Uladzislau Rezki
  0 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2022-12-28 23:47 UTC (permalink / raw)
  To: Uladzislau Rezki
  Cc: linux-mm, LKML, Baoquan He, Lorenzo Stoakes, Matthew Wilcox,
	Nicholas Piggin, Oleksiy Avramchenko, Christoph Hellwig

On Fri, 23 Dec 2022 17:41:48 +0100 Uladzislau Rezki <urezki@gmail.com> wrote:

> > Don't we also need to remove the manual unlink that was done
> > here previously?   Actually it seems like that manual unlink is missing
> > after patch 1, creating a bisection hazard.  So either add it there,
> > or just fold this patch into the previous one.
> >
> Right. In terms of bisection it is not so good. I think folding is the
> best.
> 
> Andrew, could you please fold this patch into the:

which patch ;)

> [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() ?
> 
> or should i send a v4 instead?

Yes please.

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

* Re: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-28 23:47       ` Andrew Morton
@ 2022-12-29 12:47         ` Uladzislau Rezki
  2022-12-29 23:17           ` Andrew Morton
  0 siblings, 1 reply; 14+ messages in thread
From: Uladzislau Rezki @ 2022-12-29 12:47 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Uladzislau Rezki, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Matthew Wilcox, Nicholas Piggin, Oleksiy Avramchenko,
	Christoph Hellwig

On Wed, Dec 28, 2022 at 03:47:07PM -0800, Andrew Morton wrote:
> On Fri, 23 Dec 2022 17:41:48 +0100 Uladzislau Rezki <urezki@gmail.com> wrote:
> 
> > > Don't we also need to remove the manual unlink that was done
> > > here previously?   Actually it seems like that manual unlink is missing
> > > after patch 1, creating a bisection hazard.  So either add it there,
> > > or just fold this patch into the previous one.
> > >
> > Right. In terms of bisection it is not so good. I think folding is the
> > best.
> > 
> > Andrew, could you please fold this patch into the:
> 
> which patch ;)
> 
Currently the next-20221226 contains three patches:

<snip>
[1]
commit c83b70c3cc1ecf99897ca0ea6e44aa2125a61ccb
Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
Date:   Wed Dec 21 18:44:54 2022 +0100

    mm: vmalloc: replace BUG_ON() by WARN_ON_ONCE()

[2]
commit 8a85ea97b35924ee39d51e00ecb3f6d07f748a36
Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
Date:   Wed Dec 21 18:44:53 2022 +0100

    mm: vmalloc: switch to find_unlink_vmap_area() in vm_unmap_ram()

[3]
commit a7c84c673c71cdfad20fe25e5d2051ed229859f7
Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
Date:   Wed Dec 21 18:44:52 2022 +0100

    mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap()
<snip>

It would be good if you could fold [2] into [3] making it as one
patch. The problem is that, if we leave it as it is, the bisection
mechanism would consider [3] as a buggy patch, because it is not
fully accomplished and depends on [2].

Is that OK for you, i mean to squash on your own? Or i just should
resend one more time?

Thank you in advance!

--
Uladzislau Rezki

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

* Re: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-29 12:47         ` Uladzislau Rezki
@ 2022-12-29 23:17           ` Andrew Morton
  2022-12-31  9:17             ` Uladzislau Rezki
  0 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2022-12-29 23:17 UTC (permalink / raw)
  To: Uladzislau Rezki
  Cc: linux-mm, LKML, Baoquan He, Lorenzo Stoakes, Matthew Wilcox,
	Nicholas Piggin, Oleksiy Avramchenko, Christoph Hellwig

On Thu, 29 Dec 2022 13:47:43 +0100 Uladzislau Rezki <urezki@gmail.com> wrote:

> [2]
> commit 8a85ea97b35924ee39d51e00ecb3f6d07f748a36
> Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
> Date:   Wed Dec 21 18:44:53 2022 +0100
> 
>     mm: vmalloc: switch to find_unlink_vmap_area() in vm_unmap_ram()
> 
> [3]
> commit a7c84c673c71cdfad20fe25e5d2051ed229859f7
> Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
> Date:   Wed Dec 21 18:44:52 2022 +0100
> 
>     mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap()
> <snip>
> 
> It would be good if you could fold [2] into [3] making it as one
> patch. The problem is that, if we leave it as it is, the bisection
> mechanism would consider [3] as a buggy patch, because it is not
> fully accomplished and depends on [2].
> 
> Is that OK for you, i mean to squash on your own? 

I did that.  I updated the "mm: vmalloc: avoid calling
__find_vmap_area() twice in __vunmap()" accordingly, thanks.


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

* Re: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram()
  2022-12-29 23:17           ` Andrew Morton
@ 2022-12-31  9:17             ` Uladzislau Rezki
  0 siblings, 0 replies; 14+ messages in thread
From: Uladzislau Rezki @ 2022-12-31  9:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Uladzislau Rezki, linux-mm, LKML, Baoquan He, Lorenzo Stoakes,
	Matthew Wilcox, Nicholas Piggin, Oleksiy Avramchenko,
	Christoph Hellwig

On Thu, Dec 29, 2022 at 03:17:06PM -0800, Andrew Morton wrote:
> On Thu, 29 Dec 2022 13:47:43 +0100 Uladzislau Rezki <urezki@gmail.com> wrote:
> 
> > [2]
> > commit 8a85ea97b35924ee39d51e00ecb3f6d07f748a36
> > Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > Date:   Wed Dec 21 18:44:53 2022 +0100
> > 
> >     mm: vmalloc: switch to find_unlink_vmap_area() in vm_unmap_ram()
> > 
> > [3]
> > commit a7c84c673c71cdfad20fe25e5d2051ed229859f7
> > Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > Date:   Wed Dec 21 18:44:52 2022 +0100
> > 
> >     mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap()
> > <snip>
> > 
> > It would be good if you could fold [2] into [3] making it as one
> > patch. The problem is that, if we leave it as it is, the bisection
> > mechanism would consider [3] as a buggy patch, because it is not
> > fully accomplished and depends on [2].
> > 
> > Is that OK for you, i mean to squash on your own? 
> 
> I did that.  I updated the "mm: vmalloc: avoid calling
> __find_vmap_area() twice in __vunmap()" accordingly, thanks.
> 
At least bisection part will not detect anything wrong now.

Happy New Year and thank you!

--
Uladzislau Rezki

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

end of thread, other threads:[~2022-12-31  9:17 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-22 19:00 [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Uladzislau Rezki (Sony)
2022-12-22 19:00 ` [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram() Uladzislau Rezki (Sony)
2022-12-23  8:21   ` Christoph Hellwig
2022-12-23 16:41     ` Uladzislau Rezki
2022-12-28 23:47       ` Andrew Morton
2022-12-29 12:47         ` Uladzislau Rezki
2022-12-29 23:17           ` Andrew Morton
2022-12-31  9:17             ` Uladzislau Rezki
2022-12-22 19:00 ` [PATCH v3 3/3] mm: vmalloc: Replace BUG_ON() by WARN_ON_ONCE() Uladzislau Rezki (Sony)
2022-12-23  8:21   ` Christoph Hellwig
2022-12-22 20:06 ` [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() Lorenzo Stoakes
2022-12-23 16:42   ` Uladzislau Rezki
2022-12-23  8:19 ` Christoph Hellwig
2022-12-23 16:43   ` Uladzislau Rezki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).