> I've been having a problem in recent kernels (1.3.30-32, don't know about
> older ones) with the process /fd entries in /proc. All the fd's show
> up in ls, but they can't be written to or read from. Bash gives "no
> such file or directory"
>
> I tracked down where the error actually occurs. It's in file
> fs/proc/link.c in the function proc_fd_dupf. The error comes from
> the "if (fd>=NR_OPEN) return -ENOENT /* should never happen */"
> statement. The file descriptor comparison loop is failing. I don't
> know exactly how this is supposed to work, so I don't know _why_ this
> loop fails. Could someone take a look at this?
The problem is that the function do_open() was reordered in a more sane
way. proc_fd_dupf() contains a hack which relies on the fact that
incomplete fds are exported, however several kernels ago, do_open() was
modified such that fds are not put into the file table until
file->f_op->open() is called. This breaks the proc_fd_dupf() hack, which
used to search through the file table until it found the file which is
being opened, and then set that file equal to the fd which is being
catted (current->files->fd[fd]=new_f; in the code).
Producing the same functionality that /proc/PID/fd/* used to have without
using this hack is slightly tricky, as proc_fd_dupf() doesn't have access
to the pointer which points to the file being opened. It would be simple
enough to make /proc/PID/fd/* have f_ops which simply call the f_ops of
the fds the user is after...
Please -- no one release a patch which modifies fs/open.c -- do_open()
was changed for a -very- good reason.
-Nat