From: Andrew Morton <akpm@linux-foundation.org>
To: Ying Han <yinghan@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, mingo@elte.hu,
mikew@google.com, rientjes@google.com, rohitseth@google.com,
hugh@veritas.com, a.p.zijlstra@chello.nl, hpa@zytor.com,
edwintorok@gmail.com, lee.schermerhorn@hp.com, npiggin@suse.de
Subject: Re: [RFC v2][PATCH]page_fault retry with NOPAGE_RETRY
Date: Mon, 26 Jan 2009 15:52:46 -0800 [thread overview]
Message-ID: <20090126155246.2d7df309.akpm@linux-foundation.org> (raw)
In-Reply-To: <604427e00901261508n7967ea74m3deacd3213c86065@mail.gmail.com>
On Mon, 26 Jan 2009 15:08:48 -0800
Ying Han <yinghan@google.com> wrote:
> On Mon, Jan 26, 2009 at 11:37 AM, Andrew Morton
> <akpm@linux-foundation.org>wrote:
>
> > On Fri, 5 Dec 2008 11:40:19 -0800
> > Ying Han <yinghan@google.com> wrote:
> >
> > > --- a/arch/x86/mm/fault.c
> > > +++ b/arch/x86/mm/fault.c
> > > @@ -591,6 +591,7 @@ void __kprobes do_page_fault(struct pt_regs *regs,
> > unsigne
> > > #ifdef CONFIG_X86_64
> > > unsigned long flags;
> > > #endif
> > > + unsigned int retry_flag = FAULT_FLAG_RETRY;
> > >
> > > tsk = current;
> > > mm = tsk->mm;
> > > @@ -689,6 +690,7 @@ again:
> > > down_read(&mm->mmap_sem);
> > > }
> > >
> > > +retry:
> > > vma = find_vma(mm, address);
> > > if (!vma)
> > > goto bad_area;
> > > @@ -715,6 +717,7 @@ again:
> > > good_area:
> > > si_code = SEGV_ACCERR;
> > > write = 0;
> > > + write |= retry_flag;
> > > switch (error_code & (PF_PROT|PF_WRITE)) {
> > > default: /* 3: write, present */
> > > /* fall through */
> > > @@ -743,6 +746,15 @@ good_area:
> > > goto do_sigbus;
> > > BUG();
> > > }
> > > +
> > > + 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
> >
> > This code is mixing flags from the FAULT_FLAG_foor domain into local
> > variable `write'. But that's inappropriate because `write' is a
> > boolean, and in one of Ingo's trees, `write' gets bits other than bit 0
> > set, and it all generally ends up a mess.
> >
> > Can we not do that? I assume that a previous version of this patch
> > kept those things separated?
> >
> > Something like this, I think?
> >
> > diff -puN arch/x86/mm/fault.c~page_fault-retry-with-nopage_retry-fix
> > arch/x86/mm/fault.c
> > --- a/arch/x86/mm/fault.c~page_fault-retry-with-nopage_retry-fix
> > +++ a/arch/x86/mm/fault.c
> > @@ -799,7 +799,7 @@ void __kprobes do_page_fault(struct pt_r
> > struct vm_area_struct *vma;
> > int write;
> > int fault;
> > - unsigned int retry_flag = FAULT_FLAG_RETRY;
> > + int retry_flag = 1;
> >
> > tsk = current;
> > mm = tsk->mm;
> > @@ -951,6 +951,7 @@ good_area:
> > }
> >
> > write |= retry_flag;
> > +
> > /*
> > * If for any reason at all we couldn't handle the fault,
> > * make sure we exit gracefully rather than endlessly redo
> > @@ -969,8 +970,8 @@ good_area:
> > * be removed or changed after the retry.
> > */
> > if (fault & VM_FAULT_RETRY) {
> > - if (write & FAULT_FLAG_RETRY) {
> > - retry_flag &= ~FAULT_FLAG_RETRY;
> > + if (retry_flag) {
> > + retry_flag = 0;
> > goto retry;
> > }
> > BUG();
>
> with this change, 'write' still gets bits other than bit 0
> set in the case of 'write, not present' and the Ingo's problem remains, am i
> missing something here?
umm, yes. This?
--- a/arch/x86/mm/fault.c~page_fault-retry-with-nopage_retry-fix-fix
+++ a/arch/x86/mm/fault.c
@@ -950,8 +950,6 @@ good_area:
return;
}
- write |= retry_flag;
-
/*
* If for any reason at all we couldn't handle the fault,
* make sure we exit gracefully rather than endlessly redo
_
(I should just give up here - doing too many things at once)
> >
> >
> >
> > Question: why is this code passing `write==true' into handle_mm_fault()
> > in the retry case?
> > Here i am using unused bit of "write" to carry FAULT_FLAG_RETRY flag down
> > to the handle_mm_fault(). Meanwhile, "write" still have its read/write bit
> > set as it is before. It is true that 'write == true' in the retry patch, but
> > i did the correct interpretation in
>
>
>
> > static int do_linear_fault() {
> >
> 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);
> }
OK, this is horridly confusing. Is `write_access' a boolean, as its
name implies, or is it a bunch of flags?
If we're going to turn it into a bunch of flags then it should be
renamed! And callsites such as do_page_fault() should rename their
local variable `write' to something which accurately conveys the new
usage. And various code comments in mm/memory.c (which don't appear to
exist) should be updated.
I think that a good way to present this is as a preparatory patch:
"convert the fourth argument to handle_mm_fault() from a boolean to a
flags word". That would be a simple do-nothing patch which affects all
architectures and which ideally would break the build at any
unconverted code sites. (Change the argument order?)
What do you think?
next prev parent reply other threads:[~2009-01-26 23:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-05 19:40 [RFC v2][PATCH]page_fault retry with NOPAGE_RETRY Ying Han
2008-12-06 9:52 ` Török Edwin
2008-12-06 9:55 ` Török Edwin
2008-12-08 1:43 ` Ying Han
2008-12-09 17:57 ` Ying Han
2008-12-09 19:31 ` Andrew Morton
2009-01-26 19:37 ` Andrew Morton
[not found] ` <604427e00901261508n7967ea74m3deacd3213c86065@mail.gmail.com>
2009-01-26 23:52 ` Andrew Morton [this message]
2009-01-26 23:57 ` Ingo Molnar
2009-01-27 4:34 ` KOSAKI Motohiro
2009-03-31 22:00 ` Andrew Morton
2009-04-01 0:17 ` Ying Han
2009-04-03 8:22 ` [PATCH] vfs: fix find_lock_page_retry() return value parsing Wu Fengguang
2009-04-03 8:35 ` [PATCH v2] " Wu Fengguang
2009-04-03 8:55 ` [PATCH] vfs: reduce page fault retry code Wu Fengguang
2009-04-03 10:53 ` Wu Fengguang
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=20090126155246.2d7df309.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=edwintorok@gmail.com \
--cc=hpa@zytor.com \
--cc=hugh@veritas.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mikew@google.com \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=rientjes@google.com \
--cc=rohitseth@google.com \
--cc=yinghan@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