Re: [Xenomai] Question regarding rt_sem_p

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2014-09-16 17:56, Lennart Sorensen wrote:
> On Sun, Sep 14, 2014 at 05:27:04AM +0200, Gilles Chanteperdrix wrote:
>> I am almost sure I fixed an issue with user-space getting -EINTR with
>> gdb. I simply did not want to look for the commit if you still have the
>> issue with 3.14. If 3.14 does not boot, it looks like I will have to
>> search the commit anyway.
> 
> I am trying to bacport the 3.14 git tree to 3.12 (so far looking not
> too hard).  Just trying to get any of the fixes 3.14 has to see if it
> helps (the commit mentioned did help with some things, so gdb works now).
> 
> I spotted this though that looks like a mistake (although clearly harmless
> is CONFIG_IPIPE is enabled)
> 
> diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> index b30a292..27376a0 100644
> --- a/kernel/sched/clock.c
> +++ b/kernel/sched/clock.c
> @@ -242,6 +242,10 @@ u64 sched_clock_cpu(int cpu)
>         struct sched_clock_data *scd;
>         u64 clock;
>         
> +#ifndef CONFIG_IPIPE
> +       WARN_ON_ONCE(!irqs_disabled());
> +#endif 
> +
>         if (sched_clock_stable())
>                 return sched_clock();
>                 
> 
> The kernel purposely removed that warning, so why should the ipipe patch
> put it back, and only when ipipe is disabled?
> 

Usually such things come in when merge conflicts are resolved.

Upstream replaced local_irq_disable with preempt_enable/disable for the
sched clock. That's fine for our usage, tracing, as we have that under
control when I-pipe is enabled. Without I-pipe, this piece will cause a
false-positive. So a patch to remove this also in 3.14 is definitely
welcome.

Jan

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