From: Dipankar Sarma <dipankar@in.ibm.com>
Update files documentation to mention the need for reloading fdtable pointer
if ->file_lock is dropped.
Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
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().
+
_