Re: kmemleak splat on copy_process()

From	Andy Lutomirski <luto@amacapital.net>
Newsgroups	linux.kernel
Subject	Re: kmemleak splat on copy_process()
Date	2017-02-17 18:10 +0100
Message-ID	<tbUcH-76j-27@gated-at.bofh.it> (permalink)
References	<t6Thg-7ai-35@gated-at.bofh.it> <t7O5P-3el-5@gated-at.bofh.it> <t82Vc-4qF-11@gated-at.bofh.it> <t890B-gF-13@gated-at.bofh.it> <t8LSh-7Ue-13@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Wed, Feb 8, 2017 at 5:37 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Tue, Feb 07, 2017 at 09:03:43AM +0100, Michal Hocko wrote:
>> On Tue 07-02-17 02:37:02, Luis R. Rodriguez wrote:
>> > > From a quick check I do not see any leak there either.
>> >
>> > Then in that case what about:
>>
>> This just disables the kmemleak altogether which doesn't sound like a
>> good idea to me.
>
> Only for this case, but if that is also not desirable let us debug further.
> That or I think we could perhaps massage code to make it clearer to kmemleak
> things are good.
>

I'm not seeing the issue.  There should be a live pointer to stack at
all times, either in a local variable or in task->stack.  There's a
weird window in dup_task_struct in which we're stashing away
stack_vm_area, but stack itself should be okay, I think.  But maybe
there really is a race in which a kmemleak check right in the middle
of duplicating the task struct really can't see the stack pointer.

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: kmemleak splat on copy_process() Andy Lutomirski <luto@amacapital.net> - 2017-02-17 18:10 +0100
  Re: kmemleak splat on copy_process() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-02-17 18:30 +0100
    Re: kmemleak splat on copy_process() Andy Lutomirski <luto@amacapital.net> - 2017-02-17 20:40 +0100

csiph-web