mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Erez Zadok <ezk@cs.sunysb.edu>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@ftp.linux.org.uk, hch@infradead.org,
	Erez Zadok <ezk@cs.sunysb.edu>
Subject: [PATCH 02/12] Unionfs: prevent races in unionfs_fault
Date: Fri, 25 Apr 2008 18:18:58 -0400	[thread overview]
Message-ID: <12091619491117-git-send-email-ezk@cs.sunysb.edu> (raw)
In-Reply-To: <12091619483888-git-send-email-ezk@cs.sunysb.edu>

vm_ops->fault may be called in parallel.  Because we have to resort to
temporarily changing the vma->vm_file to point to the lower file, a
concurrent invocation of unionfs_fault could see a different value.  In this
workaround, we keep a different copy of the vma structure in our stack, so
we never expose a different value of the vma->vm_file called to us, even
temporarily.  A better fix (already tested) would be to change the calling
semantics of ->fault to take an explicit file pointer.

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
---
 fs/unionfs/mmap.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
index 07db5b0..febde7c 100644
--- a/fs/unionfs/mmap.c
+++ b/fs/unionfs/mmap.c
@@ -40,23 +40,28 @@ static int unionfs_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 	int err;
 	struct file *file, *lower_file;
 	struct vm_operations_struct *lower_vm_ops;
+	struct vm_area_struct lower_vma;
 
 	BUG_ON(!vma);
-	file = vma->vm_file;
+	memcpy(&lower_vma, vma, sizeof(struct vm_area_struct));
+	file = lower_vma.vm_file;
 	lower_vm_ops = UNIONFS_F(file)->lower_vm_ops;
 	BUG_ON(!lower_vm_ops);
 
 	lower_file = unionfs_lower_file(file);
 	BUG_ON(!lower_file);
 	/*
-	 * XXX: we set the vm_file to the lower_file, before calling the
-	 * lower ->fault op, then we restore the vm_file back to the upper
-	 * file.  Need to change the ->fault prototype to take an explicit
-	 * struct file, and fix all users accordingly.
+	 * XXX: vm_ops->fault may be called in parallel.  Because we have to
+	 * resort to temporarily changing the vma->vm_file to point to the
+	 * lower file, a concurrent invocation of unionfs_fault could see a
+	 * different value.  In this workaround, we keep a different copy of
+	 * the vma structure in our stack, so we never expose a different
+	 * value of the vma->vm_file called to us, even temporarily.  A
+	 * better fix would be to change the calling semantics of ->fault to
+	 * take an explicit file pointer.
 	 */
-	vma->vm_file = lower_file;
-	err = lower_vm_ops->fault(vma, vmf);
-	vma->vm_file = file;
+	lower_vma.vm_file = lower_file;
+	err = lower_vm_ops->fault(&lower_vma, vmf);
 	return err;
 }
 
-- 
1.5.2.2


  parent reply	other threads:[~2008-04-25 22:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-25 22:18 [GIT PULL -mm] 00/12 Unionfs updates/fixes/cleanups Erez Zadok
2008-04-25 22:18 ` [PATCH 01/12] Unionfs: minor code cleanups Erez Zadok
2008-04-25 22:18 ` Erez Zadok [this message]
2008-04-25 22:18 ` [PATCH 03/12] Unionfs: copy lower times in fsync/fasync only when needed Erez Zadok
2008-04-25 22:19 ` [PATCH 04/12] Unionfs: lock inode around calls to notify_change() Erez Zadok
2008-04-25 22:19 ` [PATCH 05/12] Unionfs: stop as soon as first writeable branch is found Erez Zadok
2008-04-25 22:19 ` [PATCH 06/12] Unionfs: don't dereference dentry without lower branches in d_release Erez Zadok
2008-04-25 22:19 ` [PATCH 07/12] Unionfs: set append offset correctly for copied-up files Erez Zadok
2008-04-25 22:19 ` [PATCH 08/12] Unionfs: copyup only if file is being written to Erez Zadok
2008-04-25 22:19 ` [PATCH 09/12] Unionfs: reorganize file_revalidate for un/locking callers Erez Zadok
2008-04-25 22:19 ` [PATCH 10/12] Unionfs: maintain one-open-file invariant for non-directories Erez Zadok
2008-04-25 22:19 ` [PATCH 11/12] Unionfs: set lower file to NULL in file_release Erez Zadok
2008-04-25 22:19 ` [PATCH 12/12] Unionfs: lock parent dentry branch config in write Erez Zadok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12091619491117-git-send-email-ezk@cs.sunysb.edu \
    --to=ezk@cs.sunysb.edu \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®