[lkml]   [2007]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Possible "struct pid" leak from tty_io.c
    "Catalin Marinas" <> writes:

    > Hi Eric,
    > I'm trying to track down a kmemleak report (on an ARM platform) which
    > seems to have appeared with commit
    > ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
    > TTY layer at all, is it possible that the above commit missed a
    > put_pid() call on some path?

    I won't arbitrarily rule a missing put_pid out. I have been know to
    goof up upon occasion.

    I just did a quick look to see what kmemleak is. A conservative
    tracing leak detector sounds interesting. Except for all of the list
    heads which lead to container_of calls I don't know of anything in the
    struct pid implementation that would be difficult for it to work with.
    Well that and there is some rcu access protection which can delay the
    free by a bit.

    > The /sbin/init application calls sys_clone() a few times but only one
    > leak is reported (see below). Looking at the reported pid object (at
    > 0xc7c14500), count is 2 and nr is 296 but no process with pid 296
    > exists any more.

    It could still be a valid session or a process group id.
    If you examine the struct pid you can test for this be examining all
    of the list heads it keeps. If there is something on any of the
    lists that would account a count of 1. How we have a count of 2
    I don't have enough information to guess.

    Core tty layer handling stops having an remembering pids when the
    session or process group exits so it is relatively safe from pid wrap
    around issues without my changes and should make the kind of thing you
    are reporting very unlikely in a correctly functioning system.

    In most any other layer we cache pids indefinitely and a situation
    where we have a pointer to a struct pid with a ref count of 1 long
    after the process goes away is expected. In this case it is better
    to hold a reference to a struct pid so we don't do the wrong thing
    when pid wrap around occurs then to hold a reference to an entire
    task_struct and lock that in place.

    I don't understand your situation enough to guess what is going wrong
    yet. Hopefully I have given you enough information to get started.

    > unreferenced object 0xc7c14500 (size 36):
    > comm "init", pid 245, jiffies 4294939289
    > backtrace:
    > [<c0070c18>] kmem_cache_alloc
    > [<c003a528>] alloc_pid
    > [<c0026468>] do_fork
    > [<c00153b0>] sys_clone
    > [<c0010f80>] ret_fast_syscall

    I think this is the path that all pid structures come from so
    unfortunately that doesn't help tracing this problem down.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-08 19:15    [W:0.022 / U:8.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site