linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: michal.simek@petalogix.com
Cc: Oleg Nesterov <oleg@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, John Williams <john.williams@petalogix.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Subject: Re: Flushing whole page instead of work for ptrace
Date: Tue, 30 Nov 2010 15:32:50 -0800 (PST)	[thread overview]
Message-ID: <20101130233250.35603401C8@magilla.sf.frob.com> (raw)
In-Reply-To: Michal Simek's message of  Friday, 26 November 2010 13:31:42 +0100 <4CEFA8AE.2090804@petalogix.com>

This is a VM question more than a ptrace question.  
I can't give you any authoritative answers about the VM issues.

Documentation/cachetlb.txt says:

	Any time the kernel writes to a page cache page, _OR_
	the kernel is about to read from a page cache page and
	user space shared/writable mappings of this page potentially
	exist, this routine is called.

In your case, the kernel is only reading (write=0 passed to
access_process_vm and get_user_pages).  In normal situations,
the page in question will have only a private and read-only
mapping in user space.  So the call should not be required in
these cases--if the code can tell that's so.

Perhaps something like the following would be safe.
But you really need some VM folks to tell you for sure.

diff --git a/mm/memory.c b/mm/memory.c
index 02e48aa..2864ee7 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1484,7 +1484,8 @@ int __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
 				pages[i] = page;
 
 				flush_anon_page(vma, page, start);
-				flush_dcache_page(page);
+				if ((vm_flags & VM_WRITE) || (vma->vm_flags & VM_SHARED)
+					flush_dcache_page(page);
 			}
 			if (vmas)
 				vmas[i] = vma;


Thanks,
Roland

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2010-11-30 23:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-26 12:31 Michal Simek
2010-11-30 11:07 ` Flushing whole page instead of exact address " Michal Simek
2010-11-30 23:32 ` Roland McGrath [this message]
2010-12-01 17:10   ` Flushing whole page instead of work " Michal Simek
2010-12-01 17:57     ` David Miller
2010-12-03 15:00   ` Oleg Nesterov
2010-12-03 16:28     ` Minchan Kim
2010-12-03 17:07       ` Oleg Nesterov
2010-12-04 14:57         ` Minchan Kim

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=20101130233250.35603401C8@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=edgar.iglesias@gmail.com \
    --cc=john.williams@petalogix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=michal.simek@petalogix.com \
    --cc=oleg@redhat.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