On 04/24, H. Peter Anvin wrote:
>
> On 04/24/2013 10:07 AM, Oleg Nesterov wrote:
> > DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
> > bits in the "unsigned long" data, make them long to ensure that
> > "&~" doesn't clear the upper bits.
> >
> > do_debug() and ptrace_write_dr7()
On 04/24, H. Peter Anvin wrote:
On 04/24/2013 10:07 AM, Oleg Nesterov wrote:
DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
bits in the unsigned long data, make them long to ensure that
~ doesn't clear the upper bits.
do_debug() and ptrace_write_dr7() which use
On 04/24/2013 04:31 PM, Frederic Weisbecker wrote:
>>
>> Now, DR6 is a bit special in that a bunch of the reserved bits are
>> hardwired to 1, not 0; I don't know offhand if that is true for bits
>> [63:32].
>
> Hmm, good point, could it be a problem given that we clear the
> reserved dr6 bits on
2013/4/25 H. Peter Anvin :
> On 04/24/2013 03:48 PM, Frederic Weisbecker wrote:
>> You told in an earlier email that intel manual says upper 32 bits of
>> dr6 are reserved.
>> In this case don't we need to expand the mask in 64 bits like is done
>> for DR_CONTROL_RESERVED?
>>
>
> Arguably this
On 04/24/2013 03:48 PM, Frederic Weisbecker wrote:
> 2013/4/24 Oleg Nesterov :
>> DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
>> bits in the "unsigned long" data, make them long to ensure that
>> "&~" doesn't clear the upper bits.
>>
>> do_debug() and ptrace_write_dr7() which
2013/4/24 Oleg Nesterov :
> DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
> bits in the "unsigned long" data, make them long to ensure that
> "&~" doesn't clear the upper bits.
>
> do_debug() and ptrace_write_dr7() which use DR*_RESERVED look
> safe, but probably it makes sense to
On 04/24/2013 10:07 AM, Oleg Nesterov wrote:
> DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
> bits in the "unsigned long" data, make them long to ensure that
> "&~" doesn't clear the upper bits.
>
> do_debug() and ptrace_write_dr7() which use DR*_RESERVED look
> safe, but
On 04/24/2013 10:07 AM, Oleg Nesterov wrote:
DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
bits in the unsigned long data, make them long to ensure that
~ doesn't clear the upper bits.
do_debug() and ptrace_write_dr7() which use DR*_RESERVED look
safe, but probably it makes
2013/4/24 Oleg Nesterov o...@redhat.com:
DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
bits in the unsigned long data, make them long to ensure that
~ doesn't clear the upper bits.
do_debug() and ptrace_write_dr7() which use DR*_RESERVED look
safe, but probably it makes
On 04/24/2013 03:48 PM, Frederic Weisbecker wrote:
2013/4/24 Oleg Nesterov o...@redhat.com:
DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the set
bits in the unsigned long data, make them long to ensure that
~ doesn't clear the upper bits.
do_debug() and ptrace_write_dr7() which use
2013/4/25 H. Peter Anvin h...@zytor.com:
On 04/24/2013 03:48 PM, Frederic Weisbecker wrote:
You told in an earlier email that intel manual says upper 32 bits of
dr6 are reserved.
In this case don't we need to expand the mask in 64 bits like is done
for DR_CONTROL_RESERVED?
Arguably this
On 04/24/2013 04:31 PM, Frederic Weisbecker wrote:
Now, DR6 is a bit special in that a bunch of the reserved bits are
hardwired to 1, not 0; I don't know offhand if that is true for bits
[63:32].
Hmm, good point, could it be a problem given that we clear the
reserved dr6 bits on do_trap()
12 matches
Mail list logo