proc_readfd calls fcheck_files() without taking read_lock() for the
files_struct which could end up in race with expand_fd_array(). The patch
below puts the read_lock to avoid that. I am not very sure if this is already
protected by some other means and read_lock is not needed.
Please comment.
Thank you,
Maneesh
-- Maneesh Soni IBM Linux Technology Center, IBM India Software Lab, Bangalore. Phone: +91-80-5262355 Extn. 3999 email: maneesh@in.ibm.com http://lse.sourceforge.net/locking/rcupdate.htmldiff -urN linux-2.4.14-pre8-orig/fs/proc/base.c linux-2.4.14pre8/fs/proc/base.c --- linux-2.4.14-pre8-orig/fs/proc/base.c Tue Nov 6 10:13:27 2001 +++ linux-2.4.14pre8/fs/proc/base.c Tue Nov 6 10:02:19 2001 @@ -553,6 +553,7 @@ task_unlock(p); if (!files) goto out; + read_lock(&files->file_lock); for (fd = filp->f_pos-2; fd < files->max_fds; fd++, filp->f_pos++) { @@ -561,6 +562,7 @@ if (!fcheck_files(files, fd)) continue; + read_unlock(&files->file_lock); j = NUMBUF; i = fd; do { @@ -571,8 +573,11 @@ ino = fake_ino(pid, PROC_PID_FD_DIR + fd); if (filldir(dirent, buf+j, NUMBUF-j, fd+2, ino, DT_LNK) < 0) - break; + goto done; + read_lock(&files->file_lock); } + read_unlock(&files->file_lock); +done: put_files_struct(files); } out: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/