* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-07-04 21:50 Bert Karwatzki
0 siblings, 0 replies; 13+ messages in thread
From: Bert Karwatzki @ 2024-07-04 21:50 UTC (permalink / raw)
To: Liam R . Howlett; +Cc: Bert Karwatzki, Andrew Morton, linux-mm
I just did test the v3 patchset on top of linux-next-20240703 with
`stress-ng --vm-segv 16`. In about 5 minutes of testing no errors occured.
This seems to be a good sign especially since testing the v2 patchset yielded
more than a million errors in 30 seconds.
Bert Karwatzki
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-07-04 21:15 Bert Karwatzki
0 siblings, 0 replies; 13+ messages in thread
From: Bert Karwatzki @ 2024-07-04 21:15 UTC (permalink / raw)
To: Liam R . Howlett; +Cc: Bert Karwatzki, Andrew Morton, linux-mm
Also, this time the kernel was compiled with CONFIG_DEBUG_VM_MAPLE_TREE=y,
but /var/log/kern.log contained no related warnings.
Bert Karwatzki
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-07-04 21:07 Bert Karwatzki
0 siblings, 0 replies; 13+ messages in thread
From: Bert Karwatzki @ 2024-07-04 21:07 UTC (permalink / raw)
To: Liam R . Howlett; +Cc: Bert Karwatzki, Andrew Morton, linux-mm
I tested the v2 patch on top of linux-next-20240703 with stress-ng --vm-segv 16 and
got more than a million "Bad rss-counter state" errors plus an invalid opcode error!
I'm rebooting now to test v3.
Bert Karwatzki
[ T1359] BUG: Bad rss-counter state mm:00000000e5421690 type:MM_ANONPAGES val:370
[...] Here are more than 10^6 (~2^20) lines of "Bad rss-counter-state"
[ T1359] BUG: Bad rss-counter state mm:00000000e5421690 type:MM_SHMEMPAGES val:27
[T24203] page: refcount:542376 mapcount:542374 mapping:00000000ba179a51 index:0x0 pfn:0x29594e
[T24203] memcg:ffff9bc0424b6800
[T24203] aops:shmem_aops ino:a678
[T24203] flags: 0x400000000004012d(locked|referenced|uptodate|lru|active|swapbacked|zone=2)
[T24203] raw: 400000000004012d ffffd864c574a908 ffffd864c776fa48 ffff9bc1a0681040
[T24203] raw: 0000000000000000 0000000000000000 000846a8000846a5 ffff9bc0424b6800
[T24203] page dumped because: VM_BUG_ON_FOLIO(folio_mapped(folio))
[T24203] ------------[ cut here ]------------
[T24203] kernel BUG at mm/filemap.c:162!
[T24203] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[T24203] CPU: 1 UID: 0 PID: 24203 Comm: stress-ng Not tainted 6.10.0-rc6-next-20240703-00016-g09a756327684 #1417
[T24203] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.107 11/10/2021
[T24203] RIP: 0010:filemap_unaccount_folio+0xcf/0x170
[T24203] Code: 00 00 48 8b 06 a8 40 0f 84 a3 00 00 00 8b 43 50 83 c0 01 85 c0 0f 8e 66 ff ff ff 48 c7 c6 48 e4 aa bc 48 89 df e8 31 32 03 00 <0f> 0b 5b 5d 41 5c e9 71 7f 92 00 44 89 e2 be 17 00 00 00 48 89 df
[T24203] RSP: 0018:ffffb1a4e01aba88 EFLAGS: 00010046
[T24203] RAX: 0000000000000039 RBX: ffffd864ca565380 RCX: 0000000000000027
[T24203] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9bceee657780
[T24203] RBP: ffff9bc1a0681040 R08: 0000000000000000 R09: 0000000000000003
[T24203] R10: ffffb1a4e01ab940 R11: ffffffffbcc82940 R12: ffff9bc1a0681040
[T24203] R13: 0000000000000000 R14: ffff9bc1a0681048 R15: ffffd864ca565380
[T24203] FS: 00007f944cb0df40(0000) GS:ffff9bceee640000(0000) knlGS:0000000000000000
[T24203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[T24203] CR2: 00007ffe0ec9f948 CR3: 0000000150be4000 CR4: 0000000000750ef0
[T24203] PKRU: 55555554
[T24203] Call Trace:
[T24203] <TASK>
[T24203] ? die+0x31/0x80
[T24203] ? do_trap+0xf1/0x100
[T24203] ? filemap_unaccount_folio+0xcf/0x170
[T24203] ? do_error_trap+0x60/0x80
[T24203] ? filemap_unaccount_folio+0xcf/0x170
[T24203] ? exc_invalid_op+0x4d/0x70
[T24203] ? filemap_unaccount_folio+0xcf/0x170
[T24203] ? asm_exc_invalid_op+0x1a/0x20
[T24203] ? filemap_unaccount_folio+0xcf/0x170
[T24203] ? filemap_unaccount_folio+0xcf/0x170
[T24203] ? __filemap_remove_folio+0x33/0x1a0
[T24203] ? xas_find+0x159/0x1c0
[T24203] ? srso_alias_return_thunk+0x5/0xfbef5
[T24203] ? find_lock_entries+0x229/0x330
[T24203] ? srso_alias_return_thunk+0x5/0xfbef5
[T24203] ? unmap_mapping_folio+0x75/0x130
[T24203] ? filemap_remove_folio+0x3c/0xa0
[T24203] ? truncate_inode_folio+0x1e/0x30
[T24203] ? shmem_undo_range+0x15c/0x6f0
[T24203] ? bio_integrity_unpin_bvec+0xf/0x60
[T24203] ? shmem_evict_inode+0x109/0x260
[T24203] ? swake_up_locked+0x50/0x50
[T24203] ? evict+0xbf/0x1c0
[T24203] ? __dentry_kill+0x6c/0x170
[T24203] ? dput+0xe6/0x1b0
[T24203] ? __fput+0x13c/0x2c0
[T24203] ? task_work_run+0x57/0x80
[T24203] ? syscall_exit_to_user_mode+0x196/0x1a0
[T24203] ? do_syscall_64+0x6b/0x170
[T24203] ? entry_SYSCALL_64_after_hwframe+0x55/0x5d
[T24203] </TASK>
[T24203] Modules linked in: ccm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device rfcomm cmac bnep nls_ascii nls_cp437 vfat fat snd_ctl_led snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_scodec_component btusb btrtl btintel snd_hda_intel btbcm snd_intel_dspcfg btmtk snd_hda_codec snd_soc_dmic snd_acp3x_rn uvcvideo snd_acp3x_pdm_dma bluetooth amd_atl snd_hwdep snd_soc_core videobuf2_vmalloc snd_hda_core uvc videobuf2_memops videobuf2_v4l2 snd_pcm_oss videodev snd_mixer_oss snd_pcm snd_rn_pci_acp3x snd_acp_config videobuf2_common snd_timer msi_wmi snd_soc_acpi ecdh_generic ecc mc sparse_keymap snd edac_mce_amd wmi_bmof ccp soundcore snd_pci_acp3x k10temp ac battery button hid_sensor_gyro_3d hid_sensor_als hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_prox joydev hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio amd_pmc hid_sensor_iio_common evdev hid_multitouch serio_raw mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76
[T24203] mac80211 libarc4 cfg80211 rfkill msr fuse nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 crc32c_generic mbcache jbd2 usbhid amdgpu i2c_algo_bit drm_ttm_helper ttm xhci_pci drm_exec drm_suballoc_helper xhci_hcd amdxcp drm_buddy hid_sensor_hub usbcore gpu_sched nvme mfd_core hid_generic crc32c_intel psmouse amd_sfh i2c_piix4 drm_display_helper usb_common nvme_core r8169 crc16 i2c_hid_acpi i2c_hid hid i2c_designware_platform i2c_designware_core
[T24203] ---[ end trace 0000000000000000 ]---
[T24203] RIP: 0010:filemap_unaccount_folio+0xcf/0x170
[T24203] Code: 00 00 48 8b 06 a8 40 0f 84 a3 00 00 00 8b 43 50 83 c0 01 85 c0 0f 8e 66 ff ff ff 48 c7 c6 48 e4 aa bc 48 89 df e8 31 32 03 00 <0f> 0b 5b 5d 41 5c e9 71 7f 92 00 44 89 e2 be 17 00 00 00 48 89 df
[T24203] RSP: 0018:ffffb1a4e01aba88 EFLAGS: 00010046
[T24203] RAX: 0000000000000039 RBX: ffffd864ca565380 RCX: 0000000000000027
[T24203] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9bceee657780
[T24203] RBP: ffff9bc1a0681040 R08: 0000000000000000 R09: 0000000000000003
[T24203] R10: ffffb1a4e01ab940 R11: ffffffffbcc82940 R12: ffff9bc1a0681040
[T24203] R13: 0000000000000000 R14: ffff9bc1a0681048 R15: ffffd864ca565380
[T24203] FS: 00007f944cb0df40(0000) GS:ffff9bceee640000(0000) knlGS:0000000000000000
[T24203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[T24203] CR2: 00007ffe0ec9f948 CR3: 0000000150be4000 CR4: 0000000000750ef0
[T24203] PKRU: 55555554
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
2024-07-03 14:30 Bert Karwatzki
@ 2024-07-04 18:31 ` Liam R. Howlett
0 siblings, 0 replies; 13+ messages in thread
From: Liam R. Howlett @ 2024-07-04 18:31 UTC (permalink / raw)
To: Bert Karwatzki; +Cc: Andrew Morton, linux-mm
* Bert Karwatzki <spasswolf@web.de> [240703 10:30]:
>
> > Thanks. Is this the first error printed in the kern.log?
>
> Yes. Uptime was about an hour when it occurred.
>
> > It could very likely be me, but I don't know how the count would have
> > errors so late in the process life cycle - do you have
> > CONFIG_DEBUG_VM_MAPLE_TREE enabled? This would check the count against
> > the tree on modifications and would narrow down where things could have
> > gone wrong.
>
> Unfortunately, the panicking kernel was compiled without CONFIG_DEBUG_VM_MAPLE_TREE.
> After the error I recompiled it with that option enabled. This kernel is running for
> about 3 hours without the error reappearing.
>
I sent v3 after producing an error with stress-ng --vm-sigv, which
unmaps the entire process space. That might be at play with what you
saw, but I'm still unsure if your issue is fixed by this change. I was
unable to reproduce the issue you saw against the mm-unstable and
mm-stable branch, but that might just mean it's rare.
Thanks,
Liam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-07-03 14:30 Bert Karwatzki
2024-07-04 18:31 ` Liam R. Howlett
0 siblings, 1 reply; 13+ messages in thread
From: Bert Karwatzki @ 2024-07-03 14:30 UTC (permalink / raw)
To: Liam R . Howlett; +Cc: Bert Karwatzki, Andrew Morton, linux-mm
> Thanks. Is this the first error printed in the kern.log?
Yes. Uptime was about an hour when it occurred.
> It could very likely be me, but I don't know how the count would have
> errors so late in the process life cycle - do you have
> CONFIG_DEBUG_VM_MAPLE_TREE enabled? This would check the count against
> the tree on modifications and would narrow down where things could have
> gone wrong.
Unfortunately, the panicking kernel was compiled without CONFIG_DEBUG_VM_MAPLE_TREE.
After the error I recompiled it with that option enabled. This kernel is running for
about 3 hours without the error reappearing.
Bert Karwatzki
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
2024-07-03 10:13 Bert Karwatzki
@ 2024-07-03 13:53 ` Liam R. Howlett
0 siblings, 0 replies; 13+ messages in thread
From: Liam R. Howlett @ 2024-07-03 13:53 UTC (permalink / raw)
To: Bert Karwatzki; +Cc: Andrew Morton, linux-mm
* Bert Karwatzki <spasswolf@web.de> [240703 06:14]:
> If been running the fixed patchset on top of linux-next for a few days now, so far
> without error but then I ran into this. After this the system went into a kernel panic
> (freeze, flashing capslock) this is the last message preserverd in /var/log/kern.log. I
> tried to emergency sync using magic sysrq, but that did not work so the actual panic message
> is lost. I do not know how (or if) this is related to the patch set.
Thanks. Is this the first error printed in the kern.log?
> The kernel used is linux-next-20240703 plus your v2 patchset plus one additional unrelated patch
> (just #ifdef CONFIG_OF in drivers/pci/bus.c related to
> https://lore.kernel.org/all/20240612082019.19161-4-brgl@bgdev.pl/#t).
It could very likely be me, but I don't know how the count would have
errors so late in the process life cycle - do you have
CONFIG_DEBUG_VM_MAPLE_TREE enabled? This would check the count against
the tree on modifications and would narrow down where things could have
gone wrong.
>
>
> [ T8516] show_signal_msg: 16 callbacks suppressed
> [ T8516] Isolated Web Co[8516]: segfault at 0 ip 00007f8c1f55fbe5 sp 00007ffcc2b97660 error 6 in libxul.so[4f98be5,7f8c1a686000+5f96000] likely on CPU 14 (core 7, socket 0)
This is firefox again.
> [ T8516] Code: 48 8d 0d 63 a3 3c 01 48 89 08 c7 04 25 00 00 00 00 00 00 00 00 0f 0b 48 8b 05 47 1a e2 03 48 8d 0d 38 99 30 01 48 89 08 31 c0 <89> 04 25 00 00 00 00 0f 0b e8 7d 7a 12 fb 66 2e 0f 1f 84 00 00 00
> [ T8521] ------------[ cut here ]------------
> [ T8521] kernel BUG at mm/mmap.c:3521!
This is failing because the munmap count != mm->map_count on
exit_mmap().
> [ T8521] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> [ T8521] CPU: 6 UID: 1000 PID: 8521 Comm: Socket Thread Not tainted 6.10.0-rc6-next-20240703-00016-g09a756327684 #1416
> [ T8521] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.107 11/10/2021
> [ T8521] RIP: 0010:exit_mmap+0x28c/0x2a0
> [ T8521] Code: f7 45 31 ed e8 f5 7e e9 ff 4c 89 f7 e8 3d f4 6c 00 e9 63 ff ff ff 48 89 ef e8 70 11 04 00 e9 d1 fd ff ff 0f 0b e9 66 ff ff ff <0f> 0b e8 8d 0a 6c 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 66 0f
> [ T8521] RSP: 0018:ffffac759002fca0 EFLAGS: 00010297
> [ T8521] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> [ T8521] RDX: 0000000000000001 RSI: ffff8bb7caca9700 RDI: ffff8bb7caca9708
> [ T8521] RBP: ffff8bb7c237e900 R08: 0000000000000000 R09: 000000000000000f
> [ T8521] R10: 00007ffcc2b9bfff R11: 0000000000000078 R12: 00000000000006b5
> [ T8521] R13: fffffffffffeb575 R14: ffff8bb7c237e9a8 R15: ffff8bb7c237e940
> [ T8521] FS: 0000000000000000(0000) GS:ffff8bc6adf80000(0000) knlGS:0000000000000000
> [ T8521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ T8521] CR2: 00007f2b6cae2000 CR3: 0000000fd1c18000 CR4: 0000000000750ef0
> [ T8521] PKRU: 55555554
> [ T8521] Call Trace:
> [ T8521] <TASK>
> [ T8521] ? die+0x31/0x80
> [ T8521] ? do_trap+0xf1/0x100
> [ T8521] ? exit_mmap+0x28c/0x2a0
> [ T8521] ? do_error_trap+0x60/0x80
> [ T8521] ? exit_mmap+0x28c/0x2a0
> [ T8521] ? exc_invalid_op+0x4d/0x70
> [ T8521] ? exit_mmap+0x28c/0x2a0
> [ T8521] ? asm_exc_invalid_op+0x1a/0x20
> [ T8521] ? exit_mmap+0x28c/0x2a0
> [ T8521] ? mmput+0x50/0x120
> [ T8521] ? do_exit+0x285/0x9c0
> [ T8521] ? do_group_exit+0x2b/0x80
> [ T8521] ? get_signal+0x731/0x7e0
> [ T8521] ? arch_do_signal_or_restart+0x29/0x230
> [ T8521] ? srso_alias_return_thunk+0x5/0xfbef5
> [ T8521] ? srso_alias_return_thunk+0x5/0xfbef5
> [ T8521] ? __x64_sys_futex+0x109/0x1c0
> [ T8521] ? syscall_exit_to_user_mode+0x154/0x1a0
> [ T8521] ? do_syscall_64+0x6b/0x170
> [ T8521] ? entry_SYSCALL_64_after_hwframe+0x55/0x5d
> [ T8521] </TASK>
> [ T8521] Modules linked in: ccm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device rfcomm cmac bnep nls_ascii nls_cp437 vfat fat snd_ctl_led btusb snd_hda_codec_realtek btrtl btintel snd_hda_codec_generic btbcm btmtk snd_hda_scodec_component snd_hda_codec_hdmi bluetooth snd_hda_intel snd_intel_dspcfg uvcvideo snd_hda_codec videobuf2_vmalloc snd_acp3x_pdm_dma snd_soc_dmic snd_hwdep snd_acp3x_rn uvc amd_atl videobuf2_memops snd_soc_core snd_hda_core videobuf2_v4l2 snd_pcm_oss videodev snd_mixer_oss snd_pcm snd_rn_pci_acp3x videobuf2_common snd_acp_config snd_timer snd_soc_acpi msi_wmi ecdh_generic ecc sparse_keymap mc edac_mce_amd wmi_bmof snd ccp k10temp joydev soundcore snd_pci_acp3x battery ac button hid_sensor_gyro_3d hid_sensor_prox hid_sensor_als hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio amd_pmc hid_sensor_iio_common evdev hid_multitouch serio_raw mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76
> [ T8521] mac80211 libarc4 cfg80211 rfkill msr fuse nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 crc32c_generic mbcache jbd2 usbhid amdgpu i2c_algo_bit drm_ttm_helper xhci_pci ttm drm_exec drm_suballoc_helper xhci_hcd amdxcp drm_buddy hid_sensor_hub usbcore nvme gpu_sched mfd_core hid_generic crc32c_intel psmouse i2c_piix4 amd_sfh drm_display_helper usb_common nvme_core crc16 r8169 i2c_hid_acpi i2c_hid hid i2c_designware_platform i2c_designware_core
> [ T8521] ---[ end trace 0000000000000000 ]---
> [ T8521] RIP: 0010:exit_mmap+0x28c/0x2a0
> [ T8521] Code: f7 45 31 ed e8 f5 7e e9 ff 4c 89 f7 e8 3d f4 6c 00 e9 63 ff ff ff 48 89 ef e8 70 11 04 00 e9 d1 fd ff ff 0f 0b e9 66 ff ff ff <0f> 0b e8 8d 0a 6c 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 66 0f
> [ T8521] RSP: 0018:ffffac759002fca0 EFLAGS: 00010297
> [ T8521] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> [ T8521] RDX: 0000000000000001 RSI: ffff8bb7caca9700 RDI: ffff8bb7caca9708
> [ T8521] RBP: ffff8bb7c237e900 R08: 0000000000000000 R09: 000000000000000f
> [ T8521] R10: 00007ffcc2b9bfff R11: 0000000000000078 R12: 00000000000006b5
> [ T8521] R13: fffffffffffeb575 R14: ffff8bb7c237e9a8 R15: ffff8bb7c237e940
> [ T8521] FS: 0000000000000000(0000) GS:ffff8bc6adfc0000(0000) knlGS:0000000000000000
> [ T8521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ T8521] CR2: 00007f460adce000 CR3: 0000000fd1c18000 CR4: 0000000000750ef0
> [ T8521] PKRU: 55555554
> [ T8521] Fixing recursive fault but reboot is needed!
> [ T8521] BUG: scheduling while atomic: Socket Thread/8521/0x00000000
> [ T8521] Modules linked in: ccm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device rfcomm cmac bnep nls_ascii nls_cp437 vfat fat snd_ctl_led btusb snd_hda_codec_realtek btrtl btintel snd_hda_codec_generic btbcm btmtk snd_hda_scodec_component snd_hda_codec_hdmi bluetooth snd_hda_intel snd_intel_dspcfg uvcvideo snd_hda_codec videobuf2_vmalloc snd_acp3x_pdm_dma snd_soc_dmic snd_hwdep snd_acp3x_rn uvc amd_atl videobuf2_memops snd_soc_core snd_hda_core videobuf2_v4l2 snd_pcm_oss videodev snd_mixer_oss snd_pcm snd_rn_pci_acp3x videobuf2_common snd_acp_config snd_timer snd_soc_acpi msi_wmi ecdh_generic ecc sparse_keymap mc edac_mce_amd wmi_bmof snd ccp k10temp joydev soundcore snd_pci_acp3x battery ac button hid_sensor_gyro_3d hid_sensor_prox hid_sensor_als hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio amd_pmc hid_sensor_iio_common evdev hid_multitouch serio_raw mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76
> [ T8521] mac80211 libarc4 cfg80211 rfkill msr fuse nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 crc32c_generic mbcache jbd2 usbhid amdgpu i2c_algo_bit drm_ttm_helper xhci_pci ttm drm_exec drm_suballoc_helper xhci_hcd amdxcp drm_buddy hid_sensor_hub usbcore nvme gpu_sched mfd_core hid_generic crc32c_intel psmouse i2c_piix4 amd_sfh drm_display_helper usb_common nvme_core crc16 r8169 i2c_hid_acpi i2c_hid hid i2c_designware_platform i2c_designware_core
> [ T8521] CPU: 7 UID: 1000 PID: 8521 Comm: Socket Thread Tainted: G D 6.10.0-rc6-next-20240703-00016-g09a756327684 #1416
> [ T8521] Tainted: [D]=DIE
> [ T8521] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.107 11/10/2021
> [ T8521] Call Trace:
> [ T8521] <TASK>
> [ T8521] ? dump_stack_lvl+0x53/0x70
> [ T8521] ? __schedule_bug+0x4d/0x60
> [ T8521] ? __schedule+0x734/0x800
> [ T8521] ? srso_alias_return_thunk+0x5/0xfbef5
> [ T8521] ? _printk+0x57/0x80
> [ T8521] ? do_task_dead+0x3d/0x40
> [ T8521] ? make_task_dead+0x13b/0x160
> [ T8521] ? rewind_stack_and_make_dead+0x16/0x20
> [ T8521] </TASK>
It looks like it might have been in the process of killing the thread
group (terminating firefox ?) for another reason?
Considering that I modify the count under the mmap_lock in write mode
and that the map_count is verified in validate_mm(), I am eager to find
out if you are running with CONFIG_DEBUG_VM_MAPLE_TREE enabled.
Thanks,
Liam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-07-03 10:13 Bert Karwatzki
2024-07-03 13:53 ` Liam R. Howlett
0 siblings, 1 reply; 13+ messages in thread
From: Bert Karwatzki @ 2024-07-03 10:13 UTC (permalink / raw)
To: Liam R . Howlett; +Cc: Bert Karwatzki, Andrew Morton, linux-mm
If been running the fixed patchset on top of linux-next for a few days now, so far
without error but then I ran into this. After this the system went into a kernel panic
(freeze, flashing capslock) this is the last message preserverd in /var/log/kern.log. I
tried to emergency sync using magic sysrq, but that did not work so the actual panic message
is lost. I do not know how (or if) this is related to the patch set.
The kernel used is linux-next-20240703 plus your v2 patchset plus one additional unrelated patch
(just #ifdef CONFIG_OF in drivers/pci/bus.c related to
https://lore.kernel.org/all/20240612082019.19161-4-brgl@bgdev.pl/#t).
[ T8516] show_signal_msg: 16 callbacks suppressed
[ T8516] Isolated Web Co[8516]: segfault at 0 ip 00007f8c1f55fbe5 sp 00007ffcc2b97660 error 6 in libxul.so[4f98be5,7f8c1a686000+5f96000] likely on CPU 14 (core 7, socket 0)
[ T8516] Code: 48 8d 0d 63 a3 3c 01 48 89 08 c7 04 25 00 00 00 00 00 00 00 00 0f 0b 48 8b 05 47 1a e2 03 48 8d 0d 38 99 30 01 48 89 08 31 c0 <89> 04 25 00 00 00 00 0f 0b e8 7d 7a 12 fb 66 2e 0f 1f 84 00 00 00
[ T8521] ------------[ cut here ]------------
[ T8521] kernel BUG at mm/mmap.c:3521!
[ T8521] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ T8521] CPU: 6 UID: 1000 PID: 8521 Comm: Socket Thread Not tainted 6.10.0-rc6-next-20240703-00016-g09a756327684 #1416
[ T8521] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.107 11/10/2021
[ T8521] RIP: 0010:exit_mmap+0x28c/0x2a0
[ T8521] Code: f7 45 31 ed e8 f5 7e e9 ff 4c 89 f7 e8 3d f4 6c 00 e9 63 ff ff ff 48 89 ef e8 70 11 04 00 e9 d1 fd ff ff 0f 0b e9 66 ff ff ff <0f> 0b e8 8d 0a 6c 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 66 0f
[ T8521] RSP: 0018:ffffac759002fca0 EFLAGS: 00010297
[ T8521] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ T8521] RDX: 0000000000000001 RSI: ffff8bb7caca9700 RDI: ffff8bb7caca9708
[ T8521] RBP: ffff8bb7c237e900 R08: 0000000000000000 R09: 000000000000000f
[ T8521] R10: 00007ffcc2b9bfff R11: 0000000000000078 R12: 00000000000006b5
[ T8521] R13: fffffffffffeb575 R14: ffff8bb7c237e9a8 R15: ffff8bb7c237e940
[ T8521] FS: 0000000000000000(0000) GS:ffff8bc6adf80000(0000) knlGS:0000000000000000
[ T8521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ T8521] CR2: 00007f2b6cae2000 CR3: 0000000fd1c18000 CR4: 0000000000750ef0
[ T8521] PKRU: 55555554
[ T8521] Call Trace:
[ T8521] <TASK>
[ T8521] ? die+0x31/0x80
[ T8521] ? do_trap+0xf1/0x100
[ T8521] ? exit_mmap+0x28c/0x2a0
[ T8521] ? do_error_trap+0x60/0x80
[ T8521] ? exit_mmap+0x28c/0x2a0
[ T8521] ? exc_invalid_op+0x4d/0x70
[ T8521] ? exit_mmap+0x28c/0x2a0
[ T8521] ? asm_exc_invalid_op+0x1a/0x20
[ T8521] ? exit_mmap+0x28c/0x2a0
[ T8521] ? mmput+0x50/0x120
[ T8521] ? do_exit+0x285/0x9c0
[ T8521] ? do_group_exit+0x2b/0x80
[ T8521] ? get_signal+0x731/0x7e0
[ T8521] ? arch_do_signal_or_restart+0x29/0x230
[ T8521] ? srso_alias_return_thunk+0x5/0xfbef5
[ T8521] ? srso_alias_return_thunk+0x5/0xfbef5
[ T8521] ? __x64_sys_futex+0x109/0x1c0
[ T8521] ? syscall_exit_to_user_mode+0x154/0x1a0
[ T8521] ? do_syscall_64+0x6b/0x170
[ T8521] ? entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ T8521] </TASK>
[ T8521] Modules linked in: ccm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device rfcomm cmac bnep nls_ascii nls_cp437 vfat fat snd_ctl_led btusb snd_hda_codec_realtek btrtl btintel snd_hda_codec_generic btbcm btmtk snd_hda_scodec_component snd_hda_codec_hdmi bluetooth snd_hda_intel snd_intel_dspcfg uvcvideo snd_hda_codec videobuf2_vmalloc snd_acp3x_pdm_dma snd_soc_dmic snd_hwdep snd_acp3x_rn uvc amd_atl videobuf2_memops snd_soc_core snd_hda_core videobuf2_v4l2 snd_pcm_oss videodev snd_mixer_oss snd_pcm snd_rn_pci_acp3x videobuf2_common snd_acp_config snd_timer snd_soc_acpi msi_wmi ecdh_generic ecc sparse_keymap mc edac_mce_amd wmi_bmof snd ccp k10temp joydev soundcore snd_pci_acp3x battery ac button hid_sensor_gyro_3d hid_sensor_prox hid_sensor_als hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio amd_pmc hid_sensor_iio_common evdev hid_multitouch serio_raw mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76
[ T8521] mac80211 libarc4 cfg80211 rfkill msr fuse nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 crc32c_generic mbcache jbd2 usbhid amdgpu i2c_algo_bit drm_ttm_helper xhci_pci ttm drm_exec drm_suballoc_helper xhci_hcd amdxcp drm_buddy hid_sensor_hub usbcore nvme gpu_sched mfd_core hid_generic crc32c_intel psmouse i2c_piix4 amd_sfh drm_display_helper usb_common nvme_core crc16 r8169 i2c_hid_acpi i2c_hid hid i2c_designware_platform i2c_designware_core
[ T8521] ---[ end trace 0000000000000000 ]---
[ T8521] RIP: 0010:exit_mmap+0x28c/0x2a0
[ T8521] Code: f7 45 31 ed e8 f5 7e e9 ff 4c 89 f7 e8 3d f4 6c 00 e9 63 ff ff ff 48 89 ef e8 70 11 04 00 e9 d1 fd ff ff 0f 0b e9 66 ff ff ff <0f> 0b e8 8d 0a 6c 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 66 0f
[ T8521] RSP: 0018:ffffac759002fca0 EFLAGS: 00010297
[ T8521] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ T8521] RDX: 0000000000000001 RSI: ffff8bb7caca9700 RDI: ffff8bb7caca9708
[ T8521] RBP: ffff8bb7c237e900 R08: 0000000000000000 R09: 000000000000000f
[ T8521] R10: 00007ffcc2b9bfff R11: 0000000000000078 R12: 00000000000006b5
[ T8521] R13: fffffffffffeb575 R14: ffff8bb7c237e9a8 R15: ffff8bb7c237e940
[ T8521] FS: 0000000000000000(0000) GS:ffff8bc6adfc0000(0000) knlGS:0000000000000000
[ T8521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ T8521] CR2: 00007f460adce000 CR3: 0000000fd1c18000 CR4: 0000000000750ef0
[ T8521] PKRU: 55555554
[ T8521] Fixing recursive fault but reboot is needed!
[ T8521] BUG: scheduling while atomic: Socket Thread/8521/0x00000000
[ T8521] Modules linked in: ccm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device rfcomm cmac bnep nls_ascii nls_cp437 vfat fat snd_ctl_led btusb snd_hda_codec_realtek btrtl btintel snd_hda_codec_generic btbcm btmtk snd_hda_scodec_component snd_hda_codec_hdmi bluetooth snd_hda_intel snd_intel_dspcfg uvcvideo snd_hda_codec videobuf2_vmalloc snd_acp3x_pdm_dma snd_soc_dmic snd_hwdep snd_acp3x_rn uvc amd_atl videobuf2_memops snd_soc_core snd_hda_core videobuf2_v4l2 snd_pcm_oss videodev snd_mixer_oss snd_pcm snd_rn_pci_acp3x videobuf2_common snd_acp_config snd_timer snd_soc_acpi msi_wmi ecdh_generic ecc sparse_keymap mc edac_mce_amd wmi_bmof snd ccp k10temp joydev soundcore snd_pci_acp3x battery ac button hid_sensor_gyro_3d hid_sensor_prox hid_sensor_als hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio amd_pmc hid_sensor_iio_common evdev hid_multitouch serio_raw mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76
[ T8521] mac80211 libarc4 cfg80211 rfkill msr fuse nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 crc32c_generic mbcache jbd2 usbhid amdgpu i2c_algo_bit drm_ttm_helper xhci_pci ttm drm_exec drm_suballoc_helper xhci_hcd amdxcp drm_buddy hid_sensor_hub usbcore nvme gpu_sched mfd_core hid_generic crc32c_intel psmouse i2c_piix4 amd_sfh drm_display_helper usb_common nvme_core crc16 r8169 i2c_hid_acpi i2c_hid hid i2c_designware_platform i2c_designware_core
[ T8521] CPU: 7 UID: 1000 PID: 8521 Comm: Socket Thread Tainted: G D 6.10.0-rc6-next-20240703-00016-g09a756327684 #1416
[ T8521] Tainted: [D]=DIE
[ T8521] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.107 11/10/2021
[ T8521] Call Trace:
[ T8521] <TASK>
[ T8521] ? dump_stack_lvl+0x53/0x70
[ T8521] ? __schedule_bug+0x4d/0x60
[ T8521] ? __schedule+0x734/0x800
[ T8521] ? srso_alias_return_thunk+0x5/0xfbef5
[ T8521] ? _printk+0x57/0x80
[ T8521] ? do_task_dead+0x3d/0x40
[ T8521] ? make_task_dead+0x13b/0x160
[ T8521] ? rewind_stack_and_make_dead+0x16/0x20
[ T8521] </TASK>
Bert Karwatzki
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
2024-06-27 1:28 ` Andrew Morton
@ 2024-06-27 13:31 ` Liam R. Howlett
0 siblings, 0 replies; 13+ messages in thread
From: Liam R. Howlett @ 2024-06-27 13:31 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Suren Baghdasaryan, Vlastimil Babka, Lorenzo Stoakes,
Matthew Wilcox, sidhartha.kumar, Paul E . McKenney,
Bert Karwatzki, Jiri Olsa, linux-kernel, Kees Cook
* Andrew Morton <akpm@linux-foundation.org> [240626 21:28]:
> On Wed, 26 Jun 2024 21:15:18 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
>
> > * Andrew Morton <akpm@linux-foundation.org> [240626 16:59]:
> > > On Tue, 25 Jun 2024 15:11:30 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
> > >
> > > > It is now possible to walk the vma tree using the rcu read locks and is
> > > > beneficial to do so to reduce lock contention. Doing so while a
> > > > MAP_FIXED mapping is executing means that a reader may see a gap in the
> > > > vma tree that should never logically exist - and does not when using the
> > > > mmap lock in read mode. The temporal gap exists because mmap_region()
> > > > calls munmap() prior to installing the new mapping.
> > >
> > > What are the consequences when this race hits? IOW, why do we need to
> > > change anything?
> > >
> >
> > In the (near) future, we want to walk the vma tree to produce
> > /proc/<pid>/maps. Without this change we will see the temporal gap and
> > expose it to the user. This series was initially sent to Suren as part
> > of his patch set.
> >
> > We also have the new interface for an ioctl request to a vma at or above
> > an address. I had highlighted that an rcu reader would be ideal, but
> > proved too difficult at this time. These patches by Andrii are currently
> > not using the rcu reading method as this and a per-vma locking
> > clarification are needed.
> >
> > Since there were two users for this code, I decided to send it out
> > before the other patches.
>
> OK, thanks. We're approaching -rc6 and things are a bit sketchy so I'm
> inclined to hold this off until the next cycle, unless there's urgency?
>
There is no urgency. I'm more than happy to hold off merging to get a
full cycle of testing.
Thanks,
Liam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-06-27 9:31 Bert Karwatzki
0 siblings, 0 replies; 13+ messages in thread
From: Bert Karwatzki @ 2024-06-27 9:31 UTC (permalink / raw)
To: Liam R . Howlett; +Cc: Bert Karwatzki, Andrew Morton, linux-mm
* Andrew Morton <akpm@linux-foundation.org> [240626 16:59]:
> On Tue, 25 Jun 2024 15:11:30 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
>
> > It is now possible to walk the vma tree using the rcu read locks and is
> > beneficial to do so to reduce lock contention. Doing so while a
> > MAP_FIXED mapping is executing means that a reader may see a gap in the
> > vma tree that should never logically exist - and does not when using the
> > mmap lock in read mode. The temporal gap exists because mmap_region()
> > calls munmap() prior to installing the new mapping.
>
> What are the consequences when this race hits? IOW, why do we need to
> change anything?
>
If I understand this correctly the plan is to replace mmap_read_lock(mm) by
rcu_read_lock(). So the consequences of a visible gap could be tested by
replacing mmap_read_lock(mm) by rcu_read_lock() within the old code. If this is
the case I'm willing to test it.
Bert Karwatzki
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
2024-06-27 1:15 ` Liam R. Howlett
@ 2024-06-27 1:28 ` Andrew Morton
2024-06-27 13:31 ` Liam R. Howlett
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Morton @ 2024-06-27 1:28 UTC (permalink / raw)
To: Liam R. Howlett
Cc: linux-mm, Suren Baghdasaryan, Vlastimil Babka, Lorenzo Stoakes,
Matthew Wilcox, sidhartha.kumar, Paul E . McKenney,
Bert Karwatzki, Jiri Olsa, linux-kernel, Kees Cook
On Wed, 26 Jun 2024 21:15:18 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
> * Andrew Morton <akpm@linux-foundation.org> [240626 16:59]:
> > On Tue, 25 Jun 2024 15:11:30 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
> >
> > > It is now possible to walk the vma tree using the rcu read locks and is
> > > beneficial to do so to reduce lock contention. Doing so while a
> > > MAP_FIXED mapping is executing means that a reader may see a gap in the
> > > vma tree that should never logically exist - and does not when using the
> > > mmap lock in read mode. The temporal gap exists because mmap_region()
> > > calls munmap() prior to installing the new mapping.
> >
> > What are the consequences when this race hits? IOW, why do we need to
> > change anything?
> >
>
> In the (near) future, we want to walk the vma tree to produce
> /proc/<pid>/maps. Without this change we will see the temporal gap and
> expose it to the user. This series was initially sent to Suren as part
> of his patch set.
>
> We also have the new interface for an ioctl request to a vma at or above
> an address. I had highlighted that an rcu reader would be ideal, but
> proved too difficult at this time. These patches by Andrii are currently
> not using the rcu reading method as this and a per-vma locking
> clarification are needed.
>
> Since there were two users for this code, I decided to send it out
> before the other patches.
OK, thanks. We're approaching -rc6 and things are a bit sketchy so I'm
inclined to hold this off until the next cycle, unless there's urgency?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
2024-06-26 20:58 ` Andrew Morton
@ 2024-06-27 1:15 ` Liam R. Howlett
2024-06-27 1:28 ` Andrew Morton
0 siblings, 1 reply; 13+ messages in thread
From: Liam R. Howlett @ 2024-06-27 1:15 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Suren Baghdasaryan, Vlastimil Babka, Lorenzo Stoakes,
Matthew Wilcox, sidhartha.kumar, Paul E . McKenney,
Bert Karwatzki, Jiri Olsa, linux-kernel, Kees Cook
* Andrew Morton <akpm@linux-foundation.org> [240626 16:59]:
> On Tue, 25 Jun 2024 15:11:30 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
>
> > It is now possible to walk the vma tree using the rcu read locks and is
> > beneficial to do so to reduce lock contention. Doing so while a
> > MAP_FIXED mapping is executing means that a reader may see a gap in the
> > vma tree that should never logically exist - and does not when using the
> > mmap lock in read mode. The temporal gap exists because mmap_region()
> > calls munmap() prior to installing the new mapping.
>
> What are the consequences when this race hits? IOW, why do we need to
> change anything?
>
In the (near) future, we want to walk the vma tree to produce
/proc/<pid>/maps. Without this change we will see the temporal gap and
expose it to the user. This series was initially sent to Suren as part
of his patch set.
We also have the new interface for an ioctl request to a vma at or above
an address. I had highlighted that an rcu reader would be ideal, but
proved too difficult at this time. These patches by Andrii are currently
not using the rcu reading method as this and a per-vma locking
clarification are needed.
Since there were two users for this code, I decided to send it out
before the other patches.
Thanks,
Liam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
2024-06-25 19:11 Liam R. Howlett
@ 2024-06-26 20:58 ` Andrew Morton
2024-06-27 1:15 ` Liam R. Howlett
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Morton @ 2024-06-26 20:58 UTC (permalink / raw)
To: Liam R. Howlett
Cc: linux-mm, Suren Baghdasaryan, Vlastimil Babka, Lorenzo Stoakes,
Matthew Wilcox, sidhartha.kumar, Paul E . McKenney,
Bert Karwatzki, Jiri Olsa, linux-kernel, Kees Cook
On Tue, 25 Jun 2024 15:11:30 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
> It is now possible to walk the vma tree using the rcu read locks and is
> beneficial to do so to reduce lock contention. Doing so while a
> MAP_FIXED mapping is executing means that a reader may see a gap in the
> vma tree that should never logically exist - and does not when using the
> mmap lock in read mode. The temporal gap exists because mmap_region()
> calls munmap() prior to installing the new mapping.
What are the consequences when this race hits? IOW, why do we need to
change anything?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 00/15] Avoid MAP_FIXED gap exposure
@ 2024-06-25 19:11 Liam R. Howlett
2024-06-26 20:58 ` Andrew Morton
0 siblings, 1 reply; 13+ messages in thread
From: Liam R. Howlett @ 2024-06-25 19:11 UTC (permalink / raw)
To: linux-mm, Andrew Morton
Cc: Suren Baghdasaryan, Vlastimil Babka, Lorenzo Stoakes,
Matthew Wilcox, sidhartha.kumar, Paul E . McKenney,
Bert Karwatzki, Jiri Olsa, linux-kernel, Kees Cook,
Liam R. Howlett
It is now possible to walk the vma tree using the rcu read locks and is
beneficial to do so to reduce lock contention. Doing so while a
MAP_FIXED mapping is executing means that a reader may see a gap in the
vma tree that should never logically exist - and does not when using the
mmap lock in read mode. The temporal gap exists because mmap_region()
calls munmap() prior to installing the new mapping.
This patch set stops rcu readers from seeing the temporal gap by
splitting up the munmap() function into two parts. The first part
prepares the vma tree for modifications by doing the necessary splits
and tracks the vmas marked for removal in a side tree. The second part
completes the munmapping of the vmas after the vma tree has been
overwritten (either by a MAP_FIXED replacement vma or by a NULL in the
munmap() case).
Please note that rcu walkers will still be able to see a temporary state
of split vmas that may be in the process of being removed, but the
temporal gap will not be exposed. vma_start_write() are called on both
parts of the split vma, so this state is detectable.
RFC: https://lore.kernel.org/linux-mm/20240531163217.1584450-1-Liam.Howlett@oracle.com/
v1: https://lore.kernel.org/linux-mm/20240611180200.711239-1-Liam.Howlett@oracle.com/
Changes since v1:
- Fixed issue with expanding vmas clearing the incorrect PTE range,
Thanks Bert Karwatzki and Jiri Olsa for testing linux-next
- Separated patches into smaller portions for easier reviewing
- Replaced open coded shifting of length with PHYS_PFN()
- Changed security calculation (Cc Kees on this change)
- Changed the vma iterator use to point to the targeted area instead of
the previous vma
- Remove page table entries prior to fully removing the vmas, if a
driver may do mappings
- Tested with stress-ng and split/joining of VMA at the start, end, and
middle of a vma.
Liam R. Howlett (15):
mm/mmap: Correctly position vma_iterator in __split_vma()
mm/mmap: Introduce abort_munmap_vmas()
mm/mmap: Introduce vmi_complete_munmap_vmas()
mm/mmap: Extract the gathering of vmas from do_vmi_align_munmap()
mm/mmap: Introduce vma_munmap_struct for use in munmap operations
mm/mmap: Change munmap to use vma_munmap_struct() for accounting and
surrounding vmas
mm/mmap: Extract validate_mm() from vma_complete()
mm/mmap: Inline munmap operation in mmap_region()
mm/mmap: Expand mmap_region() munmap call
mm/mmap: Reposition vma iterator in mmap_region()
mm/mmap: Track start and end of munmap in vma_munmap_struct
mm/mmap: Avoid zeroing vma tree in mmap_region()
mm/mmap: Use PHYS_PFN in mmap_region()
mm/mmap: Use vms accounted pages in mmap_region()
mm/mmap: Move may_expand_vm() check in mmap_region()
mm/internal.h | 25 +++
mm/mmap.c | 449 +++++++++++++++++++++++++++++++-------------------
2 files changed, 304 insertions(+), 170 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2024-07-04 21:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-04 21:50 [PATCH v2 00/15] Avoid MAP_FIXED gap exposure Bert Karwatzki
-- strict thread matches above, loose matches on Subject: below --
2024-07-04 21:15 Bert Karwatzki
2024-07-04 21:07 Bert Karwatzki
2024-07-03 14:30 Bert Karwatzki
2024-07-04 18:31 ` Liam R. Howlett
2024-07-03 10:13 Bert Karwatzki
2024-07-03 13:53 ` Liam R. Howlett
2024-06-27 9:31 Bert Karwatzki
2024-06-25 19:11 Liam R. Howlett
2024-06-26 20:58 ` Andrew Morton
2024-06-27 1:15 ` Liam R. Howlett
2024-06-27 1:28 ` Andrew Morton
2024-06-27 13:31 ` Liam R. Howlett
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox