Mark Kettenis wrote:
> > > The documentation may have been wrong for some time on some archs, it
> > > feels like making PT_WRITE_D and PT_WRITE_I equivalent was deemed
> > > useful at one point. Given that Free and NetBSD document the same
> > > guarantee, I personally don't feel comfortable
> From: "Ted Unangst"
> Date: Tue, 31 May 2016 13:57:04 -0400
>
> Jeremie Courreges-Anglas wrote:
> > >>
> > >> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
> > >> since rev. 1.1, I doubt that such an optimization is a good idea.
> > >
> > > A clear
Jeremie Courreges-Anglas wrote:
> >>
> >> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent
> >> since rev. 1.1, I doubt that such an optimization is a good idea.
> >
> > A clear case where the documentation is wrong.
>
>
> The documentation may have been wrong for some time
Mark Kettenis writes:
>> From: Jeremie Courreges-Anglas
>> Date: Mon, 30 May 2016 19:30:27 +0200
>>
>> Mark Kettenis writes:
>>
>> > Mathieu - schreef op 2016-05-28 13:05:
>> >> Martin Natano wrote:
>> >>> The diff reads fine
> From: Jeremie Courreges-Anglas
> Date: Mon, 30 May 2016 19:30:27 +0200
>
> Mark Kettenis writes:
>
> > Mathieu - schreef op 2016-05-28 13:05:
> >> Martin Natano wrote:
> >>> The diff reads fine to me, however it is incomplete. There are some
> >>>
Mark Kettenis writes:
> Mathieu - schreef op 2016-05-28 13:05:
>> Martin Natano wrote:
>>> The diff reads fine to me, however it is incomplete. There are some
>>> callers of process_domem() in arch/. They will need to be changed too.
>>> req seems to be in sync with
Mark Kettenis wrote:
> The thing you guys are missing is that on some architectures making changes
> to instructions (PT_WRITE_I) requires some additional operations to
> guarantee that the CPU actually sees those updated instructions. Typically
> this is the case on architectures with separate
Mathieu - schreef op 2016-05-28 13:05:
Martin Natano wrote:
The diff reads fine to me, however it is incomplete. There are some
callers of process_domem() in arch/. They will need to be changed too.
req seems to be in sync with uio_rw in all the cases, so just removing
the last argument should
Mathieu - writes:
> Martin Natano wrote:
>> The diff reads fine to me, however it is incomplete. There are some
>> callers of process_domem() in arch/. They will need to be changed too.
>> req seems to be in sync with uio_rw in all the cases, so just removing
>> the last
Martin Natano wrote:
> The diff reads fine to me, however it is incomplete. There are some
> callers of process_domem() in arch/. They will need to be changed too.
> req seems to be in sync with uio_rw in all the cases, so just removing
> the last argument should do it.
>
Thanks for the
On Fri, May 27, 2016 at 10:15:39PM +0200, Jeremie Courreges-Anglas wrote:
> Mathieu - writes:
>
> > Hello everyone,
> >
> > While playing a bit with ptrace to do some debugging I stumbled upon
> > something that looks like a bug.
> > While trying to write to the ptrace'd
Mathieu - writes:
> Hello everyone,
>
> While playing a bit with ptrace to do some debugging I stumbled upon
> something that looks like a bug.
> While trying to write to the ptrace'd process using PT_IO in combinaison
> with PIOD_WRITE_D I kept getting EFAULTs.
> PIOD_READ_D
12 matches
Mail list logo