Re: [PATCH 4/4] files: doc update

[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>
---


 Documentation/filesystems/files.txt |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+)

diff -puN Documentation/filesystems/files.txt~files-doc-update Documentation/filesystems/files.txt
--- linux-2.6.12-mm1-fix/Documentation/filesystems/files.txt~files-doc-update	2005-06-26 06:01:40.000000000 +0530
+++ linux-2.6.12-mm1-fix-dipankar/Documentation/filesystems/files.txt	2005-06-26 06:13:09.000000000 +0530
@@ -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().
+

_