mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ying Han <yinghan@google.com>
To: Valdis.Kletnieks@vt.edu
Cc: Andrew Morton <akpm@linux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, Mike Waychison <mikew@google.com>
Subject: Re: 2.6.29 -mm merge plans
Date: Wed, 7 Jan 2009 20:18:34 -0800	[thread overview]
Message-ID: <604427e00901072018o42ff0627yb5282f2a81a13c65@mail.gmail.com> (raw)
In-Reply-To: <6991.1231194895@turing-police.cc.vt.edu>

Hi Valdis:
     Please try this fix and i tested on ubunbu8.10 with xmms and it helps.

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9e268b6..f4bbd9b 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -593,6 +593,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigne
 	unsigned long flags;
 	int sig;
 #endif
+	unsigned int retry_flag = FAULT_FLAG_RETRY;

 	tsk = current;
 	mm = tsk->mm;
@@ -690,6 +691,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigne
 		down_read(&mm->mmap_sem);
 	}

+retry:
 	vma = find_vma(mm, address);
 	if (!vma)
 		goto bad_area;
@@ -716,6 +718,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigne
 good_area:
 	si_code = SEGV_ACCERR;
 	write = 0;
+	write |= retry_flag;
 	switch (error_code & (PF_PROT|PF_WRITE)) {
 	default:	/* 3: write, present */
 		/* fall through */
@@ -744,6 +747,21 @@ good_area:
 			goto do_sigbus;
 		BUG();
 	}
+
+	/*
+	 * Here we retry fault once and switch to synchronous mode. The
+	 * main reason is to prevent us from the cases of starvation.
+	 * The retry logic open a starvation hole in which case pages might
+	 * be removed or changed after the retry.
+	 */
+	if (fault & VM_FAULT_RETRY) {
+		if (write & FAULT_FLAG_RETRY) {
+			retry_flag &= ~FAULT_FLAG_RETRY;
+			goto retry;
+		}
+		BUG();
+	}
+
 	if (fault & VM_FAULT_MAJOR)
 		tsk->maj_flt++;
 	else
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 4a3d28c..be770f9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -144,6 +144,7 @@ extern pgprot_t protection_map[16];

 #define FAULT_FLAG_WRITE	0x01	/* Fault was a write access */
 #define FAULT_FLAG_NONLINEAR	0x02	/* Fault was via a nonlinear mapping */
+#define FAULT_FLAG_RETRY	0x04	/* Retry major fault */

 /*
  * This interface is used by x86 PAT code to identify a pfn mapping that is
@@ -707,6 +708,7 @@ static inline int page_mapped(struct page *page)

 #define VM_FAULT_MINOR	0 /* For backwards compat. Remove me quickly. */

+#define VM_FAULT_RETRY	0x0010
 #define VM_FAULT_OOM	0x0001
 #define VM_FAULT_SIGBUS	0x0002
 #define VM_FAULT_MAJOR	0x0004
diff --git a/mm/filemap.c b/mm/filemap.c
index 2f55a1e..aed5a3f 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -714,6 +714,58 @@ repeat:
 EXPORT_SYMBOL(find_lock_page);

 /**
+ * find_lock_page_retry - locate, pin and lock a pagecache page
+ * @mapping: the address_space to search
+ * @offset: the page index
+ * @vma: vma in which the fault was taken
+ * @ppage: zero if page not present, otherwise point to the page in pagecache
+ * @retry: 1 indicate caller tolerate a retry.
+ *
+ * If retry flag is on, and page is already locked by someone else, return
+ * a hint of retry.
+ *
+ * Return *ppage==NULL if page is not in pagecache. Otherwise return *ppage
+ * points to the page in the pagecache with ret=VM_FAULT_RETRY indicate a
+ * hint to caller for retry, or ret=0 which means page is succefully
+ * locked.
+ */
+unsigned find_lock_page_retry(struct address_space *mapping, pgoff_t offset,
+				struct vm_area_struct *vma, struct page **ppage,
+				int retry)
+{
+	unsigned int ret = 0;
+	struct page *page;
+
+repeat:
+	page = find_get_page(mapping, offset);
+	if (page) {
+		if (!retry)
+			lock_page(page);
+		else {
+			if (!trylock_page(page)) {
+				struct mm_struct *mm = vma->vm_mm;
+
+				up_read(&mm->mmap_sem);
+				wait_on_page_locked(page);
+				down_read(&mm->mmap_sem);
+
+				page_cache_release(page);
+				return VM_FAULT_RETRY;
+			}
+		}
+		if (unlikely(page->mapping != mapping)) {
+			unlock_page(page);
+			page_cache_release(page);
+			goto repeat;
+		}
+		VM_BUG_ON(page->index != offset);
+	}
+	*ppage = page;
+	return ret;
+}
+EXPORT_SYMBOL(find_lock_page_retry);
+
+/**
  * find_or_create_page - locate or add a pagecache page
  * @mapping: the page's address_space
  * @index: the page's index into the mapping
@@ -1452,6 +1504,8 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_
 	pgoff_t size;
 	int did_readaround = 0;
 	int ret = 0;
+	int retry_flag = vmf->flags & FAULT_FLAG_RETRY;
+	int retry_ret;

 	size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
 	if (vmf->pgoff >= size)
@@ -1466,6 +1520,8 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_
 	 */
 retry_find:
 	page = find_lock_page(mapping, vmf->pgoff);
+
+retry_find_nopage:
 	/*
 	 * For sequential accesses, we use the generic readahead logic.
 	 */
@@ -1473,9 +1529,12 @@ retry_find:
 		if (!page) {
 			page_cache_sync_readahead(mapping, ra, file,
 							   vmf->pgoff, 1);
-			page = find_lock_page(mapping, vmf->pgoff);
+			retry_ret = find_lock_page_retry(mapping, vmf->pgoff,
+						vma, &page, retry_flag);
 			if (!page)
 				goto no_cached_page;
+			if (retry_ret == VM_FAULT_RETRY)
+				return retry_ret;
 		}
 		if (PageReadahead(page)) {
 			page_cache_async_readahead(mapping, ra, file, page,
@@ -1512,14 +1571,18 @@ retry_find:
 				start = vmf->pgoff - ra_pages / 2;
 			do_page_cache_readahead(mapping, file, start, ra_pages);
 		}
-		page = find_lock_page(mapping, vmf->pgoff);
+		retry_ret = find_lock_page_retry(mapping, vmf->pgoff,
+				vma, &page, retry_flag);
 		if (!page)
 			goto no_cached_page;
+		if (retry_ret == VM_FAULT_RETRY)
+			return retry_ret;
 	}

 	if (!did_readaround)
 		ra->mmap_miss--;

+retry_page_update:
 	/*
 	 * We have a locked page in the page cache, now we need to check
 	 * that it's up-to-date. If not, it is going to be due to an error.
@@ -1554,8 +1617,23 @@ no_cached_page:
 	 * In the unlikely event that someone removed it in the
 	 * meantime, we'll just come back here and read it again.
 	 */
-	if (error >= 0)
-		goto retry_find;
+	if (error >= 0) {
+		/*
+		 * If caller cannot tolerate a retry in the ->fault path
+		 * go back to check the page again.
+		 */
+		if (!retry_flag)
+			goto retry_find;
+
+		retry_ret = find_lock_page_retry(mapping, vmf->pgoff,
+					vma, &page, retry_flag);
+		if (!page)
+			goto retry_find_nopage;
+		else if (retry_ret == VM_FAULT_RETRY)
+			return retry_ret;
+		else
+			goto retry_page_update;
+	}

 	/*
 	 * An error return from page_cache_read can result if the
diff --git a/mm/memory.c b/mm/memory.c
index 3f8fa06..534ba1d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2572,6 +2572,13 @@ static int __do_fault(struct mm_struct *mm, struct vm_a
 	vmf.page = NULL;

 	ret = vma->vm_ops->fault(vma, &vmf);
+
+	/* page may be available, but we have to restart the process
+	 * because mmap_sem was dropped during the ->fault
+	 */
+	if (ret & VM_FAULT_RETRY)
+		return ret;
+
 	if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))
 		return ret;

@@ -2713,8 +2720,10 @@ static int do_linear_fault(struct mm_struct *mm, struct
 {
 	pgoff_t pgoff = (((address & PAGE_MASK)
 			- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
-	unsigned int flags = (write_access ? FAULT_FLAG_WRITE : 0);
+	int write = write_access & ~FAULT_FLAG_RETRY;
+	unsigned int flags = (write ? FAULT_FLAG_WRITE : 0);

+	flags |= (write_access & FAULT_FLAG_RETRY);
 	pte_unmap(page_table);
 	return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte);
 }


On Mon, Jan 5, 2009 at 2:34 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
> On Mon, 05 Jan 2009 01:07:26 PST, Andrew Morton said:
> > (cc's added)
> >
> > On Mon,  5 Jan 2009 18:00:33 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.
> fujitsu.com> wrote:
> >
> > > > #
> > > > page_fault-retry-with-nopage_retry.patch
> > > > page_fault-retry-with-nopage_retry-fix.patch
> > > > page_fault-retry-with-nopage_retry-fix-fix.patch
> > >
> > > I oppose this.
> > >
> > > Valdis.Kletnieks@vt.edu reported this patch has bug in
> > > "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
> > > thread.
> > >
> > > Nobody answer his question yet.
> >
> > OK, thanks.  I actually thought we'd fixed that?
>
> I'll check mmotm-0105 later tonight, I was still seeing the issue in -1230.

  reply	other threads:[~2009-01-08  4:18 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05  8:43 Andrew Morton
2009-01-05  9:00 ` KOSAKI Motohiro
2009-01-05  9:07   ` Andrew Morton
2009-01-05 22:31     ` Ying Han
2009-01-05 22:34     ` Valdis.Kletnieks
2009-01-08  4:18       ` Ying Han [this message]
2009-01-08  4:41         ` KOSAKI Motohiro
2009-01-08  7:57           ` Ying Han
2009-01-08  8:31             ` KOSAKI Motohiro
2009-01-11  4:18         ` Valdis.Kletnieks
2009-01-12  4:18           ` Ying Han
2009-01-06  5:27   ` Valdis.Kletnieks
2009-01-06  5:41     ` Nick Piggin
2009-01-05  9:02 ` Sam Ravnborg
2009-01-05  9:12   ` Andrew Morton
2009-01-05  9:17     ` David Miller
2009-01-05  9:21       ` Ingo Molnar
2009-01-05  9:39         ` Sam Ravnborg
2009-01-05 10:10           ` Ingo Molnar
2009-01-05 10:36             ` David Miller
2009-01-05 12:32               ` Ingo Molnar
2009-01-05 10:11     ` Ingo Molnar
2009-01-05 10:37       ` David Miller
2009-01-05  9:40 ` Ryusuke Konishi
2009-01-06 13:30   ` Pekka Enberg
2009-01-07  3:26     ` Ryusuke Konishi
2009-01-07  7:58       ` Pekka Enberg
2009-01-07 14:17       ` Chris Mason
2009-01-05 11:34 ` Al Viro
2009-01-05 11:40 ` Stephen Rothwell
2008-10-06  6:14   ` Greg Ungerer
2009-01-05 12:17   ` Ingo Molnar
2009-01-05 17:38   ` KOSAKI Motohiro
2009-01-05 12:28 ` Nick Piggin
2009-01-12 22:06   ` Andrew Morton
2009-01-15  6:37     ` Nick Piggin
2009-01-06  9:46 ` Pavel Machek
2009-01-06 22:33 ` Folkert van Heusden
2009-01-06 22:38   ` Alan Cox
2009-01-06 22:57 ` Christoph Hellwig
2009-01-06 23:08   ` Andrew Morton
2009-01-07  1:05     ` Nick Piggin
2009-01-06 23:08   ` Andrew Morton
2009-01-06 23:22     ` Christoph Hellwig
2009-01-07  2:16       ` Dave Chinner
2009-01-08 15:50         ` Dmitri Monakhov
2009-01-06 23:11   ` Andrew Morton
2009-01-06 23:24     ` Christoph Hellwig
2009-01-07  1:14       ` Nick Piggin
2009-01-07  1:38         ` Andi Kleen
2009-01-07  1:49           ` Nick Piggin
2009-01-07  2:57             ` Andi Kleen
2009-01-07  3:28               ` Nick Piggin
2009-01-08 13:24               ` Pavel Machek
2009-01-10 15:07                 ` Andi Kleen
2009-01-10 21:32                   ` sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] Pavel Machek
2009-01-10 22:12                     ` Andi Kleen
2009-01-10 22:26                       ` Pavel Machek
2009-01-08 13:22       ` 2.6.29 -mm merge plans Pavel Machek
2009-01-06 23:13   ` Andrew Morton
2009-01-06 23:24     ` Christoph Hellwig
2009-01-06 23:38       ` Andrew Morton
2009-01-07  2:06     ` Nick Piggin
2009-01-07  2:16       ` Andrew Morton
2009-01-07  3:05         ` Nick Piggin
2009-01-07  4:16           ` Andrew Morton
2009-01-06 23:15   ` Andrew Morton
2009-01-06 23:25     ` Christoph Hellwig
2009-01-07  7:54       ` Christoph Hellwig
2009-01-07  7:59         ` Andrew Morton
2009-01-07  8:10           ` Christoph Hellwig
2009-01-06 23:17   ` Andrew Morton
2009-01-06 23:19     ` Christoph Hellwig
2009-01-06 23:26       ` Warren Turkal
2009-01-06 23:26         ` Warren Turkal
2009-01-12  3:19         ` Roman Zippel
2009-01-06 23:27       ` Diego E. 'Flameeyes' Pettenò
2009-01-06 23:31         ` Christoph Hellwig
2009-01-06 23:49           ` Harvey Harrison
2009-01-07  0:09           ` Diego E. 'Flameeyes' Pettenò
2009-01-07  0:16             ` Harvey Harrison
2009-01-12  4:21         ` Roman Zippel
2009-01-06 23:19   ` Andrew Morton
2009-01-08 19:11     ` Rodolfo Giometti
2009-01-12 20:23       ` Christoph Hellwig
2009-01-13  9:49         ` Rodolfo Giometti
2009-01-12 20:22     ` Christoph Hellwig
2009-01-13  9:47       ` Rodolfo Giometti
2009-01-06 23:21   ` Andrew Morton
2009-01-06 23:28   ` Andrew Morton
2009-01-07  2:21     ` Nick Piggin
2009-01-08  8:39       ` Miklos Szeredi
2009-01-15  6:45         ` Nick Piggin
2009-01-07  0:01 ` Dan Williams

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=604427e00901072018o42ff0627yb5282f2a81a13c65@mail.gmail.com \
    --to=yinghan@google.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.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

all inboxes | Powered by JetHome®