From: Dipankar Sarma Update files documentation to mention the need for reloading fdtable pointer if ->file_lock is dropped. Signed-off-by: Dipankar Sarma Signed-off-by: Andrew Morton --- Documentation/filesystems/files.txt | 20 ++++++++++++++++++++ 1 files changed, 20 insertions(+) diff -puN Documentation/filesystems/files.txt~files-files-locking-doc-update Documentation/filesystems/files.txt --- 25/Documentation/filesystems/files.txt~files-files-locking-doc-update 2005-06-24 22:52:36.000000000 -0700 +++ 25-akpm/Documentation/filesystems/files.txt 2005-06-24 22:52:36.000000000 -0700 @@ -101,3 +101,23 @@ the fdtable structure - API. If they are looked up lock-free, rcu_dereference() must be used. However it is advisable to use files_fdtable() and fcheck()/fcheck_files() which take care of these issues. + +7. While updating, the fdtable pointer must be looked up while + holding files->file_lock. If ->file_lock is dropped, then + another thread expand the files thereby creating a new + fdtable and making the earlier fdtable pointer stale. + For example : + + spin_lock(&files->file_lock); + fd = locate_fd(files, file, start); + if (fd >= 0) { + /* locate_fd() may have expanded fdtable, load the ptr */ + fdt = files_fdtable(files); + FD_SET(fd, fdt->open_fds); + FD_CLR(fd, fdt->close_on_exec); + spin_unlock(&files->file_lock); + ..... + + Since locate_fd() can drop ->file_lock (and reacquire ->file_lock), + the fdtable pointer (fdt) must be loaded after locate_fd(). + _