From: Michal Simek <michal.simek@petalogix.com>
To: Roland McGrath <roland@redhat.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: Wed, 01 Dec 2010 18:10:12 +0100 [thread overview]
Message-ID: <4CF68174.10301@petalogix.com> (raw)
In-Reply-To: <20101130233250.35603401C8@magilla.sf.frob.com>
Roland McGrath wrote:
> 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
Andrew any comment?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
WARNING: multiple messages have this Message-ID (diff)
From: Michal Simek <michal.simek@petalogix.com>
To: Roland McGrath <roland@redhat.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: Wed, 01 Dec 2010 18:10:12 +0100 [thread overview]
Message-ID: <4CF68174.10301@petalogix.com> (raw)
In-Reply-To: <20101130233250.35603401C8@magilla.sf.frob.com>
Roland McGrath wrote:
> 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
Andrew any comment?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
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>
next prev parent reply other threads:[~2010-12-01 17:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-26 12:31 Flushing whole page instead of work for ptrace Michal Simek
2010-11-26 12:31 ` Michal Simek
2010-11-30 11:07 ` Flushing whole page instead of exact address " Michal Simek
2010-11-30 11:07 ` Michal Simek
2010-11-30 23:32 ` Flushing whole page instead of work " Roland McGrath
2010-11-30 23:32 ` Roland McGrath
2010-12-01 17:10 ` Michal Simek [this message]
2010-12-01 17:10 ` Michal Simek
2010-12-01 17:57 ` David Miller
2010-12-01 17:57 ` David Miller
2010-12-03 15:00 ` Oleg Nesterov
2010-12-03 15:00 ` Oleg Nesterov
2010-12-03 16:28 ` Minchan Kim
2010-12-03 16:28 ` Minchan Kim
2010-12-03 17:07 ` Oleg Nesterov
2010-12-03 17:07 ` Oleg Nesterov
2010-12-04 14:57 ` Minchan Kim
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=4CF68174.10301@petalogix.com \
--to=michal.simek@petalogix.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=oleg@redhat.com \
--cc=roland@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.