On Thu, Feb 15, 2007 at 08:01:20AM +, Jan Beulich wrote:
> Ack.
Great, thanks for your help.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
>>> Jeff Dike <[EMAIL PROTECTED]> 14.02.07 18:51 >>>
>On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote:
>> Actually, after a second round of thinking I believe there's still more to do
>> - your second patch missed fixing i386's do_trap() similarly to x86-64's
>> and, vice versa,
Jeff Dike [EMAIL PROTECTED] 14.02.07 18:51
On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote:
Actually, after a second round of thinking I believe there's still more to do
- your second patch missed fixing i386's do_trap() similarly to x86-64's
and, vice versa, x86-64's
On Thu, Feb 15, 2007 at 08:01:20AM +, Jan Beulich wrote:
Ack.
Great, thanks for your help.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote:
> Actually, after a second round of thinking I believe there's still more to do
> - your second patch missed fixing i386's do_trap() similarly to x86-64's
> and, vice versa, x86-64's do_general_protection() similarly to i386's.
Sigh,
On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote:
Actually, after a second round of thinking I believe there's still more to do
- your second patch missed fixing i386's do_trap() similarly to x86-64's
and, vice versa, x86-64's do_general_protection() similarly to i386's.
Sigh,
On Tuesday 13 February 2007 08:52, Jan Beulich wrote:
> >Yup. How does this patch look to you? We set error_code and trap_no
> >for userspace faults and kernel faults which call die(). We don't set
> >them for kernelspace faults which are fixed up.
>
> Actually, after a second round of
On Tuesday 13 February 2007 08:52, Jan Beulich wrote:
Yup. How does this patch look to you? We set error_code and trap_no
for userspace faults and kernel faults which call die(). We don't set
them for kernelspace faults which are fixed up.
Actually, after a second round of thinking I
>Yup. How does this patch look to you? We set error_code and trap_no
>for userspace faults and kernel faults which call die(). We don't set
>them for kernelspace faults which are fixed up.
Actually, after a second round of thinking I believe there's still more to do
- your second patch missed
>Yup. How does this patch look to you? We set error_code and trap_no
>for userspace faults and kernel faults which call die(). We don't set
>them for kernelspace faults which are fixed up.
That seems a reasonable approach.
Thanks, Jan
-
To unsubscribe from this list: send the line
On Mon, Feb 12, 2007 at 09:32:10AM +, Jan Beulich wrote:
> This breaks consumers of notify_die() relying on the proper trap number being
> passed, as the call to notify_die() from die() currently reads
> current->thread.trap_no.
Rats, good point.
> Also, you seem to leave other places where
>>> Andi Kleen <[EMAIL PROTECTED]> 10.02.07 12:50 >>>
>
>From: Jeff Dike <[EMAIL PROTECTED]>
>
>Kernel-mode traps on x86_64 can pollute the trap information for a previous
>userspace trap for which the signal has not yet been delivered to the
>process.
>
>do_trap and do_general_protection set
Andi Kleen [EMAIL PROTECTED] 10.02.07 12:50
From: Jeff Dike [EMAIL PROTECTED]
Kernel-mode traps on x86_64 can pollute the trap information for a previous
userspace trap for which the signal has not yet been delivered to the
process.
do_trap and do_general_protection set task-thread.error_code
On Mon, Feb 12, 2007 at 09:32:10AM +, Jan Beulich wrote:
This breaks consumers of notify_die() relying on the proper trap number being
passed, as the call to notify_die() from die() currently reads
current-thread.trap_no.
Rats, good point.
Also, you seem to leave other places where
Yup. How does this patch look to you? We set error_code and trap_no
for userspace faults and kernel faults which call die(). We don't set
them for kernelspace faults which are fixed up.
That seems a reasonable approach.
Thanks, Jan
-
To unsubscribe from this list: send the line unsubscribe
Yup. How does this patch look to you? We set error_code and trap_no
for userspace faults and kernel faults which call die(). We don't set
them for kernelspace faults which are fixed up.
Actually, after a second round of thinking I believe there's still more to do
- your second patch missed
16 matches
Mail list logo
