Re: PTRACE_POKEDATA on PROT_NONE hangs kernel

Jeremy Fitzhardinge (jsgf@sirius.com)
Tue, 22 Sep 1998 12:48:29 -0700 (PDT)

On 22-Sep-98 Bill Hawes wrote:
> Michael Elizabeth Chastain wrote:
>
>> I have two ideas for a solution:
>>
>> #1 change the semantics of ptrace put_long. ptrace get_long has no
>> problem: check for _PAGE_PROTNONE and return 0 specifically for that
>> case (same semantics). ptrace put_long would check for _PAGE_PROTNONE
>> and return -EFAULT or a similar error. I don't like this very much
>> but it does make ptrace conform to the "PROTNONE is never mapped"
>> constraint.
>
> This seems reasonable to me. It doesn't matter what ptrace does to a
> PROTNONE page, as the child process won't be able to read it anyway.

Sure it can - after it uses mprotect() on it. One can easily imagine a GC
which hides pages from the mutator (user of the garbage collector) with
PROT_NONE, catching the SIGSEGV when they're touched to work out what the
mutator is doing. This is pretty common stuff, and it would be nice to be able
to debug it with ptrace().

I haven't been fully following this thread, but Michael's analysis imply that
the kernel assumes that a PROT_NONE page can never be accessed in its whole
history? Or does it just assume that it doesn't need to deal with this
particular user access by making the page really resident, and if it later
becomes PROT_READ/WRITE it will be faulted in/COW?

J

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/