public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@linuxhacker.ru>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org
Cc: Paul Cassella <cassella@cray.com>, Patrick Farrell <paf@cray.com>,
	Oleg Drokin <oleg.drokin@intel.com>
Subject: [PATCH 03/10] staging/lustre/llite: Make sure ft_flags is valid
Date: Fri, 15 Aug 2014 12:48:08 -0400	[thread overview]
Message-ID: <1408121295-29115-4-git-send-email-green@linuxhacker.ru> (raw)
In-Reply-To: <1408121295-29115-1-git-send-email-green@linuxhacker.ru>

From: Paul Cassella <cassella@cray.com>

In ll_fault0, the 'fault' struct is mostly cleared before the call to
cl_io_loop, but ft_flags is not reset. It is ordinarily set by
the call to filemap_fault in vvp_io_kernel_fault, but if Lustre
returns before calling filemap_fault, it still has the old value of
ft_flags.

ll_fault0 will then consume the ft_flags field. If it has the
VM_FAULT_RETRY bit set, it will be used as ll_fault0() and
ll_fault()'s return value.

This is a problem when VM_FAULT_RETRY is in ft_flags:
When fault/filemap_fault return with that flag set, they have already
released the mmap semaphore, and do_page_fault does not need to
release it.
Incorrectly returning this flag from ll_fault means mmap_sem
is not upped in the kernel's do_page_fault().

In addition to clearing ft_flags, this patch does not use it unless
it is valid.  It's potentially misleading to return ft_flags in
"fault_ret" if ft_flags has not been set by filemap_fault.

This adds clarity, but does not change the current behavior:
When not valid, ft_flags is replaced by fault_ret, which is zero,
as is ft_flags when not set by filemap_fault.

Signed-off-by: Patrick Farrell <paf@cray.com>
Reviewed-on: http://review.whamcloud.com/10956
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5291
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
---
 drivers/staging/lustre/lustre/llite/llite_internal.h | 4 ++++
 drivers/staging/lustre/lustre/llite/llite_mmap.c     | 8 +++++++-
 drivers/staging/lustre/lustre/llite/vvp_io.c         | 1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 634ffa6..684405e 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -894,6 +894,10 @@ struct vvp_io {
 				 * fault API used bitflags for return code.
 				 */
 				unsigned int    ft_flags;
+				/**
+				 * check that flags are from filemap_fault
+				 */
+				bool		ft_flags_valid;
 			} fault;
 		} fault;
 	} u;
diff --git a/drivers/staging/lustre/lustre/llite/llite_mmap.c b/drivers/staging/lustre/lustre/llite/llite_mmap.c
index 7dae610..5916648 100644
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -310,10 +310,16 @@ static int ll_fault0(struct vm_area_struct *vma, struct vm_fault *vmf)
 		vio->u.fault.ft_vma       = vma;
 		vio->u.fault.ft_vmpage    = NULL;
 		vio->u.fault.fault.ft_vmf = vmf;
+		vio->u.fault.fault.ft_flags = 0;
+		vio->u.fault.fault.ft_flags_valid = 0;
 
 		result = cl_io_loop(env, io);
 
-		fault_ret = vio->u.fault.fault.ft_flags;
+		/* ft_flags are only valid if we reached
+		 * the call to filemap_fault */
+		if (vio->u.fault.fault.ft_flags_valid)
+			fault_ret = vio->u.fault.fault.ft_flags;
+
 		vmpage = vio->u.fault.ft_vmpage;
 		if (result != 0 && vmpage != NULL) {
 			page_cache_release(vmpage);
diff --git a/drivers/staging/lustre/lustre/llite/vvp_io.c b/drivers/staging/lustre/lustre/llite/vvp_io.c
index a4117d6..fd24874 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_io.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_io.c
@@ -615,6 +615,7 @@ static int vvp_io_kernel_fault(struct vvp_fault_io *cfio)
 	struct vm_fault *vmf = cfio->fault.ft_vmf;
 
 	cfio->fault.ft_flags = filemap_fault(cfio->ft_vma, vmf);
+	cfio->fault.ft_flags_valid = 1;
 
 	if (vmf->page) {
 		CDEBUG(D_PAGE,
-- 
1.9.3


  parent reply	other threads:[~2014-08-15 16:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-15 16:48 [PATCH 00/10] Catchup lustre fixes Oleg Drokin
2014-08-15 16:48 ` [PATCH 01/10] staging/lustre/llite: check for integer overflow in hsm user request Oleg Drokin
2014-08-15 16:48 ` [PATCH 02/10] staging/lustre/mdc: cleanup intent if mdc_finish_enqueue() fails Oleg Drokin
2014-08-15 16:48 ` Oleg Drokin [this message]
2014-08-15 16:48 ` [PATCH 04/10] staging/lustre/ldlm: drop redundant ibits lock interoperability check Oleg Drokin
2014-08-15 16:48 ` [PATCH 05/10] staging/lustre/clio: reorder initialization in cl_req_alloc() Oleg Drokin
2014-08-15 16:48 ` [PATCH 06/10] staging/lustre/llite: hold inode mutex around ll_setattr_raw() Oleg Drokin
2014-08-15 16:48 ` [PATCH 07/10] staging/lustre/llite: optimize ll_fid2path() Oleg Drokin
2014-08-15 16:48 ` [PATCH 08/10] staging/lustre/llite: Fix integer overflow in ll_fid2path Oleg Drokin
2014-08-15 16:48 ` [PATCH 09/10] lustre: Add MAINTAINERS entry Oleg Drokin
2014-08-17 16:37   ` Greg Kroah-Hartman
2014-08-17 16:47     ` Oleg Drokin
2014-08-18 14:21       ` Dan Carpenter
2014-08-30 18:51       ` Greg Kroah-Hartman
2014-08-15 16:48 ` [PATCH 10/10] lustre: Add some basic documentation Oleg Drokin
2014-08-17 16:37   ` Greg Kroah-Hartman
2014-08-17 16:49     ` Oleg Drokin
2014-08-17 16:53       ` Greg Kroah-Hartman

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=1408121295-29115-4-git-send-email-green@linuxhacker.ru \
    --to=green@linuxhacker.ru \
    --cc=cassella@cray.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg.drokin@intel.com \
    --cc=paf@cray.com \
    /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