Messages in this thread | | | Date | Fri, 13 Nov 1998 13:27:38 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Bug 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/
| |