lkml.org 
[lkml]   [1998]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectBug in find_task_by_pid()? (was Re: /proc/non-existent-pid/)
    Hi,

    This (in 2.1.128) is because find_task_by_pid() returns a valid task
    structure for a process that already exited. This lasts for a few seconds
    and then eventually disappears. If you put a printk() after the line
    p = find_task_by_pid(pid) in fs/proc/fd.c/proc_readfd() you will see it for
    yourself. So, either read_lock(&task_list) does not work or something
    is wrong with the way find_task_by_pid() manipulates the pid hashtable.

    Someone please narrow it down further.

    Regards,
    Tigran

    On Thu, 12 Nov 1998, Koblinger Egmont wrote:

    >
    > Hi folks!
    >
    > Several weeks ago I reported a bug. No answer came, and the bug is still
    > present in 2.1.127. :-( So I send the report again.
    >
    > It's possible that an entry remains in the proc fs after the command has
    > exited. It seems to me that it happens if we run an `ls -l' command in the
    > /proc/$pid/fd directory while the command runs. After command exits, `ls
    > /proc' does not write its pid, but /proc/$pid still exists.
    > See the log file at the end of the message.
    >
    > Two more questions about /proc/$pid/fd:
    > 1. Instead of 64, could the "correct" length of the symlinks be returned?
    > 2. When a file is deleted, the string "/tmp/x (deleted)" could rather be
    > "deleted:/tmp/x". This is because it's more similar to the pipe: and
    > socket: ones, and a normal file _can_ have the name "/tmp/x (deleted)"
    > so it cannot be told whether this really means a deleted file. On the
    > other hand, "deleted:/tmp/x" can not be the full name of a real file.
    > So it would be more simplier and more consequent to parse the
    > "deleted:/tmp/x" notation within a program.
    >
    > Bye
    > Egmont Koblinger
    > <egmont@math.bme.hu>
    >
    >
    > Here is the log file how I can invoke the bug:
    > egmont $ sleep 10 &
    > [1] 182
    > egmont $ ls -l /proc/182/fd
    > total 0
    > lrwx------ 1 egmont pupil 64 Oct 20 20:50 0 -> /dev/ttyp0
    > lrwx------ 1 egmont pupil 64 Oct 20 20:50 1 -> /dev/ttyp0
    > lrwx------ 1 egmont pupil 64 Oct 20 20:50 2 -> /dev/ttyp0
    > egmont $ ##### wait ten seconds
    > [1]+ Done sleep 10
    > egmont $ ls /proc | grep 182
    > egmont $ ls -l /proc/182
    > ls: /proc/182/exe: Permission denied
    > ls: /proc/182/root: Permission denied
    > ls: /proc/182/cwd: Permission denied
    > total 0
    > -r--r--r-- 1 root root 0 Oct 20 20:50 cmdline
    > -r--r--r-- 1 root root 0 Oct 20 20:50 cpu
    > lrwx------ 1 root root 0 Oct 20 20:50 cwd
    > -r-------- 1 root root 0 Oct 20 20:50 environ
    > lrwx------ 1 root root 0 Oct 20 20:50 exe
    > dr-x------ 2 egmont pupil 0 Oct 20 20:50 fd
    > pr--r--r-- 1 root root 0 Oct 20 20:50 maps
    > -rw------- 1 root root 0 Oct 20 20:50 mem
    > lrwx------ 1 root root 0 Oct 20 20:50 root
    > -r--r--r-- 1 root root 0 Oct 20 20:50 stat
    > -r--r--r-- 1 root root 0 Oct 20 20:50 statm
    > -r--r--r-- 1 root root 0 Oct 20 20:50 status
    > egmont $ ##### well, that's it
    >
    >
    >
    >
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.rutgers.edu
    > Please read the FAQ at http://www.tux.org/lkml/
    >


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.027 / U:300.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site