[lkml]   [2005]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ptrace can't be transparent on readonly MAP_SHARED

On Thu, 15 Sep 2005, Andrea Arcangeli wrote:
> I'll try again: what is the point of still getting page faults on writes
> when the first read will contain the wrong data?

What's the point of having the page AT ALL if the data is wrong?

You are _still_ arguing that the "data" and the "page fault" are somehow
connected. They aren't.

If you think the data is wrong, then you are arguing against the COW. Yes,
the COW will make the data "wrong", but you can't escape that. That's what
a "write" by ptrace does.

Btw, that's true even if we didn't do the COW - the COW just makes it even
more so. But even without the COW, the ptrace has written data that the
process didn't expect, and the process didn't write.

Here's a big clue. A ptrace PTRACE_POKE-induced write WRITES DATA.

Afterwards, the data is different from what if would have been if the
ptrace hadn't written. It's "wrong". Tough titties. It's what ptrace does.
Live with it. If you don't want wrong data, don't use ptrace to write
wrong data.

However, you seem to confuse "write data" with "write data and make the
page writable".

And as long as you continue to mix the two, there's no point in talking
about it. They are different.

To recap: PTRACE_POKE _will_ write "wrong data" to the process. Part of it
directly (the actual data written), and part of it indirectly (the fact
that it has to break the COW connection in order to do the write). THAT IS

And it has _nothing_ to do with whether we fault afterwards or not.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.043 / U:4.640 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site