Skip to content

Commit 69dc72f

Browse files
minchankgregkh
authored andcommitted
mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING
commit e91d8d7 upstream. While I was doing zram testing, I found sometimes decompression failed since the compression buffer was corrupted. With investigation, I found below commit calls cond_resched unconditionally so it could make a problem in atomic context if the task is reschedule. BUG: sleeping function called from invalid context at mm/vmalloc.c:108 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 946, name: memhog 3 locks held by memhog/946: #0: ffff9d01d4b193e8 (&mm->mmap_lock#2){++++}-{4:4}, at: __mm_populate+0x103/0x160 #1: ffffffffa3d53de0 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0xa98/0x1160 #2: ffff9d01d56b8110 (&zspage->lock){.+.+}-{3:3}, at: zs_map_object+0x8e/0x1f0 CPU: 0 PID: 946 Comm: memhog Not tainted 5.9.3-00011-gc5bfc0287345-dirty raspberrypi#316 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 Call Trace: unmap_kernel_range_noflush+0x2eb/0x350 unmap_kernel_range+0x14/0x30 zs_unmap_object+0xd5/0xe0 zram_bvec_rw.isra.0+0x38c/0x8e0 zram_rw_page+0x90/0x101 bdev_write_page+0x92/0xe0 __swap_writepage+0x94/0x4a0 pageout+0xe3/0x3a0 shrink_page_list+0xb94/0xd60 shrink_inactive_list+0x158/0x460 We can fix this by removing the ZSMALLOC_PGTABLE_MAPPING feature (which contains the offending calling code) from zsmalloc. Even though this option showed some amount improvement(e.g., 30%) in some arm32 platforms, it has been headache to maintain since it have abused APIs[1](e.g., unmap_kernel_range in atomic context). Since we are approaching to deprecate 32bit machines and already made the config option available for only builtin build since v5.8, lastly it has been not default option in zsmalloc, it's time to drop the option for better maintenance. [1] http://lore.kernel.org/linux-mm/[email protected] Fixes: e47110e ("mm/vunmap: add cond_resched() in vunmap_pmd_range") Signed-off-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Sergey Senozhatsky <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Harish Sriram <[email protected]> Cc: Uladzislau Rezki <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1 parent 3349f1e commit 69dc72f

File tree

3 files changed

+0
-60
lines changed

3 files changed

+0
-60
lines changed

include/linux/zsmalloc.h

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,6 @@
2020
* zsmalloc mapping modes
2121
*
2222
* NOTE: These only make a difference when a mapped object spans pages.
23-
* They also have no effect when PGTABLE_MAPPING is selected.
2423
*/
2524
enum zs_mapmode {
2625
ZS_MM_RW, /* normal read-write mapping */

mm/Kconfig

Lines changed: 0 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -576,19 +576,6 @@ config ZSMALLOC
576576
returned by an alloc(). This handle must be mapped in order to
577577
access the allocated space.
578578

579-
config PGTABLE_MAPPING
580-
bool "Use page table mapping to access object in zsmalloc"
581-
depends on ZSMALLOC
582-
help
583-
By default, zsmalloc uses a copy-based object mapping method to
584-
access allocations that span two pages. However, if a particular
585-
architecture (ex, ARM) performs VM mapping faster than copying,
586-
then you should select this. This causes zsmalloc to use page table
587-
mapping rather than copying for object mapping.
588-
589-
You can check speed with zsmalloc benchmark:
590-
https://github.com/spartacus06/zsmapbench
591-
592579
config ZSMALLOC_STAT
593580
bool "Export zsmalloc statistics"
594581
depends on ZSMALLOC

mm/zsmalloc.c

Lines changed: 0 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -293,11 +293,7 @@ struct zspage {
293293
};
294294

295295
struct mapping_area {
296-
#ifdef CONFIG_PGTABLE_MAPPING
297-
struct vm_struct *vm; /* vm area for mapping object that span pages */
298-
#else
299296
char *vm_buf; /* copy buffer for objects that span pages */
300-
#endif
301297
char *vm_addr; /* address of kmap_atomic()'ed pages */
302298
enum zs_mapmode vm_mm; /* mapping mode */
303299
};
@@ -1113,46 +1109,6 @@ static struct zspage *find_get_zspage(struct size_class *class)
11131109
return zspage;
11141110
}
11151111

1116-
#ifdef CONFIG_PGTABLE_MAPPING
1117-
static inline int __zs_cpu_up(struct mapping_area *area)
1118-
{
1119-
/*
1120-
* Make sure we don't leak memory if a cpu UP notification
1121-
* and zs_init() race and both call zs_cpu_up() on the same cpu
1122-
*/
1123-
if (area->vm)
1124-
return 0;
1125-
area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
1126-
if (!area->vm)
1127-
return -ENOMEM;
1128-
return 0;
1129-
}
1130-
1131-
static inline void __zs_cpu_down(struct mapping_area *area)
1132-
{
1133-
if (area->vm)
1134-
free_vm_area(area->vm);
1135-
area->vm = NULL;
1136-
}
1137-
1138-
static inline void *__zs_map_object(struct mapping_area *area,
1139-
struct page *pages[2], int off, int size)
1140-
{
1141-
BUG_ON(map_vm_area(area->vm, PAGE_KERNEL, pages));
1142-
area->vm_addr = area->vm->addr;
1143-
return area->vm_addr + off;
1144-
}
1145-
1146-
static inline void __zs_unmap_object(struct mapping_area *area,
1147-
struct page *pages[2], int off, int size)
1148-
{
1149-
unsigned long addr = (unsigned long)area->vm_addr;
1150-
1151-
unmap_kernel_range(addr, PAGE_SIZE * 2);
1152-
}
1153-
1154-
#else /* CONFIG_PGTABLE_MAPPING */
1155-
11561112
static inline int __zs_cpu_up(struct mapping_area *area)
11571113
{
11581114
/*
@@ -1233,8 +1189,6 @@ static void __zs_unmap_object(struct mapping_area *area,
12331189
pagefault_enable();
12341190
}
12351191

1236-
#endif /* CONFIG_PGTABLE_MAPPING */
1237-
12381192
static int zs_cpu_prepare(unsigned int cpu)
12391193
{
12401194
struct mapping_area *area;

0 commit comments

Comments
 (0)