[Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

Hi,

originally, I was hunting some mutex issue (still on it, report will
follow soon). But due to a typo I revealed some nasty clean-up issue of
current trunk (2.1.x seems to contain the same code). Try to create two
tasks like this:

        rt_task_spawn(&task1, "task1", 0, 20, 0, task1_fnc, 0);
        rt_task_spawn(&task2, "task1", 0, 10, 0, task2_fnc, 0);
	[I think rt_task_create would "work" as well.]

The second call will fail due to duplicate names - and will trigger the
lock-up at this chance. It's actually a NULL pointer fault caused like this:

(gdb) bt
#0  schedule_linux_call (type=4, p=0x0, arg=9) at shadow.c:343
                                 ^^^^^
                                 oops!
#1  0xc013b184 in xnshadow_send_sig (thread=<value optimized out>,
    sig=9, specific=<value optimized out>) at shadow.c:1087
#2  0xc492d7d0 in rt_task_delete (task=0xc1120d20) at task.c:591
#3  0xc492d4f7 in rt_task_create (task=0xc1120d20, name=0xc1375f1c
    "task1", stksize=0, prio=10, mode=3145728) at task.c:287

Sorry, no patch yet, I have to move on to the mutex issue first.

BTW, this reminds me the ask for a merging plan of the kgdb support for
ipipe - this bug was tracked down via kgdb...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > BTW, this reminds me the ask for a merging plan of the kgdb support for
 > ipipe - this bug was tracked down via kgdb...

There are some issues with the kgdb patch:
- it does not work if the nucleus is compiled as a module, because it
  uses xnpod_current_thread()
- it does not work on SMP because the kgdb patch uses
  smp_processor_id(), which does not work on SMP over Xenomai domain.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > BTW, this reminds me the ask for a merging plan of the kgdb support for
>  > ipipe - this bug was tracked down via kgdb...
> 
> There are some issues with the kgdb patch:
> - it does not work if the nucleus is compiled as a module, because it
>   uses xnpod_current_thread()

I know, but I do not have a clean solution for this yet. A workaround
would be to force the nucleus into the kernel via kconfig if the kgdb is
enabled. Any other ideas how to detect kernel-only threads (i.e. invalid
"current")?

> - it does not work on SMP because the kgdb patch uses
>   smp_processor_id(), which does not work on SMP over Xenomai domain.
> 

Ok, but probably fixable. If simple search&replace in the kgdb patch is
not enough, a similar workaround could be applied for now: disallow kgdb
usage over SMP.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > Jan Kiszka wrote:
 > >  > BTW, this reminds me the ask for a merging plan of the kgdb support for
 > >  > ipipe - this bug was tracked down via kgdb...
 > > 
 > > There are some issues with the kgdb patch:
 > > - it does not work if the nucleus is compiled as a module, because it
 > >   uses xnpod_current_thread()
 > 
 > I know, but I do not have a clean solution for this yet. A workaround
 > would be to force the nucleus into the kernel via kconfig if the kgdb is
 > enabled. Any other ideas how to detect kernel-only threads (i.e. invalid
 > "current")?

If we suppose that the kgdb patch is made adeos aware, could we ask a
domain-specific callback to be called when not running the root domain ?
This callback would be set by Xenomai in an #ifdef CONFIG_KGDB section.

 > 
 > > - it does not work on SMP because the kgdb patch uses
 > >   smp_processor_id(), which does not work on SMP over Xenomai domain.
 > > 
 > 
 > Ok, but probably fixable. If simple search&replace in the kgdb patch is
 > not enough, a similar workaround could be applied for now: disallow kgdb
 > usage over SMP.

Since we are going to have this problem over and over again for each
patch that we want to adapt to xenomai (ltt comes to my mind), maybe we
could make smp_processor_id() in adeos patch safe to be called over non
root domain by using ipipe_processor_id() when called over non-root
domains.

I think there is currently no code that take advantage of the fact that
the fast smp_processor_id() may safely be called over shadow threads, so
the performance penalty of using ipipe_processor_id() will be minimal.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jan Kiszka wrote:
>  > >  > BTW, this reminds me the ask for a merging plan of the kgdb support for
>  > >  > ipipe - this bug was tracked down via kgdb...
>  > > 
>  > > There are some issues with the kgdb patch:
>  > > - it does not work if the nucleus is compiled as a module, because it
>  > >   uses xnpod_current_thread()
>  > 
>  > I know, but I do not have a clean solution for this yet. A workaround
>  > would be to force the nucleus into the kernel via kconfig if the kgdb is
>  > enabled. Any other ideas how to detect kernel-only threads (i.e. invalid
>  > "current")?
> 
> If we suppose that the kgdb patch is made adeos aware, could we ask a
> domain-specific callback to be called when not running the root domain ?
> This callback would be set by Xenomai in an #ifdef CONFIG_KGDB section.

Sounds good, will try this.

> 
>  > 
>  > > - it does not work on SMP because the kgdb patch uses
>  > >   smp_processor_id(), which does not work on SMP over Xenomai domain.
>  > > 
>  > 
>  > Ok, but probably fixable. If simple search&replace in the kgdb patch is
>  > not enough, a similar workaround could be applied for now: disallow kgdb
>  > usage over SMP.
> 
> Since we are going to have this problem over and over again for each
> patch that we want to adapt to xenomai (ltt comes to my mind), maybe we
> could make smp_processor_id() in adeos patch safe to be called over non
> root domain by using ipipe_processor_id() when called over non-root
> domains.
> 
> I think there is currently no code that take advantage of the fact that
> the fast smp_processor_id() may safely be called over shadow threads, so
> the performance penalty of using ipipe_processor_id() will be minimal.
> 

What about the potential penalty for normal Linux callers of
smp_processor_id()? Would this degrade the overall performance
noticeably even if there is now kgdb or ltt? Or should we make this
"ipipe-safe" smp_processor_id() optional for such users?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > >  > > - it does not work on SMP because the kgdb patch uses
 > >  > >   smp_processor_id(), which does not work on SMP over Xenomai domain.
 > >  > > 
 > >  > 
 > >  > Ok, but probably fixable. If simple search&replace in the kgdb patch is
 > >  > not enough, a similar workaround could be applied for now: disallow kgdb
 > >  > usage over SMP.
 > > 
 > > Since we are going to have this problem over and over again for each
 > > patch that we want to adapt to xenomai (ltt comes to my mind), maybe we
 > > could make smp_processor_id() in adeos patch safe to be called over non
 > > root domain by using ipipe_processor_id() when called over non-root
 > > domains.
 > > 
 > > I think there is currently no code that take advantage of the fact that
 > > the fast smp_processor_id() may safely be called over shadow threads, so
 > > the performance penalty of using ipipe_processor_id() will be minimal.
 > > 
 > 
 > What about the potential penalty for normal Linux callers of
 > smp_processor_id()? Would this degrade the overall performance
 > noticeably even if there is now kgdb or ltt? Or should we make this
 > "ipipe-safe" smp_processor_id() optional for such users?

ipipe_current_domain uses ipipe_processor_id, so that replacing
smp_processor_id with :
if (ipipe_current_domain() == ipipe_root_domain)
    return raw_smp_processor_id()

is really stupid...

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Philippe Gerum]

Jan Kiszka wrote:
> 
> BTW, this reminds me the ask for a merging plan of the kgdb support for
> ipipe - this bug was tracked down via kgdb...
> 

It's queued with some changes planned (specifically removing any 
Xenomai-specifics from the patch).

-- 

Philippe.