Hi,
According to Documentation/cachetlb.txt flush_dcache_page should also be
called when the kernel _is about_ to read from a page and user space
shared&writable mappings of this page potentially exist. I think
kernel/ptrace.c should be fixed on this issue.
I already posted this patch on the lkml a few months ago, but it got lost
I guess.
Where should I send ptrace patches to in the future? Anyone out there who
maintains the ptrace stuff?
Frank.
--- ptrace.c.2.5.56 2003-01-13 14:31:45.000000000 +0100
+++ ptrace.c 2003-01-13 14:32:43.000000000 +0100
@@ -182,11 +182,11 @@
maddr = kmap(page);
if (write) {
memcpy(maddr + offset, buf, bytes);
- flush_page_to_ram(page);
+ flush_dcache_page(page);
flush_icache_user_range(vma, page, addr, bytes);
} else {
+ flush_dcache_page(page);
memcpy(buf, maddr + offset, bytes);
- flush_page_to_ram(page);
}
kunmap(page);
page_cache_release(page);
On Tue January 14 2003 00:25, [email protected] wrote:
>
> Hi,
>
> According to Documentation/cachetlb.txt flush_dcache_page should also be
> called when the kernel _is about_ to read from a page and user space
> shared&writable mappings of this page potentially exist. I think
> kernel/ptrace.c should be fixed on this issue.
> I already posted this patch on the lkml a few months ago, but it got lost
> I guess.
> Where should I send ptrace patches to in the future? Anyone out there who
> maintains the ptrace stuff?
>
Actually, I've had this patch in the -mm patches since you sent it. But Dave
Miller says it's not quite right, and that we need additional infrastructure
to correctly solve the problem which you have identified.
So I've kept your patch in place as a reminder to bug Dave ;)