mm/vmalloc: fix up vmap error handling
Subsystems (6)
v4 cover mm/vmalloc: fix up vmap error handling
__vmap_pages_range_noflush() and friends can install some PTEs before failing and leave them mapped, and the kernel callers do not agree on who cleans them up. pcpu_map_pages() and kmsan_ioremap_page_range() roll back what they mapped before the failure, while vm_module_tags_populate() and the __GFP_NOFAIL retry loop in __vmalloc_area_node() rely on the mapping functions cleaning up and do not call anything like vunmap_range() themselves. When the same range is mapped again, the attempt hits the leftovers and fails with a warning in vmap_pages_pte_range(). A leftover huge pmd is worse. During the retry, vmap_try_huge_pmd() calls pmd_free_pte_page() on it, and the x86 implementation cannot tell a leaf entry from a page table and frees the mapped page.
After discussing with Suren and Ulad [1], we move the rollback into the mapping functions. A failed vmap leaves nothing mapped, and the callers no longer clean up after it.
Patch 1 is the KMSAN part. The shadow and the origin of a range are mapped by two separate calls, so the rollback there has to cover both. Patch 2 is its disabled-KMSAN counterpart. Patches 3 to 5 bug out on an unaligned range at the entry of the three range walkers. Patch 6 only flushes the cache once the mapping succeeded. Patch 7 adds the rollback to __vmap_pages_range_noflush() and vmap_page_range(). Patches 8 and 9 drop the powerpc and percpu cleanups that are not needed anymore.
Changes since v3:
- drop v3 patch 3. The clamp papered over the caller bug, a bad range now BUG_ONs at the unmap entry
- drop v3 patch 4. The reworked walk (24bbe1c56f63a) propagates the errors already
- drop v3 patch 6. The walk below checks the range already
- the map side checks moved from the pte level to the entries of vmap_range_noflush() and the walk, and became BUG_ON, in line with the unmap side
- rebase onto the walk rework, commit messages updated accordingly
[1] https://lore.kernel.org/all/[email protected]/
v3 link: https://lore.kernel.org/all/[email protected]/
v2 link: https://lore.kernel.org/all/[email protected]/
v1 link: https://lore.kernel.org/all/[email protected]/
Hao Ge (9):
mm/kmsan: undo the shadow mapping when the origin mapping fails mm/kmsan: skip vunmap_range_noflush when KMSAN is disabled mm/vmalloc: BUG_ON() on an unaligned range in vmap_range_noflush() mm/vmalloc: BUG_ON() on an unaligned range in
vmap_pages_range_noflush_walk()
mm/vmalloc: BUG_ON() on an unaligned range in __vunmap_range_noflush() mm/vmalloc: only flush the cache after the vmap succeeded mm/vmalloc: undo partial mappings inside the mapping functions
powerpc: drop redundant unmaps of failed vmap mappings mm/percpu: stop unmapping the CPU that failed to map
arch/powerpc/kernel/isa-bridge.c | 5 +-- arch/powerpc/kernel/pci_64.c | 4 +- include/linux/kmsan.h | 8 +++- mm/kmsan/hooks.c | 21 ++++++--- mm/kmsan/shadow.c | 9 +++- mm/percpu-vm.c | 5 ++- mm/vmalloc.c | 75 ++++++++++++++++++++++++-------- mm/vmalloc.h | 6 ++- 8 files changed, 94 insertions(+), 39 deletions(-)
Signature · 1 line
2.25.1
PATCH v4 1/9 mm/kmsan: undo the shadow mapping when the origin mapping fails
kmsan_vmap_pages_range_noflush() first maps the shadow pages and then the origin pages. If the second mapping fails, the first one is left mapped, and the callers do not roll it back. The next vmap of the same metadata range hits the stale PTEs again and fails with a WARN_ON() and -EBUSY in vmap_pages_pte_range().
Undo the shadow mapping on that error path, the same way kmsan_ioremap_page_range() cleans up after a partial failure. __vunmap_range_noflush() only clears the PTEs; nothing has touched the shadow mapping, so no TLB flush is needed.
--- mm/kmsan/shadow.c | 4 ++++ 1 file changed, 4 insertions(+)
mm/kmsan/shadow.c +4 -0
@@ -258,6 +258,10 @@ int kmsan_vmap_pages_range_noflush(unsigned long start, unsigned long end, o_pages, page_shift);kmsan_leave_runtime ();if (mapped) { +/* Undo the shadow mapping set up above. */ +kmsan_enter_runtime (); +__vunmap_range_noflush (shadow_start, shadow_end); +kmsan_leave_runtime (); err = mapped; goto ret; }
Signature · 1 line
2.25.1
PATCH v4 2/9 mm/kmsan: skip vunmap_range_noflush when KMSAN is disabled
In reply to Hao Gekmsan_vmap_pages_range_noflush() returns 0 when kmsan_enabled is false. The unmap side does not, so it still walks the shadow and origin page tables even though KMSAN never installed any metadata there.
Add the matching early return.
--- mm/kmsan/hooks.c | 3 +++ 1 file changed, 3 insertions(+)
mm/kmsan/hooks.c +3 -0
@@ -138,6 +138,9 @@ static unsigned long vmalloc_origin(unsigned long addr)void kmsan_vunmap_range_noflush (unsigned long start,unsigned long end) { +if (!kmsan_enabled) +return ; +__vunmap_range_noflush (vmalloc_shadow (start),vmalloc_shadow (end));__vunmap_range_noflush (vmalloc_origin (start),vmalloc_origin (end));flush_cache_vmap (vmalloc_shadow (start),vmalloc_shadow (end));
Signature · 1 line
2.25.1
PATCH v4 3/9 mm/vmalloc: BUG_ON() on an unaligned range in vmap_range_noflush()
In reply to Hao Gecommit a739e6b557af ("mm: vmalloc: WARN_ON if mapping size is not PAGE_SIZE aligned") put the check in vmap_pte_range(), which is too late, because the upper levels may already have installed page tables for a range that is rejected anyway.
The pte loop maps whole pages and stops only when addr lands exactly on end. An unaligned end lets addr jump over it and the loop keeps mapping past the range. An unaligned start maps the page below the range and usually misses end too. Such a range is never a legitimate request, and the corruption it leaves behind is hard to attribute to the caller afterwards, so bug out on addr and end at the entry of vmap_range_noflush() and drop the check from vmap_pte_range().
--- mm/vmalloc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
mm/vmalloc.c +1 -3
@@ -125,9 +125,6 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,unsigned long size;unsigned int nr_pages; -if (WARN_ON_ONCE (!PAGE_ALIGNED (end - addr))) -return -EINVAL ; - pfn = phys_addr >>PAGE_SHIFT ; pte =pte_alloc_kernel_track (pmd, addr, mask);if (!pte)
@@ -347,6 +344,7 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end,*/ might_sleep ();BUG_ON (addr >= end); +BUG_ON (!PAGE_ALIGNED (addr) || !PAGE_ALIGNED (end)); start = addr; pgd =pgd_offset_k (addr);
Signature · 1 line
2.25.1
Re: [PATCH v4 3/9] mm/vmalloc: BUG_ON() on an unaligned range in vmap_range_noflush()
Quoted 34 lines · Hao Ge
commit
a739e6b557af("mm: vmalloc:WARN_ONif mapping size is notPAGE_SIZEaligned") put the check invmap_pte_range(), which is too late, because the upper levels may already have installed page tables for a range that is rejected anyway.The pte loop maps whole pages and stops only when addr lands exactly on end. An unaligned end lets addr jump over it and the loop keeps mapping past the range. An unaligned start maps the page below the range and usually misses end too. Such a range is never a legitimate request, and the corruption it leaves behind is hard to attribute to the caller afterwards, so bug out on addr and end at the entry of
vmap_range_noflush()and drop the check fromvmap_pte_range().Signed-off-by Hao Ge <[email protected]>--- mm/vmalloc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)mm/vmalloc.c +0
-3@@ -125,9 +125,6 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,unsigned long size;unsigned int nr_pages; -if (WARN_ON_ONCE (!PAGE_ALIGNED (end - addr))) -return -EINVAL ; - pfn = phys_addr >>PAGE_SHIFT ; pte =pte_alloc_kernel_track (pmd, addr, mask);if (!pte)
mm/vmalloc.c static int vmap_range_noflush(unsigned long addr, unsigned long end, · line 347
Quoted 4 lines
mm/vmalloc.c +1
-0@@ -347,6 +344,7 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end,*/ might_sleep ();BUG_ON (addr >= end); +BUG_ON (!PAGE_ALIGNED (addr) || !PAGE_ALIGNED (end));
I know BUG_ON() is ugly and it was not my first choice either, but I have not figured out a better way to handle __vunmap_range_noflush().
If an unaligned range is passed to it, the pte loop may clear PTEs adjacent to the range. Say a caller passes [3, 12) while [0, 3) belongs to somebody else. The loop operates on whole pages, so it starts at the page containing 3 and clears [0, 3) with it. That silently corrupts a live mapping, and the corruption is not detected until the owner touches the page. Bugs like that are nearly impossible to debug afterwards.
It is not feasible for __vunmap_range_noflush() to just return an invalid-argument error upfront. Its job is to clear PTEs, and an early return leaves the residual PTEs behind.
I also thought about warning and returning -EINVAL on the map side and keeping BUG_ON() only in __vunmap_range_noflush(), but the rollback kills that idea.
int __vmap_pages_range_noflush(unsigned long addr, unsigned long end,
pgprot_t prot, struct page **pages, unsigned int page_shift, gfp_t gfp_mask)
{
int err;
if (WARN_ON_ONCE(page_shift < PAGE_SHIFT))
return -EINVAL;
if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC))
page_shift = PAGE_SHIFT;
err = vmap_pages_range_noflush_walk(addr, end, prot, pages, page_shift);
/* Undo the PTEs installed before the failure. */
if (err)
__vunmap_range_noflush(addr, end,
gfpflags_allow_blocking(gfp_mask));
return err;
}If the walk WARNs and returns -EINVAL for a bad range, the undo above passes that same range to __vunmap_range_noflush(), and we BUG right after the WARN. vmap_page_range() runs into the same thing on its error path.
So the map side cannot warn while the unmap side BUGs, the rollback drags the rejected range into the unmap anyway. And the unmap side cannot warn and skip either, that leaves the stale PTEs.
Also, these checks are the last line of defense. All in-tree callers pass page aligned, non-empty ranges, and I am not aware of anyone ever hitting this line. So for correct code the BUG_ON never fires at all, no user will ever see it. The only one who can trip it is the developer who just passed the bad range, and for him a stack trace right at the spot is much better than chasing a silent corruption afterwards.
I settled on BUG_ON here. It may not be an ideal solution, but if anyone has a better idea or alternative approach, please let me know. I would greatly appreciate it.
Thanks
Best Regards
Hao
Quoted 3 lines
mm/vmalloc.c +0
-0start = addr; pgd =pgd_offset_k (addr);
PATCH v4 4/9 mm/vmalloc: BUG_ON() on an unaligned range in vmap_pages_range_noflush_walk()
In reply to Hao GeThe pte loop of vmap_pages_pte_range() maps whole pages and stops only when addr lands exactly on end. An unaligned end lets addr jump over it and the loop keeps mapping into whatever follows the range. An unaligned start maps the page below the range with its first pte. That corruption is impossible to debug afterwards, so bug out on addr and end at the entry of vmap_pages_range_noflush_walk().
--- mm/vmalloc.c | 2 ++ 1 file changed, 2 insertions(+)
mm/vmalloc.c +2 -0
@@ -698,6 +698,8 @@ static int vmap_pages_range_noflush_walk(unsigned long addr, unsigned long end,pgtbl_mod_mask mask =0 ;BUG_ON (addr >= end); +BUG_ON (!PAGE_ALIGNED (addr) || !PAGE_ALIGNED (end)); + pgd =pgd_offset_k (addr); do { next = pgd_addr_end(addr, end);
Signature · 1 line
2.25.1
PATCH v4 5/9 mm/vmalloc: BUG_ON() on an unaligned range in __vunmap_range_noflush()
In reply to Hao GeThe PTE loop of the unmap path stops only at addr == end. With an unaligned end addr never lands on end, so the loop walks past the range and keeps clearing. With an unaligned start the loop begins in the page containing start, which extends below the range. Either way the unmap clears the mappings adjacent to the range, and that is nearly impossible to debug afterwards.
vmap only installs page-aligned, page-granular mappings, so an unaligned unmap request is never a legitimate teardown, and there is no way to tell which pages the caller meant. Check addr and end at the entry of __vunmap_range_noflush() and bug out before any PTE is cleared.
--- mm/vmalloc.c | 2 ++ 1 file changed, 2 insertions(+)
mm/vmalloc.c +2 -0
@@ -518,6 +518,8 @@ void __vunmap_range_noflush(unsigned long start, unsigned long end)pgtbl_mod_mask mask =0 ;BUG_ON (addr >= end); +BUG_ON (!PAGE_ALIGNED (addr) || !PAGE_ALIGNED (end)); + pgd =pgd_offset_k (addr); do { next = pgd_addr_end(addr, end);
Signature · 1 line
2.25.1
PATCH v4 6/9 mm/vmalloc: only flush the cache after the vmap succeeded
In reply to Hao Gevmap_page_range() and __vmap_pages_range() call flush_cache_vmap() before they even look at the error code. A failed mapping is never used, so the flush is pointless at best.
According to the Sashiko review it is worse than pointless on UML:flush_cache_vmap() there is flush_tlb_kernel_range(), which syncs the PTEs into the host OS. Flushing a half-installed mapping therefore leaves host mappings behind for a range that was just freed again.
Only flush when the mapping, and for vmap_page_range() also the KMSAN metadata, is fully set up.
--- mm/vmalloc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
mm/vmalloc.c +6 -2
@@ -369,10 +369,12 @@ int vmap_page_range(unsigned long addr, unsigned long end, err =vmap_range_noflush (addr, end, phys_addr,pgprot_nx (prot), ioremap_max_page_shift); -flush_cache_vmap (addr, end);if (!err) err =kmsan_ioremap_page_range (addr, end, phys_addr, prot, ioremap_max_page_shift); +if (!err) +flush_cache_vmap (addr, end); +return err; }
@@ -758,7 +760,9 @@ static int __vmap_pages_range(unsigned long addr, unsigned long end,int err; err =vmap_pages_range_noflush (addr, end, prot, pages, page_shift, gfp_mask); -flush_cache_vmap (addr, end); +if (!err) +flush_cache_vmap (addr, end); +return err; }
Signature · 1 line
2.25.1
PATCH v4 7/9 mm/vmalloc: undo partial mappings inside the mapping functions
In reply to Hao GeThe vmap entry points may install some PTEs and then fail, leaving a partial mapping behind.
The callers do not agree on who cleans it up. pcpu_map_pages() and kmsan_ioremap_page_range() roll back what they mapped, while vm_module_tags_populate() and the __GFP_NOFAIL retry loop in __vmalloc_area_node() expect a clean range from the mapping function. For them the leftovers stay mapped, and the next attempt to map the same range trips the WARN_ON(!pte_none()) in vmap_pages_pte_range(). A leftover huge pmd is even worse. During the retry, vmap_try_huge_pmd() calls pmd_free_pte_page() on it, and the x86 implementation cannot tell a leaf entry from a page table and frees the mapped page.
After discussing with Suren and Ulad, we decided to put the rollback into the entry points of the vmap API rather than into every low-level helper. __vmap_pages_range_noflush() undoes the whole range it was asked to map when it fails, and vmap_page_range() undoes its range for the ioremap-style mappings.
The rollback is __vunmap_range_noflush(), which only clears the PTEs. No TLB flush is needed, nothing has touched the mapping yet. vmap_pages_range_noflush() also drops the KMSAN metadata of the failed mapping.
The undo walk skips its cond_resched() when the caller's gfp mask cannot block. __vmalloc() with GFP_ATOMIC or GFP_NOWAIT can run in atomic context, where cond_resched() cannot schedule. __vunmap_range_noflush() takes a can_resched argument for that, which the sleepable callers pass as true.
--- include/linux/kmsan.h | 8 ++++-- mm/kmsan/hooks.c | 18 ++++++++----- mm/kmsan/shadow.c | 7 ++--- mm/vmalloc.c | 61 +++++++++++++++++++++++++++++++++---------- mm/vmalloc.h | 6 +++-- 5 files changed, 72 insertions(+), 28 deletions(-)
include/linux/kmsan.h +6 -2
@@ -150,11 +150,14 @@ int __must_check kmsan_vmap_pages_range_noflush(unsigned long start,* kmsan_vunmap_kernel_range_noflush() - Notify KMSAN about a vunmap. * @start: start of vunmapped range. * @end: end of vunmapped range. +* @can_resched: whether the unmap walk may call cond_resched(); pass +* false from atomic context. * * KMSAN unmaps the contiguous metadata ranges created by * kmsan_map_kernel_range_noflush(). */ -void kmsan_vunmap_range_noflush (unsigned long start,unsigned long end); +void kmsan_vunmap_range_noflush (unsigned long start,unsigned long end, +bool can_resched);/** * kmsan_ioremap_page_range() - Notify KMSAN about a ioremap_page_range() call.
@@ -355,7 +358,8 @@ static inline int __must_check kmsan_vmap_pages_range_noflush( }static inline void kmsan_vunmap_range_noflush (unsigned long start, -unsigned long end) +unsigned long end, +bool can_resched) { }
mm/kmsan/hooks.c +11 -7
@@ -136,13 +136,16 @@ static unsigned long vmalloc_origin(unsigned long addr) KMSAN_META_ORIGIN); } -void kmsan_vunmap_range_noflush (unsigned long start,unsigned long end) +void kmsan_vunmap_range_noflush (unsigned long start,unsigned long end, +bool can_resched) {if (!kmsan_enabled)return ; -__vunmap_range_noflush (vmalloc_shadow (start),vmalloc_shadow (end)); -__vunmap_range_noflush (vmalloc_origin (start),vmalloc_origin (end)); +__vunmap_range_noflush (vmalloc_shadow (start),vmalloc_shadow (end), + can_resched); +__vunmap_range_noflush (vmalloc_origin (start),vmalloc_origin (end), + can_resched);flush_cache_vmap (vmalloc_shadow (start),vmalloc_shadow (end));flush_cache_vmap (vmalloc_origin (start),vmalloc_origin (end)); }
@@ -171,8 +174,9 @@ static void kmsan_iounmap_pages(unsigned long start, unsigned long end)if (origin)__free_pages (origin,KMSAN_IOREMAP_META_ORDER ); } -__vunmap_range_noflush (shadow_start, shadow_end); -__vunmap_range_noflush (origin_start, origin_end); +/* ioremap metadata mappings are always GFP_KERNEL, so resched is safe. */ +__vunmap_range_noflush (shadow_start, shadow_end, true); +__vunmap_range_noflush (origin_start, origin_end, true);flush_tlb_kernel_range (shadow_start, shadow_end);flush_tlb_kernel_range (origin_start, origin_end); }
@@ -207,7 +211,7 @@ int kmsan_ioremap_page_range(unsigned long start, unsigned long end, mapped =__vmap_pages_range_noflush (vmalloc_shadow (start + off),vmalloc_shadow (start + off +PAGE_SIZE ), prot, &shadow, -PAGE_SHIFT ); +PAGE_SHIFT , gfp_mask);if (mapped) { err = mapped; goto ret;
@@ -217,7 +221,7 @@ int kmsan_ioremap_page_range(unsigned long start, unsigned long end, mapped =__vmap_pages_range_noflush (vmalloc_origin (start + off),vmalloc_origin (start + off +PAGE_SIZE ), prot, &origin, -PAGE_SHIFT ); +PAGE_SHIFT , gfp_mask);if (mapped) { err = mapped; goto ret;
mm/kmsan/shadow.c +4 -3
@@ -247,7 +247,7 @@ int kmsan_vmap_pages_range_noflush(unsigned long start, unsigned long end, origin_end =vmalloc_meta ((void *)end,KMSAN_META_ORIGIN );kmsan_enter_runtime (); mapped =__vmap_pages_range_noflush (shadow_start, shadow_end, prot, - s_pages, page_shift); + s_pages, page_shift, gfp_mask);kmsan_leave_runtime ();if (mapped) { err = mapped;
@@ -255,12 +255,13 @@ int kmsan_vmap_pages_range_noflush(unsigned long start, unsigned long end, }kmsan_enter_runtime (); mapped =__vmap_pages_range_noflush (origin_start, origin_end, prot, - o_pages, page_shift); + o_pages, page_shift, gfp_mask);kmsan_leave_runtime ();if (mapped) {/* Undo the shadow mapping set up above. */ kmsan_enter_runtime (); -__vunmap_range_noflush (shadow_start, shadow_end); +__vunmap_range_noflush (shadow_start, shadow_end, +gfpflags_allow_blocking (gfp_mask));kmsan_leave_runtime (); err = mapped; goto ret;
mm/vmalloc.c +47 -14
140 lines not on this page · raw message
mm/vmalloc.h +4 -2
@@ -40,10 +40,12 @@ void clear_vm_uninitialized_flag(struct vm_struct *vm);int __must_check __vmap_pages_range_noflush (unsigned long addr,unsigned long end,pgprot_t prot, -struct page **pages,unsigned int page_shift); +struct page **pages,unsigned int page_shift, +gfp_t gfp_mask);void vunmap_range_noflush (unsigned long start,unsigned long end); -void __vunmap_range_noflush (unsigned long start,unsigned long end); +void __vunmap_range_noflush (unsigned long start,unsigned long end, +bool can_resched);#endif /* __MM_VMALLOC_H */
Signature · 1 line
2.25.1
PATCH v4 8/9 powerpc: drop redundant unmaps of failed vmap mappings
In reply to Hao Gevmap_page_range() and ioremap_page_range() clear the PTEs they installed when they fail, so the vunmap_range() in remap_isa_base() and ioremap_phb() has nothing left to remove.
--- arch/powerpc/kernel/isa-bridge.c | 5 ++--- arch/powerpc/kernel/pci_64.c | 4 +--- 2 files changed, 3 insertions(+), 6 deletions(-)
arch/powerpc/kernel/isa-bridge.c +2 -3
@@ -46,9 +46,8 @@ static void remap_isa_base(phys_addr_t pa, unsigned long size)WARN_ON_ONCE (size & ~PAGE_MASK );if (slab_is_available ()) { -if (vmap_page_range (ISA_IO_BASE ,ISA_IO_BASE + size, pa, -pgprot_noncached (PAGE_KERNEL ))) -vunmap_range (ISA_IO_BASE ,ISA_IO_BASE + size); +vmap_page_range (ISA_IO_BASE ,ISA_IO_BASE + size, pa, +pgprot_noncached (PAGE_KERNEL )); }else {early_ioremap_range (ISA_IO_BASE , pa, size,pgprot_noncached (PAGE_KERNEL ));
arch/powerpc/kernel/pci_64.c +1 -3
@@ -139,10 +139,8 @@ void __iomem *ioremap_phb(phys_addr_t paddr, unsigned long size) addr = (unsigned long )area->addr;if (ioremap_page_range (addr, addr + size, paddr, -pgprot_noncached (PAGE_KERNEL ))) { -vunmap_range (addr, addr + size); +pgprot_noncached (PAGE_KERNEL )))return NULL ; - }return (void __iomem *)addr; }
Signature · 1 line
2.25.1
PATCH v4 9/9 mm/percpu: stop unmapping the CPU that failed to map
In reply to Hao Ge__pcpu_map_pages() clears the PTEs it installed when it fails, so pcpu_map_pages() only has to tear down the CPUs it mapped before the failing one.
--- mm/percpu-vm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
mm/percpu-vm.c +3 -2
@@ -252,10 +252,11 @@ static int pcpu_map_pages(struct pcpu_chunk *chunk, struct page **pages,return 0 ; err:for_each_possible_cpu (tcpu) { -__pcpu_unmap_pages (pcpu_chunk_addr (chunk, tcpu, page_start), - page_end - page_start); +/* The failing CPU's partial mapping undoes itself */ if (tcpu == cpu)break ; +__pcpu_unmap_pages (pcpu_chunk_addr (chunk, tcpu, page_start), + page_end - page_start); }pcpu_post_unmap_tlb_flush (chunk, page_start, page_end);return err;
Signature · 1 line
2.25.1