linux-stable.git/mm/vmalloc.c, branch v5.10.78

mm/vmalloc.c: fix potential memory leak

2021-01-19T17:27:21+00:00

commit c22ee5284cf58017fa8c6d21d8f8c68159b6faab upstream.

In VM_MAP_PUT_PAGES case, we should put pages and free array in vfree.
But we missed to set area->nr_pages in vmap().  So we would fail to put
pages in __vunmap() because area->nr_pages = 0.

Link: https://lkml.kernel.org/r/20210107123541.39206-1-linmiaohe@huawei.com
Fixes: b944afc9d64d ("mm: add a VM_MAP_PUT_PAGES flag for vmap")
Signed-off-by: Shijie Luo 
Signed-off-by: Miaohe Lin 
Reviewed-by: Uladzislau Rezki (Sony) 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm/vmalloc.c: fix kasan shadow poisoning size

2020-12-30T10:53:55+00:00

[ Upstream commit c041098c690fe53cea5d20c62f128a4f7a5c19fe ]

The size of vm area can be affected by the presence or not of the guard
page.  In particular when VM_NO_GUARD is present, the actual accessible
size has to be considered like the real size minus the guard page.

Currently kasan does not keep into account this information during the
poison operation and in particular tries to poison the guard page as well.

This approach, even if incorrect, does not cause an issue because the tags
for the guard page are written in the shadow memory.  With the future
introduction of the Tag-Based KASAN, being the guard page inaccessible by
nature, the write tag operation on this page triggers a fault.

Fix kasan shadow poisoning size invoking get_vm_area_size() instead of
accessing directly the field in the data structure to detect the correct
value.

Link: https://lkml.kernel.org/r/20201027160213.32904-1-vincenzo.frascino@arm.com
Fixes: d98c9e83b5e7c ("kasan: fix crashes on access to memory mapped by vm_map_ram()")
Signed-off-by: Vincenzo Frascino 
Cc: Andrey Konovalov 
Cc: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Marco Elver 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm/vmalloc: Fix unlock order in s_stop()

2020-12-30T10:53:55+00:00

[ Upstream commit 0a7dd4e901b8a4ee040ba953900d1d7120b34ee5 ]

When multiple locks are acquired, they should be released in reverse
order. For s_start() and s_stop() in mm/vmalloc.c, that is not the
case.

  s_start: mutex_lock(&vmap_purge_lock); spin_lock(&vmap_area_lock);
  s_stop : mutex_unlock(&vmap_purge_lock); spin_unlock(&vmap_area_lock);

This unlock sequence, though allowed, is not optimal. If a waiter is
present, mutex_unlock() will need to go through the slowpath of waking
up the waiter with preemption disabled. Fix that by releasing the
spinlock first before the mutex.

Link: https://lkml.kernel.org/r/20201213180843.16938-1-longman@redhat.com
Fixes: e36176be1c39 ("mm/vmalloc: rework vmap_area_lock")
Signed-off-by: Waiman Long 
Reviewed-by: Uladzislau Rezki (Sony) 
Reviewed-by: David Hildenbrand 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm: remove the filename in the top of file comment in vmalloc.c

2020-10-18T16:27:10+00:00

No point in having the filename inside the file.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Cc: Uladzislau Rezki (Sony) 
Link: https://lkml.kernel.org/r/20201002124035.1539300-3-hch@lst.de
Signed-off-by: Linus Torvalds

mm: cleanup the gfp_mask handling in __vmalloc_area_node

2020-10-18T16:27:10+00:00

Patch series "two small vmalloc cleanups".

This patch (of 2):

__vmalloc_area_node currently has four different gfp_t variables to
just express this simple logic:

 - use the passed in mask, plus __GFP_NOWARN and __GFP_HIGHMEM (if
   suitable) for the underlying page allocation
 - use just the reclaim flags from the passed in mask plus __GFP_ZERO
   for allocating the page array

Simplify this down to just use the pre-existing nested_gfp as-is for
the page array allocation, and just the passed in gfp_mask for the
page allocation, after conditionally ORing __GFP_HIGHMEM into it.  This
also makes the allocation warning a little more correct.

Also initialize two variables at the time of declaration while touching
this area.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Cc: Uladzislau Rezki (Sony) 
Link: https://lkml.kernel.org/r/20201002124035.1539300-1-hch@lst.de
Link: https://lkml.kernel.org/r/20201002124035.1539300-2-hch@lst.de
Signed-off-by: Linus Torvalds

mm: remove alloc_vm_area

2020-10-18T16:27:10+00:00

All users are gone now.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Juergen Gross 
Cc: Matthew Auld 
Cc: "Matthew Wilcox (Oracle)" 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Peter Zijlstra 
Cc: Rodrigo Vivi 
Cc: Stefano Stabellini 
Cc: Tvrtko Ursulin 
Cc: Uladzislau Rezki (Sony) 
Link: https://lkml.kernel.org/r/20201002122204.1534411-12-hch@lst.de
Signed-off-by: Linus Torvalds

mm: add a vmap_pfn function

2020-10-18T16:27:10+00:00

Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE manipulation
for it.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Juergen Gross 
Cc: Matthew Auld 
Cc: "Matthew Wilcox (Oracle)" 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Peter Zijlstra 
Cc: Rodrigo Vivi 
Cc: Stefano Stabellini 
Cc: Tvrtko Ursulin 
Cc: Uladzislau Rezki (Sony) 
Link: https://lkml.kernel.org/r/20201002122204.1534411-4-hch@lst.de
Signed-off-by: Linus Torvalds

mm: add a VM_MAP_PUT_PAGES flag for vmap

2020-10-18T16:27:10+00:00

Add a flag so that vmap takes ownership of the passed in page array.  When
vfree is called on such an allocation it will put one reference on each
page, and free the page array itself.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Juergen Gross 
Cc: Matthew Auld 
Cc: "Matthew Wilcox (Oracle)" 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Peter Zijlstra 
Cc: Rodrigo Vivi 
Cc: Stefano Stabellini 
Cc: Tvrtko Ursulin 
Cc: Uladzislau Rezki (Sony) 
Link: https://lkml.kernel.org/r/20201002122204.1534411-3-hch@lst.de
Signed-off-by: Linus Torvalds

mm: update the documentation for vfree

2020-10-18T16:27:10+00:00

Patch series "remove alloc_vm_area", v4.

This series removes alloc_vm_area, which was left over from the big
vmalloc interface rework.  It is a rather arkane interface, basicaly the
equivalent of get_vm_area + actually faulting in all PTEs in the allocated
area.  It was originally addeds for Xen (which isn't modular to start
with), and then grew users in zsmalloc and i915 which seems to mostly
qualify as abuses of the interface, especially for i915 as a random driver
should not set up PTE bits directly.

This patch (of 11):

 * Document that you can call vfree() on an address returned from vmap()
 * Remove the note about the minimum size -- the minimum size of a vmalloc
   allocation is one page
 * Add a Context: section
 * Fix capitalisation
 * Reword the prohibition on calling from NMI context to avoid a double
   negative

Signed-off-by: Matthew Wilcox (Oracle) 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Cc: Peter Zijlstra 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Rodrigo Vivi 
Cc: Minchan Kim 
Cc: Matthew Wilcox 
Cc: Nitin Gupta 
Cc: Uladzislau Rezki (Sony) 
Link: https://lkml.kernel.org/r/20201002122204.1534411-1-hch@lst.de
Link: https://lkml.kernel.org/r/20201002122204.1534411-2-hch@lst.de
Signed-off-by: Linus Torvalds

mm/vmalloc.c: fix the comment of find_vm_area

2020-10-14T01:38:32+00:00

Fix the comment of find_vm_area() and get_vm_area()

Signed-off-by: Hui Su 
Signed-off-by: Andrew Morton 
Reviewed-by: Andrew Morton 
Link: https://lkml.kernel.org/r/20200927153034.GA199877@rlk
Signed-off-by: Linus Torvalds