From: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
To: Wang Nan <wangnan0-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] cgroup/kmemleak: add kmemleak_free() for cgroup deallocations.
Date: Mon, 22 Sep 2014 15:48:27 +0200 [thread overview]
Message-ID: <20140922134827.GD336@dhcp22.suse.cz> (raw)
In-Reply-To: <1411004285-42101-1-git-send-email-wangnan0-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Thu 18-09-14 09:38:05, Wang Nan wrote:
> Commit ff7ee93f4 introduces kmemleak_alloc() for alloc_page_cgroup(),
> but corresponding kmemleak_free() is missing, which makes kmemleak be
> wrongly disabled after memory offlining. Log is pasted at the end of
> this commit message.
>
> This patch add kmemleak_free() into free_page_cgroup(). During page
> offlining, this patch removes corresponding entries in kmemleak rbtree.
> After that, the freed memory can be allocated again by other subsystems
> without killing kmemleak.
>
> bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak
> [ 45.537934] Offlined Pages 32768
> [ 46.617892] kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing)
> [ 46.617892] CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
> [ 46.617892] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 46.617892] ffff880016823d10 ffff880018bdfc38 ffffffff81725d2c ffff88001780e950
> [ 46.617892] ffff880016969000 ffff880018bdfc88 ffffffff8117a9e6 ffff880018bdfc78
> [ 46.617892] 0000000000000096 ffff880017812800 ffffffff81c2eda0 ffff880016969000
> [ 46.617892] Call Trace:
> [ 46.617892] [<ffffffff81725d2c>] dump_stack+0x46/0x58
> [ 46.617892] [<ffffffff8117a9e6>] create_object+0x266/0x2c0
> [ 46.617892] [<ffffffff8171d2f6>] kmemleak_alloc+0x26/0x50
> [ 46.617892] [<ffffffff8116a3a3>] kmem_cache_alloc+0xd3/0x160
> [ 46.617892] [<ffffffff81058e59>] __sigqueue_alloc+0x49/0xd0
> [ 46.617892] [<ffffffff8105a41b>] __send_signal+0xcb/0x410
> [ 46.617892] [<ffffffff8105a7a5>] send_signal+0x45/0x90
> [ 46.617892] [<ffffffff8105a803>] __group_send_sig_info+0x13/0x20
> [ 46.617892] [<ffffffff8105bd0b>] do_notify_parent+0x1bb/0x260
> [ 46.617892] [<ffffffff81077e7a>] ? sched_move_task+0xaa/0x130
> [ 46.617892] [<ffffffff81050917>] do_exit+0x767/0xa40
> [ 46.617892] [<ffffffff81050c84>] do_group_exit+0x44/0xa0
> [ 46.617892] [<ffffffff81050cf7>] SyS_exit_group+0x17/0x20
> [ 46.617892] [<ffffffff8172cd12>] system_call_fastpath+0x16/0x1b
> [ 46.617892] kmemleak: Kernel memory leak detector disabled
> [ 46.617892] kmemleak: Object 0xffff880016900000 (size 524288):
> [ 46.617892] kmemleak: comm "swapper/0", pid 0, jiffies 4294667296
> [ 46.617892] kmemleak: min_count = 0
> [ 46.617892] kmemleak: count = 0
> [ 46.617892] kmemleak: flags = 0x1
> [ 46.617892] kmemleak: checksum = 0
> [ 46.617892] kmemleak: backtrace:
> [ 46.617892] [<ffffffff81d0a7f0>] log_early+0x63/0x77
> [ 46.617892] [<ffffffff8171d31b>] kmemleak_alloc+0x4b/0x50
> [ 46.617892] [<ffffffff81720e4f>] init_section_page_cgroup+0x7f/0xf5
> [ 46.617892] [<ffffffff81d0a6f0>] page_cgroup_init+0xc5/0xd0
> [ 46.617892] [<ffffffff81ce4ed9>] start_kernel+0x333/0x408
> [ 46.617892] [<ffffffff81ce45b2>] x86_64_start_reservations+0x2a/0x2c
> [ 46.617892] [<ffffffff81ce46a9>] x86_64_start_kernel+0xf5/0xfc
> [ 46.617892] [<ffffffffffffffff>] 0xffffffffffffffff
>
> Signed-off-by: Wang Nan <wangnan0-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
Acked-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
And sorry, I should have noticed that when reviewing the original patch
which added kmemleak_alloc.
I think this is worth going into stable. The risk is marginal and
somebody might be relying on kmemleak even on older kernels when
debugging a bug during memory hotplug.
Thanks!
> ---
> mm/page_cgroup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 3708264..5331c2b 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -171,6 +171,7 @@ static void free_page_cgroup(void *addr)
> sizeof(struct page_cgroup) * PAGES_PER_SECTION;
>
> BUG_ON(PageReserved(page));
> + kmemleak_free(addr);
> free_pages_exact(addr, table_size);
> }
> }
> --
> 1.8.4
>
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: Wang Nan <wangnan0@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Steven Rostedt <rostedt@goodmis.org>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Li Zefan <lizefan@huawei.com>
Subject: Re: [PATCH] cgroup/kmemleak: add kmemleak_free() for cgroup deallocations.
Date: Mon, 22 Sep 2014 15:48:27 +0200 [thread overview]
Message-ID: <20140922134827.GD336@dhcp22.suse.cz> (raw)
In-Reply-To: <1411004285-42101-1-git-send-email-wangnan0@huawei.com>
On Thu 18-09-14 09:38:05, Wang Nan wrote:
> Commit ff7ee93f4 introduces kmemleak_alloc() for alloc_page_cgroup(),
> but corresponding kmemleak_free() is missing, which makes kmemleak be
> wrongly disabled after memory offlining. Log is pasted at the end of
> this commit message.
>
> This patch add kmemleak_free() into free_page_cgroup(). During page
> offlining, this patch removes corresponding entries in kmemleak rbtree.
> After that, the freed memory can be allocated again by other subsystems
> without killing kmemleak.
>
> bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak
> [ 45.537934] Offlined Pages 32768
> [ 46.617892] kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing)
> [ 46.617892] CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
> [ 46.617892] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 46.617892] ffff880016823d10 ffff880018bdfc38 ffffffff81725d2c ffff88001780e950
> [ 46.617892] ffff880016969000 ffff880018bdfc88 ffffffff8117a9e6 ffff880018bdfc78
> [ 46.617892] 0000000000000096 ffff880017812800 ffffffff81c2eda0 ffff880016969000
> [ 46.617892] Call Trace:
> [ 46.617892] [<ffffffff81725d2c>] dump_stack+0x46/0x58
> [ 46.617892] [<ffffffff8117a9e6>] create_object+0x266/0x2c0
> [ 46.617892] [<ffffffff8171d2f6>] kmemleak_alloc+0x26/0x50
> [ 46.617892] [<ffffffff8116a3a3>] kmem_cache_alloc+0xd3/0x160
> [ 46.617892] [<ffffffff81058e59>] __sigqueue_alloc+0x49/0xd0
> [ 46.617892] [<ffffffff8105a41b>] __send_signal+0xcb/0x410
> [ 46.617892] [<ffffffff8105a7a5>] send_signal+0x45/0x90
> [ 46.617892] [<ffffffff8105a803>] __group_send_sig_info+0x13/0x20
> [ 46.617892] [<ffffffff8105bd0b>] do_notify_parent+0x1bb/0x260
> [ 46.617892] [<ffffffff81077e7a>] ? sched_move_task+0xaa/0x130
> [ 46.617892] [<ffffffff81050917>] do_exit+0x767/0xa40
> [ 46.617892] [<ffffffff81050c84>] do_group_exit+0x44/0xa0
> [ 46.617892] [<ffffffff81050cf7>] SyS_exit_group+0x17/0x20
> [ 46.617892] [<ffffffff8172cd12>] system_call_fastpath+0x16/0x1b
> [ 46.617892] kmemleak: Kernel memory leak detector disabled
> [ 46.617892] kmemleak: Object 0xffff880016900000 (size 524288):
> [ 46.617892] kmemleak: comm "swapper/0", pid 0, jiffies 4294667296
> [ 46.617892] kmemleak: min_count = 0
> [ 46.617892] kmemleak: count = 0
> [ 46.617892] kmemleak: flags = 0x1
> [ 46.617892] kmemleak: checksum = 0
> [ 46.617892] kmemleak: backtrace:
> [ 46.617892] [<ffffffff81d0a7f0>] log_early+0x63/0x77
> [ 46.617892] [<ffffffff8171d31b>] kmemleak_alloc+0x4b/0x50
> [ 46.617892] [<ffffffff81720e4f>] init_section_page_cgroup+0x7f/0xf5
> [ 46.617892] [<ffffffff81d0a6f0>] page_cgroup_init+0xc5/0xd0
> [ 46.617892] [<ffffffff81ce4ed9>] start_kernel+0x333/0x408
> [ 46.617892] [<ffffffff81ce45b2>] x86_64_start_reservations+0x2a/0x2c
> [ 46.617892] [<ffffffff81ce46a9>] x86_64_start_kernel+0xf5/0xfc
> [ 46.617892] [<ffffffffffffffff>] 0xffffffffffffffff
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
And sorry, I should have noticed that when reviewing the original patch
which added kmemleak_alloc.
I think this is worth going into stable. The risk is marginal and
somebody might be relying on kmemleak even on older kernels when
debugging a bug during memory hotplug.
Thanks!
> ---
> mm/page_cgroup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 3708264..5331c2b 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -171,6 +171,7 @@ static void free_page_cgroup(void *addr)
> sizeof(struct page_cgroup) * PAGES_PER_SECTION;
>
> BUG_ON(PageReserved(page));
> + kmemleak_free(addr);
> free_pages_exact(addr, table_size);
> }
> }
> --
> 1.8.4
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: Wang Nan <wangnan0@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Steven Rostedt <rostedt@goodmis.org>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Li Zefan <lizefan@huawei.com>
Subject: Re: [PATCH] cgroup/kmemleak: add kmemleak_free() for cgroup deallocations.
Date: Mon, 22 Sep 2014 15:48:27 +0200 [thread overview]
Message-ID: <20140922134827.GD336@dhcp22.suse.cz> (raw)
In-Reply-To: <1411004285-42101-1-git-send-email-wangnan0@huawei.com>
On Thu 18-09-14 09:38:05, Wang Nan wrote:
> Commit ff7ee93f4 introduces kmemleak_alloc() for alloc_page_cgroup(),
> but corresponding kmemleak_free() is missing, which makes kmemleak be
> wrongly disabled after memory offlining. Log is pasted at the end of
> this commit message.
>
> This patch add kmemleak_free() into free_page_cgroup(). During page
> offlining, this patch removes corresponding entries in kmemleak rbtree.
> After that, the freed memory can be allocated again by other subsystems
> without killing kmemleak.
>
> bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak
> [ 45.537934] Offlined Pages 32768
> [ 46.617892] kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing)
> [ 46.617892] CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
> [ 46.617892] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 46.617892] ffff880016823d10 ffff880018bdfc38 ffffffff81725d2c ffff88001780e950
> [ 46.617892] ffff880016969000 ffff880018bdfc88 ffffffff8117a9e6 ffff880018bdfc78
> [ 46.617892] 0000000000000096 ffff880017812800 ffffffff81c2eda0 ffff880016969000
> [ 46.617892] Call Trace:
> [ 46.617892] [<ffffffff81725d2c>] dump_stack+0x46/0x58
> [ 46.617892] [<ffffffff8117a9e6>] create_object+0x266/0x2c0
> [ 46.617892] [<ffffffff8171d2f6>] kmemleak_alloc+0x26/0x50
> [ 46.617892] [<ffffffff8116a3a3>] kmem_cache_alloc+0xd3/0x160
> [ 46.617892] [<ffffffff81058e59>] __sigqueue_alloc+0x49/0xd0
> [ 46.617892] [<ffffffff8105a41b>] __send_signal+0xcb/0x410
> [ 46.617892] [<ffffffff8105a7a5>] send_signal+0x45/0x90
> [ 46.617892] [<ffffffff8105a803>] __group_send_sig_info+0x13/0x20
> [ 46.617892] [<ffffffff8105bd0b>] do_notify_parent+0x1bb/0x260
> [ 46.617892] [<ffffffff81077e7a>] ? sched_move_task+0xaa/0x130
> [ 46.617892] [<ffffffff81050917>] do_exit+0x767/0xa40
> [ 46.617892] [<ffffffff81050c84>] do_group_exit+0x44/0xa0
> [ 46.617892] [<ffffffff81050cf7>] SyS_exit_group+0x17/0x20
> [ 46.617892] [<ffffffff8172cd12>] system_call_fastpath+0x16/0x1b
> [ 46.617892] kmemleak: Kernel memory leak detector disabled
> [ 46.617892] kmemleak: Object 0xffff880016900000 (size 524288):
> [ 46.617892] kmemleak: comm "swapper/0", pid 0, jiffies 4294667296
> [ 46.617892] kmemleak: min_count = 0
> [ 46.617892] kmemleak: count = 0
> [ 46.617892] kmemleak: flags = 0x1
> [ 46.617892] kmemleak: checksum = 0
> [ 46.617892] kmemleak: backtrace:
> [ 46.617892] [<ffffffff81d0a7f0>] log_early+0x63/0x77
> [ 46.617892] [<ffffffff8171d31b>] kmemleak_alloc+0x4b/0x50
> [ 46.617892] [<ffffffff81720e4f>] init_section_page_cgroup+0x7f/0xf5
> [ 46.617892] [<ffffffff81d0a6f0>] page_cgroup_init+0xc5/0xd0
> [ 46.617892] [<ffffffff81ce4ed9>] start_kernel+0x333/0x408
> [ 46.617892] [<ffffffff81ce45b2>] x86_64_start_reservations+0x2a/0x2c
> [ 46.617892] [<ffffffff81ce46a9>] x86_64_start_kernel+0xf5/0xfc
> [ 46.617892] [<ffffffffffffffff>] 0xffffffffffffffff
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
And sorry, I should have noticed that when reviewing the original patch
which added kmemleak_alloc.
I think this is worth going into stable. The risk is marginal and
somebody might be relying on kmemleak even on older kernels when
debugging a bug during memory hotplug.
Thanks!
> ---
> mm/page_cgroup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 3708264..5331c2b 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -171,6 +171,7 @@ static void free_page_cgroup(void *addr)
> sizeof(struct page_cgroup) * PAGES_PER_SECTION;
>
> BUG_ON(PageReserved(page));
> + kmemleak_free(addr);
> free_pages_exact(addr, table_size);
> }
> }
> --
> 1.8.4
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2014-09-22 13:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 1:38 [PATCH] cgroup/kmemleak: add kmemleak_free() for cgroup deallocations Wang Nan
2014-09-18 1:38 ` Wang Nan
2014-09-18 14:16 ` Johannes Weiner
2014-09-18 14:16 ` Johannes Weiner
2014-09-18 15:16 ` Steven Rostedt
2014-09-18 15:16 ` Steven Rostedt
[not found] ` <1411004285-42101-1-git-send-email-wangnan0-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-09-22 13:48 ` Michal Hocko [this message]
2014-09-22 13:48 ` Michal Hocko
2014-09-22 13:48 ` Michal Hocko
2014-10-14 11:49 ` Wang Nan
2014-10-14 11:49 ` Wang Nan
2014-10-14 11:49 ` Wang Nan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140922134827.GD336@dhcp22.suse.cz \
--to=mhocko-alswssmvlrq@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
--cc=wangnan0-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.