On Sat, Aug 25, 2012 at 06:16:05PM +0100, Al Viro wrote: > On Thu, Aug 23, 2012 at 02:43:24PM +0400, Cyrill Gorcunov wrote: > > This patch prepares the ground for further extension of > > /proc/pid/fd[info] handling code by moving fdinfo handling > > code into fs/proc/fd.c. > > > > I think such move makes both fs/proc/base.c and fs/proc/fd.c > > easier to read. > > BTW, looking at the other stuff in fs/proc/base.c, why the hell is > struct file * grabbed in proc_map_files_readdir()? All we do with > it is passing it to proc_fill_cache(), which passes it to > proc_map_files_instantiate(), which looks at two sodding bits > in file->f_mode. Then we go and fput() all those struct file > references we'd been putting into the array... What for? Another thing: f_flags = fd_file->f_flags & ~O_CLOEXEC; in there is really wrong; we shouldn't leak that bit into ->f_flags at all (which is properly fixed in fs/open.c). Close-on-exec is a property of descriptor, not of file... tid_fd_revalidate(): these dances with get_files_struct()/put_files_struct() are pointless. We really only need "is it opened" + f_mode if it is. Extracting that information is cheap enough to have it done right under task_lock() (see what get_files_struct() is doing); no need to mess with files_struct refcount, etc. proc_fd_link() and seq_fd_open(): ditto. As the matter of fact, the only place in there where get_files_struct() is warranted is proc_readfd_common(). intantiate callback: sodding atrocity; as the absolute minimum it should lose its "dir" argument. dentry->d_parent->d_inode is stable (we are holding ->i_mutex on parent in all callers) and it's equal to dir in all cases. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
