From: David Miller <davem@davemloft.net>
To: michal.simek@petalogix.com
Cc: roland@redhat.com, oleg@redhat.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
john.williams@petalogix.com, edgar.iglesias@gmail.com
Subject: Re: Flushing whole page instead of work for ptrace
Date: Wed, 01 Dec 2010 09:57:23 -0800 (PST) [thread overview]
Message-ID: <20101201.095723.193718753.davem@davemloft.net> (raw)
In-Reply-To: <4CF68174.10301@petalogix.com>
From: Michal Simek <michal.simek@petalogix.com>
Date: Wed, 01 Dec 2010 18:10:12 +0100
> 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?
I don't have any comments on this specific patch but I will note
that special care is needed _after_ the access to kick out aliases
so that other future accesses to this page, which are oblivious to
what ptrace did, don't see illegal D-cache aliases.
Have a look at arch/sparc/kernel/ptrace_64.c:flush_ptrace_access().
Also, another issue is that much of the time ptrace() is just fetching
very small chunks (perhaps, a stack frame, or some variable in the
program image), so doing an entire page flush when we only copy
a few bytes out of the page is overkill.
Sparc64's flush_ptrace_access() tries to address this as well.
--
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:56 UTC|newest]
Thread overview: 9+ 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-30 11:07 ` Flushing whole page instead of exact address " Michal Simek
2010-11-30 23:32 ` Flushing whole page instead of work " Roland McGrath
2010-12-01 17:10 ` Michal Simek
2010-12-01 17:57 ` David Miller [this message]
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=20101201.095723.193718753.davem@davemloft.net \
--to=davem@davemloft.net \
--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 \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).