On Wed, Oct 12, 2016 at 11:54:17AM -0400, CAI Qian wrote: > ----- Original Message ----- > > From: "Catalin Marinas" <catalin.mari...@arm.com> > > To: linux...@kvack.org > > Cc: linux-kernel@vger.kernel.org, "Andrew Morton" > > <a...@linux-foundation.org>, "Andy Lutomirski" <l...@kernel.org>, > > "CAI Qian" <caiq...@redhat.com> > > Sent: Wednesday, October 12, 2016 5:57:03 AM > > Subject: [PATCH] mm: kmemleak: Ensure that the task stack is not freed > > during scanning > > > > Commit 68f24b08ee89 ("sched/core: Free the stack early if > > CONFIG_THREAD_INFO_IN_TASK") may cause the task->stack to be freed > > during kmemleak_scan() execution, leading to either a NULL pointer > > fault (if task->stack is NULL) or kmemleak accessing already freed > > memory. This patch uses the new try_get_task_stack() API to ensure that > > the task stack is not freed during kmemleak stack scanning. > > > > Fixes: 68f24b08ee89 ("sched/core: Free the stack early if > > CONFIG_THREAD_INFO_IN_TASK") > > Cc: Andrew Morton <a...@linux-foundation.org> > > Cc: Andy Lutomirski <l...@kernel.org> > > Cc: CAI Qian <caiq...@redhat.com> > > Reported-by: CAI Qian <caiq...@redhat.com> > > Signed-off-by: Catalin Marinas <catalin.mari...@arm.com> > > Tested-by: CAI Qian <caiq...@redhat.com>
Thanks. BTW, I noticed a few false positives reported by kmemleak with the CONFIG_VMAP_STACK enabled caused by the fact that kmemleak requires two references (instead of one) to a vmalloc'ed object because of the vm_struct already containing the address. The cached_stack[] array only stores the vm_struct rather than the stack address, hence the kmemleak report. I'll work on a fix/annotation. -- Catalin