Re: uprobes: memory leak in enable/disable loop
On Tue, Aug 16, 2016 at 04:34:08PM +0200, Oleg Nesterov wrote:
> @@ -172,8 +172,10 @@ static int __replace_page(struct vm_area
> mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
> err = -EAGAIN;
> ptep = page_check_address(page, mm, addr, , 0);
> - if (!ptep)
> + if (!ptep) {
> + mem_cgroup_cancel_charge(kpage, memcg, false);
> goto unlock;
> + }
>
> get_page(kpage);
> page_add_new_anon_rmap(kpage, vma, addr, false);
> @@ -200,7 +202,6 @@ static int __replace_page(struct vm_area
>
> err = 0;
> unlock:
> - mem_cgroup_cancel_charge(kpage, memcg, false);
Ouch. I must have mistaken this for an exclusive error path.
The patch looks good, thank you.
Reviewed-by: Johannes Weiner
Fixes: 00501b531c47 ("mm: memcontrol: rewrite charge API")
Cc: sta...@vger.kernel.org # 3.17+
Re: uprobes: memory leak in enable/disable loop
On Tue, Aug 16, 2016 at 04:34:08PM +0200, Oleg Nesterov wrote:
> @@ -172,8 +172,10 @@ static int __replace_page(struct vm_area
> mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
> err = -EAGAIN;
> ptep = page_check_address(page, mm, addr, , 0);
> - if (!ptep)
> + if (!ptep) {
> + mem_cgroup_cancel_charge(kpage, memcg, false);
> goto unlock;
> + }
>
> get_page(kpage);
> page_add_new_anon_rmap(kpage, vma, addr, false);
> @@ -200,7 +202,6 @@ static int __replace_page(struct vm_area
>
> err = 0;
> unlock:
> - mem_cgroup_cancel_charge(kpage, memcg, false);
Ouch. I must have mistaken this for an exclusive error path.
The patch looks good, thank you.
Reviewed-by: Johannes Weiner
Fixes: 00501b531c47 ("mm: memcontrol: rewrite charge API")
Cc: sta...@vger.kernel.org # 3.17+
Re: uprobes: memory leak in enable/disable loop
On Tue, Aug 16, 2016 at 04:34:08PM +0200, Oleg Nesterov wrote:
> On 08/16, Oleg Nesterov wrote:
> >
> > On 08/16, Oleg Nesterov wrote:
> > >
> > > On 08/15, Brenden Blanco wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I think I have come across a memory leak in uprobes, which is fairly
> > > > easy to
> > > > reproduce.
> > >
> > > At first glance this looks as a problem in memcg, add CC's...
> > >
> > > put_page(old_page) looks properly balanced, and I assume we do not need
> > > the additional "uncharge", we can rely on __page_cache_release().
> > >
> > > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
> >
> > Heh. it seems that mem_cgroup_*() logic was always wrong in
> > __replace_page().
>
> Yes, it seems this was broken by 00501b53 "mm: memcontrol: rewrite charge
> API".
>
> > Could you try the patch below?
>
> Please see v2 below. We don't need "cancel_charge" under "unlock:" at all.
>
> Johannes, could you review?
>
> Oleg.
> ---
> --- x/kernel/events/uprobes.c
> +++ x/kernel/events/uprobes.c
> @@ -172,8 +172,10 @@ static int __replace_page(struct vm_area
> mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
> err = -EAGAIN;
> ptep = page_check_address(page, mm, addr, , 0);
> - if (!ptep)
> + if (!ptep) {
> + mem_cgroup_cancel_charge(kpage, memcg, false);
> goto unlock;
> + }
>
> get_page(kpage);
> page_add_new_anon_rmap(kpage, vma, addr, false);
> @@ -200,7 +202,6 @@ static int __replace_page(struct vm_area
>
> err = 0;
> unlock:
> - mem_cgroup_cancel_charge(kpage, memcg, false);
> mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
> unlock_page(page);
> return err;
>
This passes my tests, thanks!
Please note that I applied this to 4.4.15+ubuntu-patches kernel, since that
was what I had most handy, therefore I had to adjust the patch to remove the
unavailable 'compound' bool parameter in 4.4 kernels.
Re: uprobes: memory leak in enable/disable loop
On Tue, Aug 16, 2016 at 04:34:08PM +0200, Oleg Nesterov wrote:
> On 08/16, Oleg Nesterov wrote:
> >
> > On 08/16, Oleg Nesterov wrote:
> > >
> > > On 08/15, Brenden Blanco wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I think I have come across a memory leak in uprobes, which is fairly
> > > > easy to
> > > > reproduce.
> > >
> > > At first glance this looks as a problem in memcg, add CC's...
> > >
> > > put_page(old_page) looks properly balanced, and I assume we do not need
> > > the additional "uncharge", we can rely on __page_cache_release().
> > >
> > > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
> >
> > Heh. it seems that mem_cgroup_*() logic was always wrong in
> > __replace_page().
>
> Yes, it seems this was broken by 00501b53 "mm: memcontrol: rewrite charge
> API".
>
> > Could you try the patch below?
>
> Please see v2 below. We don't need "cancel_charge" under "unlock:" at all.
>
> Johannes, could you review?
>
> Oleg.
> ---
> --- x/kernel/events/uprobes.c
> +++ x/kernel/events/uprobes.c
> @@ -172,8 +172,10 @@ static int __replace_page(struct vm_area
> mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
> err = -EAGAIN;
> ptep = page_check_address(page, mm, addr, , 0);
> - if (!ptep)
> + if (!ptep) {
> + mem_cgroup_cancel_charge(kpage, memcg, false);
> goto unlock;
> + }
>
> get_page(kpage);
> page_add_new_anon_rmap(kpage, vma, addr, false);
> @@ -200,7 +202,6 @@ static int __replace_page(struct vm_area
>
> err = 0;
> unlock:
> - mem_cgroup_cancel_charge(kpage, memcg, false);
> mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
> unlock_page(page);
> return err;
>
This passes my tests, thanks!
Please note that I applied this to 4.4.15+ubuntu-patches kernel, since that
was what I had most handy, therefore I had to adjust the patch to remove the
unavailable 'compound' bool parameter in 4.4 kernels.
Re: uprobes: memory leak in enable/disable loop
On Tue 16-08-16 16:25:12, Oleg Nesterov wrote:
> On 08/16, Oleg Nesterov wrote:
> >
> > On 08/15, Brenden Blanco wrote:
> > >
> > > Hi folks,
> > >
> > > I think I have come across a memory leak in uprobes, which is fairly easy
> > > to
> > > reproduce.
> >
> > At first glance this looks as a problem in memcg, add CC's...
> >
> > put_page(old_page) looks properly balanced, and I assume we do not need
> > the additional "uncharge", we can rely on __page_cache_release().
> >
> > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
>
> Heh. it seems that mem_cgroup_*() logic was always wrong in __replace_page().
Yes this seems broken since 00501b531c47 ("mm: memcontrol: rewrite
charge API")
> Could you try the patch below?
The patch looks good to me. Thanks!
> Oleg.
> ---
>
> --- x/kernel/events/uprobes.c
> +++ x/kernel/events/uprobes.c
> @@ -200,7 +200,8 @@ static int __replace_page(struct vm_area
>
> err = 0;
> unlock:
> - mem_cgroup_cancel_charge(kpage, memcg, false);
> + if (err)
> + mem_cgroup_cancel_charge(kpage, memcg, false);
> mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
> unlock_page(page);
> return err;
--
Michal Hocko
SUSE Labs
Re: uprobes: memory leak in enable/disable loop
On Tue 16-08-16 16:25:12, Oleg Nesterov wrote:
> On 08/16, Oleg Nesterov wrote:
> >
> > On 08/15, Brenden Blanco wrote:
> > >
> > > Hi folks,
> > >
> > > I think I have come across a memory leak in uprobes, which is fairly easy
> > > to
> > > reproduce.
> >
> > At first glance this looks as a problem in memcg, add CC's...
> >
> > put_page(old_page) looks properly balanced, and I assume we do not need
> > the additional "uncharge", we can rely on __page_cache_release().
> >
> > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
>
> Heh. it seems that mem_cgroup_*() logic was always wrong in __replace_page().
Yes this seems broken since 00501b531c47 ("mm: memcontrol: rewrite
charge API")
> Could you try the patch below?
The patch looks good to me. Thanks!
> Oleg.
> ---
>
> --- x/kernel/events/uprobes.c
> +++ x/kernel/events/uprobes.c
> @@ -200,7 +200,8 @@ static int __replace_page(struct vm_area
>
> err = 0;
> unlock:
> - mem_cgroup_cancel_charge(kpage, memcg, false);
> + if (err)
> + mem_cgroup_cancel_charge(kpage, memcg, false);
> mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
> unlock_page(page);
> return err;
--
Michal Hocko
SUSE Labs
Re: uprobes: memory leak in enable/disable loop
On 08/16, Oleg Nesterov wrote:
>
> On 08/16, Oleg Nesterov wrote:
> >
> > On 08/15, Brenden Blanco wrote:
> > >
> > > Hi folks,
> > >
> > > I think I have come across a memory leak in uprobes, which is fairly easy
> > > to
> > > reproduce.
> >
> > At first glance this looks as a problem in memcg, add CC's...
> >
> > put_page(old_page) looks properly balanced, and I assume we do not need
> > the additional "uncharge", we can rely on __page_cache_release().
> >
> > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
>
> Heh. it seems that mem_cgroup_*() logic was always wrong in __replace_page().
Yes, it seems this was broken by 00501b53 "mm: memcontrol: rewrite charge API".
> Could you try the patch below?
Please see v2 below. We don't need "cancel_charge" under "unlock:" at all.
Johannes, could you review?
Oleg.
---
--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -172,8 +172,10 @@ static int __replace_page(struct vm_area
mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
err = -EAGAIN;
ptep = page_check_address(page, mm, addr, , 0);
- if (!ptep)
+ if (!ptep) {
+ mem_cgroup_cancel_charge(kpage, memcg, false);
goto unlock;
+ }
get_page(kpage);
page_add_new_anon_rmap(kpage, vma, addr, false);
@@ -200,7 +202,6 @@ static int __replace_page(struct vm_area
err = 0;
unlock:
- mem_cgroup_cancel_charge(kpage, memcg, false);
mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
unlock_page(page);
return err;
Re: uprobes: memory leak in enable/disable loop
On 08/16, Oleg Nesterov wrote:
>
> On 08/16, Oleg Nesterov wrote:
> >
> > On 08/15, Brenden Blanco wrote:
> > >
> > > Hi folks,
> > >
> > > I think I have come across a memory leak in uprobes, which is fairly easy
> > > to
> > > reproduce.
> >
> > At first glance this looks as a problem in memcg, add CC's...
> >
> > put_page(old_page) looks properly balanced, and I assume we do not need
> > the additional "uncharge", we can rely on __page_cache_release().
> >
> > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
>
> Heh. it seems that mem_cgroup_*() logic was always wrong in __replace_page().
Yes, it seems this was broken by 00501b53 "mm: memcontrol: rewrite charge API".
> Could you try the patch below?
Please see v2 below. We don't need "cancel_charge" under "unlock:" at all.
Johannes, could you review?
Oleg.
---
--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -172,8 +172,10 @@ static int __replace_page(struct vm_area
mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
err = -EAGAIN;
ptep = page_check_address(page, mm, addr, , 0);
- if (!ptep)
+ if (!ptep) {
+ mem_cgroup_cancel_charge(kpage, memcg, false);
goto unlock;
+ }
get_page(kpage);
page_add_new_anon_rmap(kpage, vma, addr, false);
@@ -200,7 +202,6 @@ static int __replace_page(struct vm_area
err = 0;
unlock:
- mem_cgroup_cancel_charge(kpage, memcg, false);
mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
unlock_page(page);
return err;
Re: uprobes: memory leak in enable/disable loop
On 08/16, Oleg Nesterov wrote: > > On 08/15, Brenden Blanco wrote: > > > > Hi folks, > > > > I think I have come across a memory leak in uprobes, which is fairly easy to > > reproduce. > > At first glance this looks as a problem in memcg, add CC's... > > put_page(old_page) looks properly balanced, and I assume we do not need > the additional "uncharge", we can rely on __page_cache_release(). > > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n. Heh. it seems that mem_cgroup_*() logic was always wrong in __replace_page(). Could you try the patch below? Oleg. --- --- x/kernel/events/uprobes.c +++ x/kernel/events/uprobes.c @@ -200,7 +200,8 @@ static int __replace_page(struct vm_area err = 0; unlock: - mem_cgroup_cancel_charge(kpage, memcg, false); + if (err) + mem_cgroup_cancel_charge(kpage, memcg, false); mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end); unlock_page(page); return err;
Re: uprobes: memory leak in enable/disable loop
On 08/16, Oleg Nesterov wrote: > > On 08/15, Brenden Blanco wrote: > > > > Hi folks, > > > > I think I have come across a memory leak in uprobes, which is fairly easy to > > reproduce. > > At first glance this looks as a problem in memcg, add CC's... > > put_page(old_page) looks properly balanced, and I assume we do not need > the additional "uncharge", we can rely on __page_cache_release(). > > And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n. Heh. it seems that mem_cgroup_*() logic was always wrong in __replace_page(). Could you try the patch below? Oleg. --- --- x/kernel/events/uprobes.c +++ x/kernel/events/uprobes.c @@ -200,7 +200,8 @@ static int __replace_page(struct vm_area err = 0; unlock: - mem_cgroup_cancel_charge(kpage, memcg, false); + if (err) + mem_cgroup_cancel_charge(kpage, memcg, false); mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end); unlock_page(page); return err;
Re: uprobes: memory leak in enable/disable loop
On 08/15, Brenden Blanco wrote:
>
> Hi folks,
>
> I think I have come across a memory leak in uprobes, which is fairly easy to
> reproduce.
At first glance this looks as a problem in memcg, add CC's...
put_page(old_page) looks properly balanced, and I assume we do not need
the additional "uncharge", we can rely on __page_cache_release().
And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
> Using a repeated use of a single uprobe, I am able to run my system out of
> memory, resulting in system failures and a need to reboot the box. When I
> first became aware of the failure, I was able to narrow down the first
> userspace-visible failure to -ENOMEM being returned from
> kernel/events/uprobes.c:uprobe_write_opcode(), though I can't say whether that
> is the actual cause of the leak or just a victim. With the below reproduction
> steps, hopefully someone smarter than me can understand the problem and
> propose
> a solution, which I would be happy to test.
>
> So far, I have reproduced the issue on kernels 4.4 and 4.8-rc2. I've tried on
> distributions from Ubuntu as well as Arch Linux. Continue reading for a rough
> log of the steps to reproduce.
>
> Thanks,
> Brenden
>
>
>
> root@localhost# uname -r
> 4.8.0-040800rc2-generic
> root@localhost# cd /sys/kernel/debug/tracing
> root@localhost# echo "p:uprobes/libc_so_6
> /lib/x86_64-linux-gnu/libc.so.6:0x00086560" > uprobe_events
> root@localhost# # number of iterations before failure depends on the amount
> of memory in your system
> root@localhost# for i in {1..48}; do echo 1 >
> events/uprobes/libc_so_6/enable; echo 0 > events/uprobes/libc_so_6/enable;
> done
>
> root@localhost# dmesg
> [ 2182.439038] [ cut here ]
> [ 2182.439042] WARNING: CPU: 6 PID: 4763 at
> /home/kernel/COD/linux/mm/page_counter.c:26 page_counter_uncharge+0x1d/0x30
> [ 2182.439043] Modules linked in: fuse binfmt_misc snd_hda_codec_generic
> snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep ppdev snd_pcm parport_pc
> snd_timer sg virtio_balloon virtio_console acpi_cpufreq parport serio_raw
> i2c_piix4 snd soundcore tpm_tis intel_powerclamp tpm_tis_core intel_rapl_perf
> evdev squashfs tpm loop ib_iser rdma_cm iw_cm ib_cm ib_core configfs
> iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 ext4 crc16 jbd2
> fscrypto mbcache btrfs dm_mod raid10 raid456 async_raid6_recov async_memcpy
> async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0
> multipath linear md_mod sd_mod ata_generic 8139too crct10dif_pclmul
> crc32_pclmul crc32c_intel ghash_clmulni_intel qxl aesni_intel aes_x86_64 lrw
> ttm virtio_pci ehci_pci uhci_hcd drm_kms_helper ehci_hcd ata_piix
> [ 2182.439067] gf128mul psmouse virtio_ring glue_helper libata ablk_helper
> 8139cp scsi_mod cryptd mii usbcore usb_common floppy virtio drm button
> [ 2182.439074] CPU: 6 PID: 4763 Comm: bash Not tainted
> 4.8.0-040800rc2-generic #201608142332
> [ 2182.439074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.9.3-20160701_074356-anatol 04/01/2014
> [ 2182.439075] 0286 d2708db2 9ad3de94
>
> [ 2182.439076] 9aa7f4ee 8be0e749e8c0
> 001f
> [ 2182.439077] 8be0e749e800 001f 8be0f4647bb0
> 8be0e71860c0
> [ 2182.439078] Call Trace:
> [ 2182.439081] [] ? dump_stack+0x5c/0x78
> [ 2182.439083] [] ? __warn+0xbe/0xe0
> [ 2182.439084] [] ? page_counter_uncharge+0x1d/0x30
> [ 2182.439085] [] ? drain_stock.isra.30+0x32/0xa0
> [ 2182.439086] [] ? try_charge+0x5f1/0x6b0
> [ 2182.439087] [] ? alloc_pages_vma+0xbb/0x240
> [ 2182.439088] [] ? mem_cgroup_try_charge+0x67/0x1b0
> [ 2182.439090] [] ? uprobe_write_opcode+0x25c/0x5e0
> [ 2182.439091] [] ?
> install_breakpoint.isra.21.part.22+0x55/0x70
> [ 2182.439092] [] ? register_for_each_vma+0x36d/0x420
> [ 2182.439092] [] ? uprobe_register+0x16e/0x290
> [ 2182.439094] [] ? probe_event_enable+0xef/0x350
> [ 2182.439096] [] ?
> __ftrace_event_enable_disable+0x5c/0x1e0
> [ 2182.439097] [] ? event_enable_write+0x95/0xe0
> [ 2182.439098] [] ? __vfs_write+0x33/0x160
> [ 2182.439101] [] ? __fd_install+0x2e/0xe0
> [ 2182.439102] [] ? __alloc_fd+0x43/0x170
> [ 2182.439104] [] ? security_file_permission+0x38/0xb0
> [ 2182.439105] [] ? vfs_write+0xb0/0x190
> [ 2182.439106] [] ? SyS_write+0x52/0xc0
> [ 2182.439107] [] ? SyS_dup2+0x95/0x100
> [ 2182.439109] [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8
> [ 2182.439110] ---[ end trace 320efb00be7bb830 ]---
>
> After this, continued toggling of the uprobe will eventually fail.
>
> root@localhost# for i in {1..100}; do echo 1 >
> events/uprobes/libc_so_6/enable; [[ $? -ne 0 ]] && break; echo 0 >
> events/uprobes/libc_so_6/enable; done
> -bash: echo: write error: Cannot allocate memory
>
> After running the uprobes out of memory, oom-killer started to pick off
> system
Re: uprobes: memory leak in enable/disable loop
On 08/15, Brenden Blanco wrote:
>
> Hi folks,
>
> I think I have come across a memory leak in uprobes, which is fairly easy to
> reproduce.
At first glance this looks as a problem in memcg, add CC's...
put_page(old_page) looks properly balanced, and I assume we do not need
the additional "uncharge", we can rely on __page_cache_release().
And I do not see any leak if I try to reproduce with CONFIG_MEMCG=n.
> Using a repeated use of a single uprobe, I am able to run my system out of
> memory, resulting in system failures and a need to reboot the box. When I
> first became aware of the failure, I was able to narrow down the first
> userspace-visible failure to -ENOMEM being returned from
> kernel/events/uprobes.c:uprobe_write_opcode(), though I can't say whether that
> is the actual cause of the leak or just a victim. With the below reproduction
> steps, hopefully someone smarter than me can understand the problem and
> propose
> a solution, which I would be happy to test.
>
> So far, I have reproduced the issue on kernels 4.4 and 4.8-rc2. I've tried on
> distributions from Ubuntu as well as Arch Linux. Continue reading for a rough
> log of the steps to reproduce.
>
> Thanks,
> Brenden
>
>
>
> root@localhost# uname -r
> 4.8.0-040800rc2-generic
> root@localhost# cd /sys/kernel/debug/tracing
> root@localhost# echo "p:uprobes/libc_so_6
> /lib/x86_64-linux-gnu/libc.so.6:0x00086560" > uprobe_events
> root@localhost# # number of iterations before failure depends on the amount
> of memory in your system
> root@localhost# for i in {1..48}; do echo 1 >
> events/uprobes/libc_so_6/enable; echo 0 > events/uprobes/libc_so_6/enable;
> done
>
> root@localhost# dmesg
> [ 2182.439038] [ cut here ]
> [ 2182.439042] WARNING: CPU: 6 PID: 4763 at
> /home/kernel/COD/linux/mm/page_counter.c:26 page_counter_uncharge+0x1d/0x30
> [ 2182.439043] Modules linked in: fuse binfmt_misc snd_hda_codec_generic
> snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep ppdev snd_pcm parport_pc
> snd_timer sg virtio_balloon virtio_console acpi_cpufreq parport serio_raw
> i2c_piix4 snd soundcore tpm_tis intel_powerclamp tpm_tis_core intel_rapl_perf
> evdev squashfs tpm loop ib_iser rdma_cm iw_cm ib_cm ib_core configfs
> iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 ext4 crc16 jbd2
> fscrypto mbcache btrfs dm_mod raid10 raid456 async_raid6_recov async_memcpy
> async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0
> multipath linear md_mod sd_mod ata_generic 8139too crct10dif_pclmul
> crc32_pclmul crc32c_intel ghash_clmulni_intel qxl aesni_intel aes_x86_64 lrw
> ttm virtio_pci ehci_pci uhci_hcd drm_kms_helper ehci_hcd ata_piix
> [ 2182.439067] gf128mul psmouse virtio_ring glue_helper libata ablk_helper
> 8139cp scsi_mod cryptd mii usbcore usb_common floppy virtio drm button
> [ 2182.439074] CPU: 6 PID: 4763 Comm: bash Not tainted
> 4.8.0-040800rc2-generic #201608142332
> [ 2182.439074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.9.3-20160701_074356-anatol 04/01/2014
> [ 2182.439075] 0286 d2708db2 9ad3de94
>
> [ 2182.439076] 9aa7f4ee 8be0e749e8c0
> 001f
> [ 2182.439077] 8be0e749e800 001f 8be0f4647bb0
> 8be0e71860c0
> [ 2182.439078] Call Trace:
> [ 2182.439081] [] ? dump_stack+0x5c/0x78
> [ 2182.439083] [] ? __warn+0xbe/0xe0
> [ 2182.439084] [] ? page_counter_uncharge+0x1d/0x30
> [ 2182.439085] [] ? drain_stock.isra.30+0x32/0xa0
> [ 2182.439086] [] ? try_charge+0x5f1/0x6b0
> [ 2182.439087] [] ? alloc_pages_vma+0xbb/0x240
> [ 2182.439088] [] ? mem_cgroup_try_charge+0x67/0x1b0
> [ 2182.439090] [] ? uprobe_write_opcode+0x25c/0x5e0
> [ 2182.439091] [] ?
> install_breakpoint.isra.21.part.22+0x55/0x70
> [ 2182.439092] [] ? register_for_each_vma+0x36d/0x420
> [ 2182.439092] [] ? uprobe_register+0x16e/0x290
> [ 2182.439094] [] ? probe_event_enable+0xef/0x350
> [ 2182.439096] [] ?
> __ftrace_event_enable_disable+0x5c/0x1e0
> [ 2182.439097] [] ? event_enable_write+0x95/0xe0
> [ 2182.439098] [] ? __vfs_write+0x33/0x160
> [ 2182.439101] [] ? __fd_install+0x2e/0xe0
> [ 2182.439102] [] ? __alloc_fd+0x43/0x170
> [ 2182.439104] [] ? security_file_permission+0x38/0xb0
> [ 2182.439105] [] ? vfs_write+0xb0/0x190
> [ 2182.439106] [] ? SyS_write+0x52/0xc0
> [ 2182.439107] [] ? SyS_dup2+0x95/0x100
> [ 2182.439109] [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8
> [ 2182.439110] ---[ end trace 320efb00be7bb830 ]---
>
> After this, continued toggling of the uprobe will eventually fail.
>
> root@localhost# for i in {1..100}; do echo 1 >
> events/uprobes/libc_so_6/enable; [[ $? -ne 0 ]] && break; echo 0 >
> events/uprobes/libc_so_6/enable; done
> -bash: echo: write error: Cannot allocate memory
>
> After running the uprobes out of memory, oom-killer started to pick off
> system
