[Xenomai] ipipe: Comment in __ipipe_handle_exception

[Xenomai] ipipe: Comment in __ipipe_handle_exception

[Jan Kiszka]

Hi Philippe,

in 2338107647 I found this:

@@ -383,6 +380,8 @@ int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
 			local_irq_disable();
 	}
 
+	/*
+	 * XXX: We don't trace page faults (yet?). */
 	if (vector == ex_do_page_fault)
 		cr2 = native_read_cr2();
 

What is the background? Any open issue?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] ipipe: Comment in __ipipe_handle_exception

[Philippe Gerum]

On 09/11/2014 10:39 AM, Jan Kiszka wrote:
> Hi Philippe,
> 
> in 2338107647 I found this:
> 
> @@ -383,6 +380,8 @@ int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
>  			local_irq_disable();
>  	}
>  
> +	/*
> +	 * XXX: We don't trace page faults (yet?). */
>  	if (vector == ex_do_page_fault)
>  		cr2 = native_read_cr2();
>  
> 
> What is the background? Any open issue?
> 

The current interposition we do via std_extable is not aware of trace_*
hooks in entry*.S, so we end up bypassing the trace encapsulation
entirely in __ipipe_handle_exception. Nothing bad, it just needs some
work to do this cleanly. This is for x86_64, ia32 might be slightly
different, but the issue should apply the same way.

-- 
Philippe.

Re: [Xenomai] ipipe: Comment in __ipipe_handle_exception

[Jan Kiszka]

On 2014-09-11 11:33, Philippe Gerum wrote:
> On 09/11/2014 10:39 AM, Jan Kiszka wrote:
>> Hi Philippe,
>>
>> in 2338107647 I found this:
>>
>> @@ -383,6 +380,8 @@ int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
>>  			local_irq_disable();
>>  	}
>>  
>> +	/*
>> +	 * XXX: We don't trace page faults (yet?). */
>>  	if (vector == ex_do_page_fault)
>>  		cr2 = native_read_cr2();
>>  
>>
>> What is the background? Any open issue?
>>
> 
> The current interposition we do via std_extable is not aware of trace_*
> hooks in entry*.S, so we end up bypassing the trace encapsulation
> entirely in __ipipe_handle_exception. Nothing bad, it just needs some
> work to do this cleanly. This is for x86_64, ia32 might be slightly
> different, but the issue should apply the same way.

Which tracing are you referring to? There are at least three in the
assembly entries (ftrace, Linux IRQSOFF tracing, I-pipe tracing). And I
unfortunately still don't get how those relate to the reading of CR2.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] ipipe: Comment in __ipipe_handle_exception

[Philippe Gerum]

On 09/11/2014 01:17 PM, Jan Kiszka wrote:
> On 2014-09-11 11:33, Philippe Gerum wrote:
>> On 09/11/2014 10:39 AM, Jan Kiszka wrote:
>>> Hi Philippe,
>>>
>>> in 2338107647 I found this:
>>>
>>> @@ -383,6 +380,8 @@ int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
>>>  			local_irq_disable();
>>>  	}
>>>  
>>> +	/*
>>> +	 * XXX: We don't trace page faults (yet?). */
>>>  	if (vector == ex_do_page_fault)
>>>  		cr2 = native_read_cr2();
>>>  
>>>
>>> What is the background? Any open issue?
>>>
>>
>> The current interposition we do via std_extable is not aware of trace_*
>> hooks in entry*.S, so we end up bypassing the trace encapsulation
>> entirely in __ipipe_handle_exception. Nothing bad, it just needs some
>> work to do this cleanly. This is for x86_64, ia32 might be slightly
>> different, but the issue should apply the same way.
> 
> Which tracing are you referring to? There are at least three in the
> assembly entries (ftrace, Linux IRQSOFF tracing, I-pipe tracing). And I
> unfortunately still don't get how those relate to the reading of CR2.
> 
> Jan
> 

CONFIG_TRACING, for ftrace.

-- 
Philippe.