Dear Linux folks,
Running `sudo make kselftest` with Linux 4.15+ built from commit
3da90b159b14 (Merge tag 'f2fs-for-4.16-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs) it stops at
```
[…]
TAP version 13
selftests: main.sh
========================================
pid 19166's current affinity mask: f
pid 19166's new affinity mask: 1
```
The traces below are shown in the log.
> [ 741.295745] ------------[ cut here ]------------
> [ 741.295748] Trying to vfree() nonexistent vm area (000000005d3b34b9)
> [ 741.295767] WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
> [ 741.295768] Modules linked in: test_firmware ccm cmac rfcomm bnep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core btusb btrtl videodev btbcm btintel media bluetooth ecdh_generic snd_hrtimer snd_seq snd_seq_device intel_rapl x86_pkg_temp_thermal binfmt_misc intel_powerclamp coretemp kvm_intel kvm nls_iso8859_1 snd_hda_codec_hdmi arc4 irqbypass snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul snd_hda_codec_generic iwlmvm ghash_clmulni_intel pcbc mac80211 snd_hda_intel aesni_intel aes_x86_64 crypto_simd snd_hda_codec glue_helper cryptd snd_hda_core snd_hwdep intel_cstate iwlwifi intel_rapl_perf snd_pcm snd_timer input_leds joydev serio_raw snd cfg80211 soundcore mei_me mei shpchp intel_pch_thermal tpm_crb acpi_pad mac_hid parport_pc ppdev lp parport dm_crypt ip_tables x_tables
> [ 741.295829] autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops r8169 psmouse mii ahci drm libahci wmi video
> [ 741.295861] CPU: 2 PID: 13215 Comm: mem-on-off-test Not tainted 4.15.0+ #21
> [ 741.295863] Hardware name: Notebook N24_25BU/N24_25BU, BIOS 5.12 07/07/2017
> [ 741.295867] RIP: 0010:__vunmap+0x147/0x190
> [ 741.295868] RSP: 0018:ffff8806210b77f0 EFLAGS: 00010286
> [ 741.295871] RAX: 0000000000000000 RBX: ffffed0001000000 RCX: 0000000000000000
> [ 741.295873] RDX: 0000000000000007 RSI: 1ffff100c4216eb3 RDI: ffff880812b1f5f0
> [ 741.295875] RBP: 0000000000000000 R08: fffffbfff71ef2e5 R09: 1ffff100c4216e83
> [ 741.295877] R10: ffff8806ad34f6f8 R11: fffffbfff71ef2e4 R12: 0000000000000001
> [ 741.295880] R13: ffffed00c4216f16 R14: ffff8806210b78b0 R15: ffffffffb8728820
> [ 741.295883] FS: 00007fcb78078740(0000) GS:ffff880812b00000(0000) knlGS:0000000000000000
> [ 741.295884] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 741.295886] CR2: 0000000000714dc0 CR3: 00000006c7b8a004 CR4: 00000000003606e0
> [ 741.295888] Call Trace:
> [ 741.295895] kasan_mem_notifier+0xad/0xb9
> [ 741.295899] notifier_call_chain+0x166/0x260
> [ 741.295904] ? SyS_setns+0x240/0x240
> [ 741.295907] ? _cond_resched+0x17/0x60
> [ 741.295910] ? down_read+0x7f/0x110
> [ 741.295912] ? down_write_killable+0x100/0x100
> [ 741.295916] ? online_memory_block+0x10/0x10
> [ 741.295920] ? __bitmap_weight+0x3b/0xc0
> [ 741.295924] __blocking_notifier_call_chain+0xdb/0x140
> [ 741.295928] ? srcu_notifier_call_chain+0x10/0x10
> [ 741.295931] ? cpumask_next+0x1c/0x40
> [ 741.295935] __offline_pages+0x96a/0xb10
> [ 741.295941] ? online_pages+0x550/0x550
> [ 741.295944] ? _cond_resched+0x17/0x60
> [ 741.295946] ? down_write+0xa6/0xf0
> [ 741.295950] ? __down_killable+0x510/0x510
> [ 741.295954] ? _find_next_bit+0x8e/0xf0
> [ 741.295959] ? percpu_down_write+0x308/0x420
> [ 741.295964] ? __percpu_up_read+0x40/0x40
> [ 741.295967] ? locks_remove_posix+0xf9/0x400
> [ 741.295970] ? klist_next+0x10f/0x240
> [ 741.295974] ? klist_iter_exit+0x16/0x50
> [ 741.295978] ? rcu_sched_qs.part.49+0x70/0x70
> [ 741.295981] ? device_remove_class_symlinks+0x110/0x110
> [ 741.295985] ? show_auto_online_blocks+0x70/0x70
> [ 741.295988] memory_subsys_offline+0x76/0xc0
> [ 741.295991] device_offline+0xb8/0x120
> [ 741.295995] store_mem_state+0xfa/0x120
> [ 741.296000] kernfs_fop_write+0x1d5/0x320
> [ 741.296004] ? sysfs_kf_bin_read+0x1b0/0x1b0
> [ 741.296008] __vfs_write+0xd4/0x530
> [ 741.296012] ? __fget_light+0x1c3/0x2a0
> [ 741.296015] ? kernel_read+0x100/0x100
> [ 741.296020] ? apparmor_task_setrlimit+0x470/0x470
> [ 741.296026] ? vfs_fallocate+0x4f0/0x4f0
> [ 741.296029] ? SyS_dup2+0x297/0x4e0
> [ 741.296033] ? f_getown+0x80/0x80
> [ 741.296036] ? rcu_sched_qs.part.49+0x70/0x70
> [ 741.296040] vfs_write+0x105/0x340
> [ 741.296044] SyS_write+0xb0/0x140
> [ 741.296047] ? SyS_read+0x140/0x140
> [ 741.296052] entry_SYSCALL_64_fastpath+0x24/0x87
> [ 741.296088] RIP: 0033:0x7fcb777890c4
> [ 741.296090] RSP: 002b:00007ffc5dbf6888 EFLAGS: 00000246
> [ 741.296093] Code: 48 89 fe 48 c7 c7 40 82 71 b5 e8 a5 57 bf ff 0f ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 de 48 c7 c7 a0 82 71 b5 e8 89 57 bf ff <0f> ff eb e2 48 63 f3 ba 01 00 00 00 4c 89 ff e8 d1 c8 68 00 e9
> [ 741.296136] ---[ end trace a2224ce39f83d90a ]---
> [ 741.302360] Offlined Pages 32768
> [ 741.302915] ------------[ cut here ]------------
> [ 741.302918] Trying to vfree() nonexistent vm area (0000000048fb8dce)
> [ 741.302933] WARNING: CPU: 1 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
> [ 741.302934] Modules linked in: test_firmware ccm cmac rfcomm bnep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core btusb btrtl videodev btbcm btintel media bluetooth ecdh_generic snd_hrtimer snd_seq snd_seq_device intel_rapl x86_pkg_temp_thermal binfmt_misc intel_powerclamp coretemp kvm_intel kvm nls_iso8859_1 snd_hda_codec_hdmi arc4 irqbypass snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul snd_hda_codec_generic iwlmvm ghash_clmulni_intel pcbc mac80211 snd_hda_intel aesni_intel aes_x86_64 crypto_simd snd_hda_codec glue_helper cryptd snd_hda_core snd_hwdep intel_cstate iwlwifi intel_rapl_perf snd_pcm snd_timer input_leds joydev serio_raw snd cfg80211 soundcore mei_me mei shpchp intel_pch_thermal tpm_crb acpi_pad mac_hid parport_pc ppdev lp parport dm_crypt ip_tables x_tables
> [ 741.302978] autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops r8169 psmouse mii ahci drm libahci wmi video
> [ 741.303002] CPU: 1 PID: 13215 Comm: mem-on-off-test Tainted: G W 4.15.0+ #21
> [ 741.303003] Hardware name: Notebook N24_25BU/N24_25BU, BIOS 5.12 07/07/2017
> [ 741.303007] RIP: 0010:__vunmap+0x147/0x190
> [ 741.303008] RSP: 0018:ffff8806210b77f0 EFLAGS: 00010286
> [ 741.303010] RAX: 0000000000000000 RBX: ffffed000a000000 RCX: 0000000000000000
> [ 741.303011] RDX: 0000000000000007 RSI: 1ffff100c4216eb3 RDI: ffff880812a9f5f0
> [ 741.303012] RBP: 0000000000000000 R08: fffffbfff71ef2e5 R09: 1ffff100c4216e83
> [ 741.303013] R10: ffff88072da876f8 R11: fffffbfff71ef2e4 R12: 0000000000000001
> [ 741.303015] R13: ffffed00c4216f16 R14: ffff8806210b78b0 R15: ffffffffb8728820
> [ 741.303016] FS: 00007fcb78078740(0000) GS:ffff880812a80000(0000) knlGS:0000000000000000
> [ 741.303018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 741.303019] CR2: 0000000000f094e0 CR3: 00000006c7b8a002 CR4: 00000000003606e0
> [ 741.303020] Call Trace:
> [ 741.303025] kasan_mem_notifier+0xad/0xb9
> [ 741.303028] notifier_call_chain+0x166/0x260
> [ 741.303031] ? SyS_setns+0x240/0x240
> [ 741.303033] ? _cond_resched+0x17/0x60
> [ 741.303036] ? down_read+0x7f/0x110
> [ 741.303038] ? down_write_killable+0x100/0x100
> [ 741.303041] ? online_memory_block+0x10/0x10
> [ 741.303044] ? __bitmap_weight+0x3b/0xc0
> [ 741.303046] __blocking_notifier_call_chain+0xdb/0x140
> [ 741.303049] ? srcu_notifier_call_chain+0x10/0x10
> [ 741.303052] ? cpumask_next+0x1c/0x40
> [ 741.303054] __offline_pages+0x96a/0xb10
> [ 741.303057] ? online_pages+0x550/0x550
> [ 741.303059] ? _cond_resched+0x17/0x60
> [ 741.303061] ? down_write+0xa6/0xf0
> [ 741.303063] ? __down_killable+0x510/0x510
> [ 741.303065] ? _find_next_bit+0x8e/0xf0
> [ 741.303068] ? percpu_down_write+0x308/0x420
> [ 741.303071] ? __percpu_up_read+0x40/0x40
> [ 741.303073] ? locks_remove_posix+0xf9/0x400
> [ 741.303076] ? klist_next+0x10f/0x240
> [ 741.303078] ? klist_iter_exit+0x16/0x50
> [ 741.303081] ? rcu_sched_qs.part.49+0x70/0x70
> [ 741.303083] ? device_remove_class_symlinks+0x110/0x110
> [ 741.303086] ? show_auto_online_blocks+0x70/0x70
> [ 741.303088] memory_subsys_offline+0x76/0xc0
> [ 741.303091] device_offline+0xb8/0x120
> [ 741.303093] store_mem_state+0xfa/0x120
> [ 741.303097] kernfs_fop_write+0x1d5/0x320
> [ 741.303099] ? sysfs_kf_bin_read+0x1b0/0x1b0
> [ 741.303102] __vfs_write+0xd4/0x530
> [ 741.303105] ? __fget_light+0x1c3/0x2a0
> [ 741.303107] ? kernel_read+0x100/0x100
> [ 741.303110] ? apparmor_task_setrlimit+0x470/0x470
> [ 741.303113] ? vfs_fallocate+0x4f0/0x4f0
> [ 741.303115] ? SyS_dup2+0x297/0x4e0
> [ 741.303118] ? f_getown+0x80/0x80
> [ 741.303120] ? rcu_sched_qs.part.49+0x70/0x70
> [ 741.303123] vfs_write+0x105/0x340
> [ 741.303126] SyS_write+0xb0/0x140
> [ 741.303127] ? SyS_read+0x140/0x140
> [ 741.303131] entry_SYSCALL_64_fastpath+0x24/0x87
> [ 741.303158] RIP: 0033:0x7fcb777890c4
> [ 741.303160] RSP: 002b:00007ffc5dbf6888 EFLAGS: 00000246
> [ 741.303162] Code: 48 89 fe 48 c7 c7 40 82 71 b5 e8 a5 57 bf ff 0f ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 de 48 c7 c7 a0 82 71 b5 e8 89 57 bf ff <0f> ff eb e2 48 63 f3 ba 01 00 00 00 4c 89 ff e8 d1 c8 68 00 e9
> [ 741.303194] ---[ end trace a2224ce39f83d90b ]---
> [ 741.309520] Offlined Pages 32768
> [ 741.309961] ------------[ cut here ]------------
> [ 741.309963] Trying to vfree() nonexistent vm area (00000000ac162129)
> [ 741.309978] WARNING: CPU: 3 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
> [ 741.309978] Modules linked in: test_firmware ccm cmac rfcomm bnep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core btusb btrtl videodev btbcm btintel media bluetooth ecdh_generic snd_hrtimer snd_seq snd_seq_device intel_rapl x86_pkg_temp_thermal binfmt_misc intel_powerclamp coretemp kvm_intel kvm nls_iso8859_1 snd_hda_codec_hdmi arc4 irqbypass snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul snd_hda_codec_generic iwlmvm ghash_clmulni_intel pcbc mac80211 snd_hda_intel aesni_intel aes_x86_64 crypto_simd snd_hda_codec glue_helper cryptd snd_hda_core snd_hwdep intel_cstate iwlwifi intel_rapl_perf snd_pcm snd_timer input_leds joydev serio_raw snd cfg80211 soundcore mei_me mei shpchp intel_pch_thermal tpm_crb acpi_pad mac_hid parport_pc ppdev lp parport dm_crypt ip_tables x_tables
> [ 741.310022] autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops r8169 psmouse mii ahci drm libahci wmi video
> [ 741.310045] CPU: 3 PID: 13215 Comm: mem-on-off-test Tainted: G W 4.15.0+ #21
> [ 741.310046] Hardware name: Notebook N24_25BU/N24_25BU, BIOS 5.12 07/07/2017
> [ 741.310048] RIP: 0010:__vunmap+0x147/0x190
> [ 741.310049] RSP: 0018:ffff8806210b77f0 EFLAGS: 00010286
> [ 741.310051] RAX: 0000000000000000 RBX: ffffed0064000000 RCX: 0000000000000000
> [ 741.310053] RDX: 0000000000000007 RSI: 1ffff100c4216eb3 RDI: ffff880812b9f5f0
> [ 741.310054] RBP: 0000000000000000 R08: fffffbfff71ef2e5 R09: 1ffff100c4216e83
> [ 741.310055] R10: ffff8806b99c76f8 R11: fffffbfff71ef2e4 R12: 0000000000000001
> [ 741.310056] R13: ffffed00c4216f16 R14: ffff8806210b78b0 R15: ffffffffb8728820
> [ 741.310058] FS: 00007fcb78078740(0000) GS:ffff880812b80000(0000) knlGS:0000000000000000
> [ 741.310059] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 741.310060] CR2: 000000000070f070 CR3: 00000006c7b8a002 CR4: 00000000003606e0
> [ 741.310061] Call Trace:
> [ 741.310067] kasan_mem_notifier+0xad/0xb9
> [ 741.310070] notifier_call_chain+0x166/0x260
> [ 741.310073] ? SyS_setns+0x240/0x240
> [ 741.310075] ? _cond_resched+0x17/0x60
> [ 741.310077] ? down_read+0x7f/0x110
> [ 741.310079] ? down_write_killable+0x100/0x100
> [ 741.310082] ? online_memory_block+0x10/0x10
> [ 741.310084] ? __bitmap_weight+0x3b/0xc0
> [ 741.310087] __blocking_notifier_call_chain+0xdb/0x140
> [ 741.310091] ? srcu_notifier_call_chain+0x10/0x10
> [ 741.310094] ? cpumask_next+0x1c/0x40
> [ 741.310097] __offline_pages+0x96a/0xb10
> [ 741.310100] ? online_pages+0x550/0x550
> [ 741.310102] ? _cond_resched+0x17/0x60
> [ 741.310104] ? down_write+0xa6/0xf0
> [ 741.310106] ? __down_killable+0x510/0x510
> [ 741.310108] ? _find_next_bit+0x8e/0xf0
> [ 741.310111] ? percpu_down_write+0x308/0x420
> [ 741.310113] ? __percpu_up_read+0x40/0x40
> [ 741.310116] ? locks_remove_posix+0xf9/0x400
> [ 741.310118] ? klist_next+0x10f/0x240
> [ 741.310120] ? klist_iter_exit+0x16/0x50
> [ 741.310123] ? rcu_sched_qs.part.49+0x70/0x70
> [ 741.310125] ? device_remove_class_symlinks+0x110/0x110
> [ 741.310128] ? show_auto_online_blocks+0x70/0x70
> [ 741.310130] memory_subsys_offline+0x76/0xc0
> [ 741.310132] device_offline+0xb8/0x120
> [ 741.310135] store_mem_state+0xfa/0x120
> [ 741.310138] kernfs_fop_write+0x1d5/0x320
> [ 741.310140] ? sysfs_kf_bin_read+0x1b0/0x1b0
> [ 741.310143] __vfs_write+0xd4/0x530
> [ 741.310146] ? __fget_light+0x1c3/0x2a0
> [ 741.310147] ? kernel_read+0x100/0x100
> [ 741.310150] ? apparmor_task_setrlimit+0x470/0x470
> [ 741.310153] ? vfs_fallocate+0x4f0/0x4f0
> [ 741.310155] ? SyS_dup2+0x297/0x4e0
> [ 741.310158] ? f_getown+0x80/0x80
> [ 741.310160] ? rcu_sched_qs.part.49+0x70/0x70
> [ 741.310163] vfs_write+0x105/0x340
> [ 741.310166] SyS_write+0xb0/0x140
> [ 741.310168] ? SyS_read+0x140/0x140
> [ 741.310171] entry_SYSCALL_64_fastpath+0x24/0x87
> [ 741.310194] RIP: 0033:0x7fcb777890c4
> [ 741.310195] RSP: 002b:00007ffc5dbf6888 EFLAGS: 00000246
> [ 741.310198] Code: 48 89 fe 48 c7 c7 40 82 71 b5 e8 a5 57 bf ff 0f ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 de 48 c7 c7 a0 82 71 b5 e8 89 57 bf ff <0f> ff eb e2 48 63 f3 ba 01 00 00 00 4c 89 ff e8 d1 c8 68 00 e9
> [ 741.310229] ---[ end trace a2224ce39f83d90c ]---
I am sorry, if this is the wrong subsystem to report such issues to.
Please tell me the right place.
Kind regards,
Paul
KASAN uses different routines to map shadow for hot added memory and memory
obtained in boot process. Attempt to offline memory onlined by normal boot
process leads to this:
Trying to vfree() nonexistent vm area (000000005d3b34b9)
WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
Call Trace:
kasan_mem_notifier+0xad/0xb9
notifier_call_chain+0x166/0x260
__blocking_notifier_call_chain+0xdb/0x140
__offline_pages+0x96a/0xb10
memory_subsys_offline+0x76/0xc0
device_offline+0xb8/0x120
store_mem_state+0xfa/0x120
kernfs_fop_write+0x1d5/0x320
__vfs_write+0xd4/0x530
vfs_write+0x105/0x340
SyS_write+0xb0/0x140
Obviously we can't call vfree() to free memory that wasn't allocated via
vmalloc(). Use find_vm_area() to see if we can call vfree().
Unfortunately it's a bit tricky to properly unmap and free shadow allocated
during boot, so we'll have to keep it. If memory will come online again
that shadow will be reused.
Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
Reported-by: Paul Menzel <[email protected]>
Signed-off-by: Andrey Ryabinin <[email protected]>
Cc: <[email protected]>
---
mm/kasan/kasan.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index e13d911251e7..0d9d9d268f32 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -791,6 +791,41 @@ DEFINE_ASAN_SET_SHADOW(f5);
DEFINE_ASAN_SET_SHADOW(f8);
#ifdef CONFIG_MEMORY_HOTPLUG
+static bool shadow_mapped(unsigned long addr)
+{
+ pgd_t *pgd = pgd_offset_k(addr);
+ p4d_t *p4d;
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+
+ if (pgd_none(*pgd))
+ return false;
+ p4d = p4d_offset(pgd, addr);
+ if (p4d_none(*p4d))
+ return false;
+ pud = pud_offset(p4d, addr);
+ if (pud_none(*pud))
+ return false;
+
+ /*
+ * We can't use pud_large() or pud_huge(), the first one
+ * is arch-specific, the last one depend on HUGETLB_PAGE.
+ * So let's abuse pud_bad(), if bud is bad it's has to
+ * because it's huge.
+ */
+ if (pud_bad(*pud))
+ return true;
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+ return false;
+
+ if (pmd_bad(*pmd))
+ return true;
+ pte = pte_offset_kernel(pmd, addr);
+ return !pte_none(*pte);
+}
+
static int __meminit kasan_mem_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -812,6 +847,14 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
case MEM_GOING_ONLINE: {
void *ret;
+ /*
+ * If shadow is mapped already than it must have been mapped
+ * during the boot. This could happen if we onlining previously
+ * offlined memory.
+ */
+ if (shadow_mapped(shadow_start))
+ return NOTIFY_OK;
+
ret = __vmalloc_node_range(shadow_size, PAGE_SIZE, shadow_start,
shadow_end, GFP_KERNEL,
PAGE_KERNEL, VM_NO_GUARD,
@@ -823,8 +866,18 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
kmemleak_ignore(ret);
return NOTIFY_OK;
}
- case MEM_OFFLINE:
- vfree((void *)shadow_start);
+ case MEM_OFFLINE: {
+ struct vm_struct *vm;
+
+ /*
+ * Only hot-added memory have vm_area. Freeing shadow
+ * mapped during boot would be tricky, so we'll just
+ * have to keep it.
+ */
+ vm = find_vm_area((void *)shadow_start);
+ if (vm)
+ vfree((void *)shadow_start);
+ }
}
return NOTIFY_OK;
--
2.13.6
On Thu, Feb 01, 2018 at 07:33:49PM +0300, Andrey Ryabinin wrote:
> + case MEM_OFFLINE: {
> + struct vm_struct *vm;
> +
> + /*
> + * Only hot-added memory have vm_area. Freeing shadow
> + * mapped during boot would be tricky, so we'll just
> + * have to keep it.
> + */
> + vm = find_vm_area((void *)shadow_start);
> + if (vm)
> + vfree((void *)shadow_start);
> + }
This looks like a complicated way to spell 'is_vmalloc_addr' ...
On 02/01/2018 10:57 PM, Matthew Wilcox wrote:
> On Thu, Feb 01, 2018 at 07:33:49PM +0300, Andrey Ryabinin wrote:
>> + case MEM_OFFLINE: {
>> + struct vm_struct *vm;
>> +
>> + /*
>> + * Only hot-added memory have vm_area. Freeing shadow
>> + * mapped during boot would be tricky, so we'll just
>> + * have to keep it.
>> + */
>> + vm = find_vm_area((void *)shadow_start);
>> + if (vm)
>> + vfree((void *)shadow_start);
>> + }
>
> This looks like a complicated way to spell 'is_vmalloc_addr' ...
>
It's not. shadow_start is never vmalloc address.
On Thu, Feb 01, 2018 at 11:22:55PM +0300, Andrey Ryabinin wrote:
> >> + vm = find_vm_area((void *)shadow_start);
> >> + if (vm)
> >> + vfree((void *)shadow_start);
> >> + }
> >
> > This looks like a complicated way to spell 'is_vmalloc_addr' ...
> >
>
> It's not. shadow_start is never vmalloc address.
I'm confused. How can you call vfree() on something that isn't a vmalloc
address?
On 02/02/2018 08:20 PM, Matthew Wilcox wrote:
> On Thu, Feb 01, 2018 at 11:22:55PM +0300, Andrey Ryabinin wrote:
>>>> + vm = find_vm_area((void *)shadow_start);
>>>> + if (vm)
>>>> + vfree((void *)shadow_start);
>>>> + }
>>>
>>> This looks like a complicated way to spell 'is_vmalloc_addr' ...
>>>
>>
>> It's not. shadow_start is never vmalloc address.
>
> I'm confused. How can you call vfree() on something that isn't a vmalloc
> address?
>
vfree() is able to free any address returned by __vmalloc_node_range().
And __vmalloc_node_range() gives you any address you ask.
It doesn't have to be an address in [VMALLOC_START, VMALLOC_END] range.
That's also how the module_alloc()/module_memfree() works on architectures that
have designated area for modules.
On 01.02.2018 17:33, Andrey Ryabinin wrote:
> KASAN uses different routines to map shadow for hot added memory and memory
> obtained in boot process. Attempt to offline memory onlined by normal boot
> process leads to this:
>
> Trying to vfree() nonexistent vm area (000000005d3b34b9)
> WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
>
> Call Trace:
> kasan_mem_notifier+0xad/0xb9
> notifier_call_chain+0x166/0x260
> __blocking_notifier_call_chain+0xdb/0x140
> __offline_pages+0x96a/0xb10
> memory_subsys_offline+0x76/0xc0
> device_offline+0xb8/0x120
> store_mem_state+0xfa/0x120
> kernfs_fop_write+0x1d5/0x320
> __vfs_write+0xd4/0x530
> vfs_write+0x105/0x340
> SyS_write+0xb0/0x140
>
> Obviously we can't call vfree() to free memory that wasn't allocated via
> vmalloc(). Use find_vm_area() to see if we can call vfree().
>
> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
> during boot, so we'll have to keep it. If memory will come online again
> that shadow will be reused.
>
While debugging kasan memory hotplug problems I am having, stumbled over
this patch.
Couldn't we handle that via VM_KASAN like in kasan_module_alloc/free
instead?
> Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
> Reported-by: Paul Menzel <[email protected]>
> Signed-off-by: Andrey Ryabinin <[email protected]>
> Cc: <[email protected]>
> ---
> mm/kasan/kasan.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index e13d911251e7..0d9d9d268f32 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -791,6 +791,41 @@ DEFINE_ASAN_SET_SHADOW(f5);
> DEFINE_ASAN_SET_SHADOW(f8);
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +static bool shadow_mapped(unsigned long addr)
> +{
> + pgd_t *pgd = pgd_offset_k(addr);
> + p4d_t *p4d;
> + pud_t *pud;
> + pmd_t *pmd;
> + pte_t *pte;
> +
> + if (pgd_none(*pgd))
> + return false;
> + p4d = p4d_offset(pgd, addr);
> + if (p4d_none(*p4d))
> + return false;
> + pud = pud_offset(p4d, addr);
> + if (pud_none(*pud))
> + return false;
> +
> + /*
> + * We can't use pud_large() or pud_huge(), the first one
> + * is arch-specific, the last one depend on HUGETLB_PAGE.
> + * So let's abuse pud_bad(), if bud is bad it's has to
> + * because it's huge.
> + */
> + if (pud_bad(*pud))
> + return true;
> + pmd = pmd_offset(pud, addr);
> + if (pmd_none(*pmd))
> + return false;
> +
> + if (pmd_bad(*pmd))
> + return true;
> + pte = pte_offset_kernel(pmd, addr);
> + return !pte_none(*pte);
> +}
> +
> static int __meminit kasan_mem_notifier(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> @@ -812,6 +847,14 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
> case MEM_GOING_ONLINE: {
> void *ret;
>
> + /*
> + * If shadow is mapped already than it must have been mapped
> + * during the boot. This could happen if we onlining previously
> + * offlined memory.
> + */
> + if (shadow_mapped(shadow_start))
> + return NOTIFY_OK;
> +
> ret = __vmalloc_node_range(shadow_size, PAGE_SIZE, shadow_start,
> shadow_end, GFP_KERNEL,
> PAGE_KERNEL, VM_NO_GUARD,
> @@ -823,8 +866,18 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
> kmemleak_ignore(ret);
> return NOTIFY_OK;
> }
> - case MEM_OFFLINE:
> - vfree((void *)shadow_start);
> + case MEM_OFFLINE: {
> + struct vm_struct *vm;
> +
> + /*
> + * Only hot-added memory have vm_area. Freeing shadow
> + * mapped during boot would be tricky, so we'll just
> + * have to keep it.
> + */
> + vm = find_vm_area((void *)shadow_start);
> + if (vm)
> + vfree((void *)shadow_start);
> + }
> }
>
> return NOTIFY_OK;
>
--
Thanks,
David / dhildenb
On 18.05.2018 17:57, David Hildenbrand wrote:
> On 01.02.2018 17:33, Andrey Ryabinin wrote:
>> KASAN uses different routines to map shadow for hot added memory and memory
>> obtained in boot process. Attempt to offline memory onlined by normal boot
>> process leads to this:
>>
>> Trying to vfree() nonexistent vm area (000000005d3b34b9)
>> WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
>>
>> Call Trace:
>> kasan_mem_notifier+0xad/0xb9
>> notifier_call_chain+0x166/0x260
>> __blocking_notifier_call_chain+0xdb/0x140
>> __offline_pages+0x96a/0xb10
>> memory_subsys_offline+0x76/0xc0
>> device_offline+0xb8/0x120
>> store_mem_state+0xfa/0x120
>> kernfs_fop_write+0x1d5/0x320
>> __vfs_write+0xd4/0x530
>> vfs_write+0x105/0x340
>> SyS_write+0xb0/0x140
>>
>> Obviously we can't call vfree() to free memory that wasn't allocated via
>> vmalloc(). Use find_vm_area() to see if we can call vfree().
>>
>> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
>> during boot, so we'll have to keep it. If memory will come online again
>> that shadow will be reused.
>>
>
> While debugging kasan memory hotplug problems I am having, stumbled over
> this patch.
>
> Couldn't we handle that via VM_KASAN like in kasan_module_alloc/free
> instead?
>
Just realized that this will most probably not work. So please ignore my
comment for now :)
--
Thanks,
David / dhildenb
On 02/01/2018 07:33 PM, Andrey Ryabinin wrote:
> KASAN uses different routines to map shadow for hot added memory and memory
> obtained in boot process. Attempt to offline memory onlined by normal boot
> process leads to this:
>
> Trying to vfree() nonexistent vm area (000000005d3b34b9)
> WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
>
> Call Trace:
> kasan_mem_notifier+0xad/0xb9
> notifier_call_chain+0x166/0x260
> __blocking_notifier_call_chain+0xdb/0x140
> __offline_pages+0x96a/0xb10
> memory_subsys_offline+0x76/0xc0
> device_offline+0xb8/0x120
> store_mem_state+0xfa/0x120
> kernfs_fop_write+0x1d5/0x320
> __vfs_write+0xd4/0x530
> vfs_write+0x105/0x340
> SyS_write+0xb0/0x140
>
> Obviously we can't call vfree() to free memory that wasn't allocated via
> vmalloc(). Use find_vm_area() to see if we can call vfree().
>
> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
> during boot, so we'll have to keep it. If memory will come online again
> that shadow will be reused.
>
> Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
> Reported-by: Paul Menzel <[email protected]>
> Signed-off-by: Andrey Ryabinin <[email protected]>
> Cc: <[email protected]>
> ---
This seems stuck in -mm. Andrew, can we proceed?
On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin <[email protected]> wrote:
> > Obviously we can't call vfree() to free memory that wasn't allocated via
> > vmalloc(). Use find_vm_area() to see if we can call vfree().
> >
> > Unfortunately it's a bit tricky to properly unmap and free shadow allocated
> > during boot, so we'll have to keep it. If memory will come online again
> > that shadow will be reused.
> >
> > Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
> > Reported-by: Paul Menzel <[email protected]>
> > Signed-off-by: Andrey Ryabinin <[email protected]>
> > Cc: <[email protected]>
> > ---
>
> This seems stuck in -mm. Andrew, can we proceed?
OK.
Should there be a code comment explaining the situation that Matthew
asked about? It's rather obscure.
On 05/23/2018 12:03 AM, Andrew Morton wrote:
> On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin <[email protected]> wrote:
>
>>> Obviously we can't call vfree() to free memory that wasn't allocated via
>>> vmalloc(). Use find_vm_area() to see if we can call vfree().
>>>
>>> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
>>> during boot, so we'll have to keep it. If memory will come online again
>>> that shadow will be reused.
>>>
>>> Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
>>> Reported-by: Paul Menzel <[email protected]>
>>> Signed-off-by: Andrey Ryabinin <[email protected]>
>>> Cc: <[email protected]>
>>> ---
>>
>> This seems stuck in -mm. Andrew, can we proceed?
>
> OK.
>
> Should there be a code comment explaining the situation that Matthew
> asked about? It's rather obscure.
>
Ok. Here is my attempt to improve the situation. If something is still not clear,
I'm open to suggestions.
From: Andrey Ryabinin <[email protected]>
Subject: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix
Improve comments.
Signed-off-by: Andrey Ryabinin <[email protected]>
---
mm/kasan/kasan.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 135ce2838c89..ea44dd0bc4e7 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -812,7 +812,7 @@ static bool shadow_mapped(unsigned long addr)
/*
* We can't use pud_large() or pud_huge(), the first one
* is arch-specific, the last one depend on HUGETLB_PAGE.
- * So let's abuse pud_bad(), if bud is bad it's has to
+ * So let's abuse pud_bad(), if pud is bad than it's bad
* because it's huge.
*/
if (pud_bad(*pud))
@@ -871,9 +871,16 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
struct vm_struct *vm;
/*
- * Only hot-added memory have vm_area. Freeing shadow
- * mapped during boot would be tricky, so we'll just
- * have to keep it.
+ * shadow_start was either mapped during boot by kasan_init()
+ * or during memory online by __vmalloc_node_range().
+ * In the latter case we can use vfree() to free shadow.
+ * Non-NULL result of the find_vm_area() will tell us if
+ * that was the second case.
+ *
+ * Currently it's not possible to free shadow mapped
+ * during boot by kasan_init(). It's because the code
+ * to do that hasn't been written yet. So we'll just
+ * leak the memory.
*/
vm = find_vm_area((void *)shadow_start);
if (vm)
--
2.16.1
Hi Andrey,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
[cannot apply to v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-dont-vfree-nonexistent-vm_area-fix/20180526-093255
base: git://git.cmpxchg.org/linux-mmotm.git master
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
fs/autofs/inode.o: In function `autofs_new_ino':
inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
fs/autofs/inode.o: In function `autofs_clean_ino':
inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
fs/autofs/inode.o:inode.c:(.text+0x280): first defined here
fs/autofs/inode.o: In function `autofs_free_ino':
inode.c:(.text+0x2c0): multiple definition of `autofs_free_ino'
fs/autofs/inode.o:inode.c:(.text+0x2c0): first defined here
fs/autofs/inode.o: In function `autofs_kill_sb':
inode.c:(.text+0x2e0): multiple definition of `autofs_kill_sb'
fs/autofs/inode.o:inode.c:(.text+0x2e0): first defined here
fs/autofs/inode.o: In function `autofs_get_inode':
inode.c:(.text+0x360): multiple definition of `autofs_get_inode'
fs/autofs/inode.o:inode.c:(.text+0x360): first defined here
fs/autofs/inode.o: In function `autofs_fill_super':
inode.c:(.text+0x440): multiple definition of `autofs_fill_super'
fs/autofs/inode.o:inode.c:(.text+0x440): first defined here
fs/autofs/root.o: In function `is_autofs_dentry':
root.c:(.text+0x1860): multiple definition of `is_autofs_dentry'
fs/autofs/root.o:root.c:(.text+0x1860): first defined here
fs/autofs/root.o:(.rodata+0x100): multiple definition of `autofs_dentry_operations'
fs/autofs/root.o:(.rodata+0x100): first defined here
fs/autofs/root.o:(.rodata+0x180): multiple definition of `autofs_dir_inode_operations'
fs/autofs/root.o:(.rodata+0x180): first defined here
fs/autofs/root.o:(.rodata+0x240): multiple definition of `autofs_dir_operations'
fs/autofs/root.o:(.rodata+0x240): first defined here
fs/autofs/root.o:(.rodata+0x338): multiple definition of `autofs_root_operations'
fs/autofs/root.o:(.rodata+0x338): first defined here
fs/autofs/symlink.o:(.rodata+0x0): multiple definition of `autofs_symlink_inode_operations'
fs/autofs/symlink.o:(.rodata+0x0): first defined here
fs/autofs/waitq.o: In function `autofs_catatonic_mode':
>> waitq.c:(.text+0x80): multiple definition of `autofs_catatonic_mode'
fs/autofs/waitq.o:waitq.c:(.text+0x80): first defined here
fs/autofs/waitq.o: In function `autofs_wait_release':
>> waitq.c:(.text+0x180): multiple definition of `autofs_wait_release'
fs/autofs/waitq.o:waitq.c:(.text+0x180): first defined here
fs/autofs/waitq.o: In function `autofs_wait':
>> waitq.c:(.text+0x520): multiple definition of `autofs_wait'
fs/autofs/waitq.o:waitq.c:(.text+0x520): first defined here
fs/autofs/expire.o: In function `autofs_expire_direct':
expire.c:(.text+0x7a0): multiple definition of `autofs_expire_direct'
fs/autofs/expire.o:expire.c:(.text+0x7a0): first defined here
fs/autofs/expire.o: In function `autofs_expire_indirect':
expire.c:(.text+0x8e0): multiple definition of `autofs_expire_indirect'
fs/autofs/expire.o:expire.c:(.text+0x8e0): first defined here
fs/autofs/expire.o: In function `autofs_expire_wait':
expire.c:(.text+0xba0): multiple definition of `autofs_expire_wait'
fs/autofs/expire.o:expire.c:(.text+0xba0): first defined here
fs/autofs/expire.o: In function `autofs_expire_run':
expire.c:(.text+0xce0): multiple definition of `autofs_expire_run'
fs/autofs/expire.o:expire.c:(.text+0xce0): first defined here
fs/autofs/expire.o: In function `autofs_do_expire_multi':
expire.c:(.text+0xde0): multiple definition of `autofs_do_expire_multi'
fs/autofs/expire.o:expire.c:(.text+0xde0): first defined here
fs/autofs/expire.o: In function `autofs_expire_multi':
expire.c:(.text+0xea0): multiple definition of `autofs_expire_multi'
fs/autofs/expire.o:expire.c:(.text+0xea0): first defined here
fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_init':
dev-ioctl.c:(.init.text+0x0): multiple definition of `autofs_dev_ioctl_init'
fs/autofs/dev-ioctl.o:dev-ioctl.c:(.init.text+0x0): first defined here
fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_exit':
dev-ioctl.c:(.text+0xbc0): multiple definition of `autofs_dev_ioctl_exit'
fs/autofs/dev-ioctl.o:dev-ioctl.c:(.text+0xbc0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot <[email protected]> wrote:
> Hi Andrey,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on mmotm/master]
> [cannot apply to v4.17-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-dont-vfree-nonexistent-vm_area-fix/20180526-093255
> base: git://git.cmpxchg.org/linux-mmotm.git master
> config: sparc-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc
>
> All errors (new ones prefixed by >>):
>
> fs/autofs/inode.o: In function `autofs_new_ino':
> inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
> fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
> fs/autofs/inode.o: In function `autofs_clean_ino':
> inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
> fs/autofs/inode.o:inode.c:(.text+0x280): first defined here
There's bot breakage here - clearly that patch didn't cause this error.
Ian, this autofs glitch may still not be fixed.
On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote:
> On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot <[email protected]> wrote:
>
> > Hi Andrey,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on mmotm/master]
> > [cannot apply to v4.17-rc6]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-do
> > nt-vfree-nonexistent-vm_area-fix/20180526-093255
> > base: git://git.cmpxchg.org/linux-mmotm.git master
> > config: sparc-allyesconfig (attached as .config)
> > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> > reproduce:
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/m
> > ake.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=sparc
> >
> > All errors (new ones prefixed by >>):
> >
> > fs/autofs/inode.o: In function `autofs_new_ino':
> > inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
> > fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
> > fs/autofs/inode.o: In function `autofs_clean_ino':
> > inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
> > fs/autofs/inode.o:inode.c:(.text+0x280): first defined here
>
> There's bot breakage here - clearly that patch didn't cause this error.
>
> Ian, this autofs glitch may still not be fixed.
Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have
fixed that.
I tied a bunch of .config combinations and I was unable to find any that
lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined.
I must be missing something else, I'll investigate.
Ian
On Mon, 2018-05-28 at 12:13 +0800, Ian Kent wrote:
> On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote:
> > On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot <[email protected]> wrote:
> >
> > > Hi Andrey,
> > >
> > > I love your patch! Yet something to improve:
> > >
> > > [auto build test ERROR on mmotm/master]
> > > [cannot apply to v4.17-rc6]
> > > [if your patch is applied to the wrong git tree, please drop us a note to
> > > help improve the system]
> > >
> > > url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-
> > > do
> > > nt-vfree-nonexistent-vm_area-fix/20180526-093255
> > > base: git://git.cmpxchg.org/linux-mmotm.git master
> > > config: sparc-allyesconfig (attached as .config)
> > > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> > > reproduce:
> > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin
> > > /m
> > > ake.cross -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # save the attached .config to linux build tree
> > > make.cross ARCH=sparc
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > fs/autofs/inode.o: In function `autofs_new_ino':
> > > inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
> > > fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
> > > fs/autofs/inode.o: In function `autofs_clean_ino':
> > > inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
> > > fs/autofs/inode.o:inode.c:(.text+0x280): first defined here
> >
> > There's bot breakage here - clearly that patch didn't cause this error.
> >
> > Ian, this autofs glitch may still not be fixed.
>
> Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have
> fixed that.
>
> I tied a bunch of .config combinations and I was unable to find any that
> lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined.
Oh, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch was sent as
a follow up patch which means it's still possible to have both
CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS set between
autofs-create-autofs-Kconfig-and-Makefile.patch and the above patch.
Perhaps all that's needed is to fold the follow up patch into
autofs-create-autofs-Kconfig-and-Makefile.patch to close that
possibility.
I'll check that can be done without problem.
>
> I must be missing something else, I'll investigate.
And I'll check if there's anything else I'm missing.
Sorry for the inconvenience.
>
> Ian
On Mon, 2018-05-28 at 12:39 +0800, Ian Kent wrote:
> On Mon, 2018-05-28 at 12:13 +0800, Ian Kent wrote:
> > On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote:
> > > On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot <[email protected]>
> > > wrote:
> > >
> > > > Hi Andrey,
> > > >
> > > > I love your patch! Yet something to improve:
> > > >
> > > > [auto build test ERROR on mmotm/master]
> > > > [cannot apply to v4.17-rc6]
> > > > [if your patch is applied to the wrong git tree, please drop us a note
> > > > to
> > > > help improve the system]
> > > >
> > > > url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasa
> > > > n-
> > > > do
> > > > nt-vfree-nonexistent-vm_area-fix/20180526-093255
> > > > base: git://git.cmpxchg.org/linux-mmotm.git master
> > > > config: sparc-allyesconfig (attached as .config)
> > > > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> > > > reproduce:
> > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sb
> > > > in
> > > > /m
> > > > ake.cross -O ~/bin/make.cross
> > > > chmod +x ~/bin/make.cross
> > > > # save the attached .config to linux build tree
> > > > make.cross ARCH=sparc
> > > >
> > > > All errors (new ones prefixed by >>):
> > > >
> > > > fs/autofs/inode.o: In function `autofs_new_ino':
> > > > inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
> > > > fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
> > > > fs/autofs/inode.o: In function `autofs_clean_ino':
> > > > inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
> > > > fs/autofs/inode.o:inode.c:(.text+0x280): first defined here
> > >
> > > There's bot breakage here - clearly that patch didn't cause this error.
> > >
> > > Ian, this autofs glitch may still not be fixed.
> >
> > Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have
> > fixed that.
> >
> > I tied a bunch of .config combinations and I was unable to find any that
> > lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined.
>
> Oh, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch was sent as
> a follow up patch which means it's still possible to have both
> CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS set between
> autofs-create-autofs-Kconfig-and-Makefile.patch and the above patch.
>
> Perhaps all that's needed is to fold the follow up patch into
> autofs-create-autofs-Kconfig-and-Makefile.patch to close that
> possibility.
>
> I'll check that can be done without problem.
I've had a look and I can't see any reason for this other than
CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS both being set which isn't
ok because the file system name is the same for both.
I have seen build system configs that have both of these set even
though the "autofs" module was removed years ago so that's probably
still present in some site build systems.
I see you've added the follow up patch I mentioned above as
"autofs-update-fs-autofs4-kconfig-fix.patch"
with title
"autofs - make autofs4 Kconfig depend on AUTOFS_FS"
Folding this patch into the patch
"autofs-create-autofs-kconfig-and-makefile.patch"
with title
"autofs: create autofs Kconfig and Makefile"
I'm unable to reproduce the breakage which leads me to think
the problem must be due to .config having both the CONFIG_AUTOFS*
entries defined to something other than n (which certainly does
produce the breakage if the follow up patch is not present, so
the result is not bisectable until the follow up patch is added).
Also, I don't think there is a need to update the description of
"autofs: create autofs Kconfig and Makefile"
because the patch that is folded into it adds a NOTE to the
fs/autofs4/Kconfig help that essentially re-states what is in
the description.
If this continues to happen I'll need more information about
applied patches and kernel config used to work out what's going
on.
For completeness here's the resulting patch after folding in the
follow up patch above:
autofs - create autofs Kconfig and Makefile
From: Ian Kent <[email protected]>
Create Makefile and Kconfig for autofs module.
Signed-off-by: Ian Kent <[email protected]>
---
fs/Kconfig | 1 +
fs/Makefile | 1 +
fs/autofs/Kconfig | 20 ++++++++++++++++++++
fs/autofs/Makefile | 7 +++++++
fs/autofs4/Kconfig | 8 ++++++++
5 files changed, 37 insertions(+)
create mode 100644 fs/autofs/Kconfig
create mode 100644 fs/autofs/Makefile
diff --git a/fs/Kconfig b/fs/Kconfig
index bc821a86d965..e712e62afe59 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -108,6 +108,7 @@ source "fs/notify/Kconfig"
source "fs/quota/Kconfig"
+source "fs/autofs/Kconfig"
source "fs/autofs4/Kconfig"
source "fs/fuse/Kconfig"
source "fs/overlayfs/Kconfig"
diff --git a/fs/Makefile b/fs/Makefile
index c9375fd2c8c4..2e005525cc19 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_AFFS_FS) += affs/
obj-$(CONFIG_ROMFS_FS) += romfs/
obj-$(CONFIG_QNX4FS_FS) += qnx4/
obj-$(CONFIG_QNX6FS_FS) += qnx6/
+obj-$(CONFIG_AUTOFS_FS) += autofs/
obj-$(CONFIG_AUTOFS4_FS) += autofs4/
obj-$(CONFIG_ADFS_FS) += adfs/
obj-$(CONFIG_FUSE_FS) += fuse/
diff --git a/fs/autofs/Kconfig b/fs/autofs/Kconfig
new file mode 100644
index 000000000000..6a2064eb3b27
--- /dev/null
+++ b/fs/autofs/Kconfig
@@ -0,0 +1,20 @@
+config AUTOFS_FS
+ tristate "Kernel automounter support (supports v3, v4 and v5)"
+ default n
+ help
+ The automounter is a tool to automatically mount remote file systems
+ on demand. This implementation is partially kernel-based to reduce
+ overhead in the already-mounted case; this is unlike the BSD
+ automounter (amd), which is a pure user space daemon.
+
+ To use the automounter you need the user-space tools from
+ <https://www.kernel.org/pub/linux/daemons/autofs/>; you also want
+ to answer Y to "NFS file system support", below.
+
+ To compile this support as a module, choose M here: the module will be
+ called autofs.
+
+ If you are not a part of a fairly large, distributed network or
+ don't have a laptop which needs to dynamically reconfigure to the
+ local network, you probably do not need an automounter, and can say
+ N here.
diff --git a/fs/autofs/Makefile b/fs/autofs/Makefile
new file mode 100644
index 000000000000..43fedde15c26
--- /dev/null
+++ b/fs/autofs/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the linux autofs-filesystem routines.
+#
+
+obj-$(CONFIG_AUTOFS_FS) += autofs.o
+
+autofs-objs := init.o inode.o root.o symlink.o waitq.o expire.o dev-ioctl.o
diff --git a/fs/autofs4/Kconfig b/fs/autofs4/Kconfig
index 53bc592a250d..2c2fdf989f90 100644
--- a/fs/autofs4/Kconfig
+++ b/fs/autofs4/Kconfig
@@ -1,6 +1,7 @@
config AUTOFS4_FS
tristate "Kernel automounter version 4 support (also supports v3 and v5)"
default n
+ depends on AUTOFS_FS = n
help
The automounter is a tool to automatically mount remote file systems
on demand. This implementation is partially kernel-based to reduce
@@ -30,3 +31,10 @@ config AUTOFS4_FS
- any "alias autofs autofs4" will need to be removed.
Please configure AUTOFS_FS instead of AUTOFS4_FS from now on.
+
+ NOTE: Since the modules autofs and autofs4 use the same file system
+ type name of "autofs" only one can be built. The "depends"
+ above will result in AUTOFS4_FS not appearing in .config for
+ any setting of AUTOFS_FS other than n and AUTOFS4_FS will
+ appear under the AUTOFS_FS entry otherwise which is intended
+ to draw attention to the module rename change.
Hi Andrey,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
[cannot apply to v4.17-rc7 next-20180529]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-dont-vfree-nonexistent-vm_area-fix/20180526-093255
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
fs/autofs/inode.o: In function `autofs_new_ino':
>> inode.c:(.text+0x170): multiple definition of `autofs_new_ino'
fs/autofs/inode.o:inode.c:(.text+0x170): first defined here
fs/autofs/inode.o: In function `autofs_clean_ino':
>> inode.c:(.text+0x1c0): multiple definition of `autofs_clean_ino'
fs/autofs/inode.o:inode.c:(.text+0x1c0): first defined here
fs/autofs/inode.o: In function `autofs_free_ino':
>> inode.c:(.text+0x1f0): multiple definition of `autofs_free_ino'
fs/autofs/inode.o:inode.c:(.text+0x1f0): first defined here
fs/autofs/inode.o: In function `autofs_kill_sb':
>> inode.c:(.text+0x200): multiple definition of `autofs_kill_sb'
fs/autofs/inode.o:inode.c:(.text+0x200): first defined here
fs/autofs/inode.o: In function `autofs_get_inode':
>> inode.c:(.text+0x250): multiple definition of `autofs_get_inode'
fs/autofs/inode.o:inode.c:(.text+0x250): first defined here
fs/autofs/inode.o: In function `autofs_fill_super':
>> inode.c:(.text+0x300): multiple definition of `autofs_fill_super'
fs/autofs/inode.o:inode.c:(.text+0x300): first defined here
fs/autofs/root.o: In function `is_autofs_dentry':
>> root.c:(.text+0x1170): multiple definition of `is_autofs_dentry'
fs/autofs/root.o:root.c:(.text+0x1170): first defined here
>> fs/autofs/root.o:(.rodata+0x0): multiple definition of `autofs_dentry_operations'
fs/autofs/root.o:(.rodata+0x0): first defined here
>> fs/autofs/root.o:(.rodata+0x40): multiple definition of `autofs_dir_inode_operations'
fs/autofs/root.o:(.rodata+0x40): first defined here
>> fs/autofs/root.o:(.rodata+0xc0): multiple definition of `autofs_dir_operations'
fs/autofs/root.o:(.rodata+0xc0): first defined here
>> fs/autofs/root.o:(.rodata+0x140): multiple definition of `autofs_root_operations'
fs/autofs/root.o:(.rodata+0x140): first defined here
>> fs/autofs/symlink.o:(.rodata+0x0): multiple definition of `autofs_symlink_inode_operations'
fs/autofs/symlink.o:(.rodata+0x0): first defined here
fs/autofs/waitq.o: In function `autofs_catatonic_mode':
>> waitq.c:(.text+0x60): multiple definition of `autofs_catatonic_mode'
fs/autofs/waitq.o:waitq.c:(.text+0x60): first defined here
fs/autofs/waitq.o: In function `autofs_wait_release':
>> waitq.c:(.text+0x110): multiple definition of `autofs_wait_release'
fs/autofs/waitq.o:waitq.c:(.text+0x110): first defined here
fs/autofs/waitq.o: In function `autofs_wait':
>> waitq.c:(.text+0x520): multiple definition of `autofs_wait'
fs/autofs/waitq.o:waitq.c:(.text+0x520): first defined here
fs/autofs/expire.o: In function `autofs_expire_direct':
expire.c:(.text+0x4d0): multiple definition of `autofs_expire_direct'
fs/autofs/expire.o:expire.c:(.text+0x4d0): first defined here
fs/autofs/expire.o: In function `autofs_expire_indirect':
expire.c:(.text+0x5c0): multiple definition of `autofs_expire_indirect'
fs/autofs/expire.o:expire.c:(.text+0x5c0): first defined here
fs/autofs/expire.o: In function `autofs_expire_wait':
expire.c:(.text+0x840): multiple definition of `autofs_expire_wait'
fs/autofs/expire.o:expire.c:(.text+0x840): first defined here
fs/autofs/expire.o: In function `autofs_expire_run':
expire.c:(.text+0x910): multiple definition of `autofs_expire_run'
fs/autofs/expire.o:expire.c:(.text+0x910): first defined here
fs/autofs/expire.o: In function `autofs_do_expire_multi':
expire.c:(.text+0xa30): multiple definition of `autofs_do_expire_multi'
fs/autofs/expire.o:expire.c:(.text+0xa30): first defined here
fs/autofs/expire.o: In function `autofs_expire_multi':
expire.c:(.text+0xb00): multiple definition of `autofs_expire_multi'
fs/autofs/expire.o:expire.c:(.text+0xb00): first defined here
fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_init':
dev-ioctl.c:(.init.text+0x0): multiple definition of `autofs_dev_ioctl_init'
fs/autofs/dev-ioctl.o:dev-ioctl.c:(.init.text+0x0): first defined here
fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_exit':
dev-ioctl.c:(.text+0xac0): multiple definition of `autofs_dev_ioctl_exit'
fs/autofs/dev-ioctl.o:dev-ioctl.c:(.text+0xac0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation