Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1583605 > unrolled thread

Re: kmemleak splat on copy_process()

Started byAndy Lutomirski <luto@amacapital.net>
First post2017-02-17 18:10 +0100
Last post2017-02-17 20:40 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  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

#1583605 — Re: kmemleak splat on copy_process()

FromAndy Lutomirski <luto@amacapital.net>
Date2017-02-17 18:10 +0100
SubjectRe: kmemleak splat on copy_process()
Message-ID<tbUcH-76j-27@gated-at.bofh.it>
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.

[toc] | [next] | [standalone]


#1583614

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2017-02-17 18:30 +0100
Message-ID<tbUw1-7dc-9@gated-at.bofh.it>
In reply to#1583605
On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> 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.

Funny, but it was actually using kmemleak how I can easily reproduce:

To reproduce the kmemleak splat:

echo clear >  /sys/kernel/debug/kmemleak
echo scan >  /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

Try that.

 Luis

[toc] | [prev] | [next] | [standalone]


#1583669

FromAndy Lutomirski <luto@amacapital.net>
Date2017-02-17 20:40 +0100
Message-ID<tbWxP-8rv-7@gated-at.bofh.it>
In reply to#1583614
On Fri, Feb 17, 2017 at 9:23 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> 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.
>
> Funny, but it was actually using kmemleak how I can easily reproduce:
>
> To reproduce the kmemleak splat:
>
> echo clear >  /sys/kernel/debug/kmemleak
> echo scan >  /sys/kernel/debug/kmemleak
> cat /sys/kernel/debug/kmemleak

Worked fine for me.  Maybe your config is special?

--Andy

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web