INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT

Wed Feb 21 14:41:43 UTC 2018

On Tue, Feb 20, 2018 at 8:26 PM, Chris Johns <chrisj at rtems.org> wrote:

> On 21/02/2018 01:23, Sebastian Huber wrote:
> > ----- Am 19. Feb 2018 um 12:41 schrieb Matthew J Fletcher
> amimjf at gmail.com:
> >
> >> Hi,
> >>
> >> I've seen this in our application in certain use cases, if my
> understanding
> >> is correct (an it might not be), it comes
> >> from RTEMS_SCORE_ROBUST_THREAD_DISPATCH,
> >> via CPU_ENABLE_ROBUST_THREAD_DISPATCH.
> >>
> >> It only seems to be TRUE for Arm, which seems a bit inconstant. However
> i
> >> dont really understand what its trying to achieve, i see
> >> https://devel.rtems.org/ticket/2954 but it does more than just
> optimise the
> >> context switch, it significantly alters how an application should be
> >> written, no more freeing memory with interrupts disabled etc,
> >
> > Originally, the CPU_ENABLE_ROBUST_THREAD_DISPATCH was implemented for
> the SMP support (inter-processor interrupt delivery MUST be possible during
> operating system services). On ARMv7-M it catches an undefined behaviour
> case. On the other ARM variants it simplified the context switch code. In
> general, we could enable the CPU_ENABLE_ROBUST_THREAD_DISPATCH on all
> architectures. This would probably break some broken applications.
>
> This is a bit messy because it is clearly wrong on SMP while the Classic
> API's
> `rtems_task_create` [1] lets a user set the mask level which is almost
> saying
> "run a task at a specific mask level". I am not aware of an API call that
> lets a
> user change this level and an interrupt disable and restore returns the
> task's
> initial level so at some point being able to block with a specific mask
> level
> was a requirement. Also on modern processors levels are handled in
> interrupt
> controllers and not in the CPU so how much use is an initial mask level
> these days?
>

rtems_task_mode() lets you change the interrupt mode dynamically.

FWIW I don't know that this feature ever was a good idea and I would be
OK with obsoleting the ability to alter the interrupt level via task mode.
But
that doesn't prevent a user from using other mechanisms including their
own inline assembly from disabling processor interrupts.

Now get off my lawn and let me tell you how long this feature has been
hokey.
Of the six earliest RTEMS ports (m68k, i386, i960, powerpc, hppa, and
sparc),
the m68k, i960, and sparc could meaningfully map the interrupt level in mode
on to something at the processor. The old PowerPC's only had external
exception
and decrementer interrupts. The i386 only has on and off but in all real
implementations
(e.g. PCs) has external interrupt controller. The hppa had on/off as I
recall but
the port/BSP had a clever feature where unused integer values mapped to
configurable settings of the interrupt controller.

This feature is inherently non-portable if you depend on a "level" other
than
on and off.

>
> I am personally OK with a change to catch interrupts being masked in a
> context
> switch because it is more likely this happens in error than on purpose and
> catching this type of error without an internal check like this is hard.
> The
> flow on of this is making obsolete setting the level on a task create.
>

Agreed.

But calling the "robust" implies there a regular context switch isn't
robust. This
implies we don't normally switch enough registers or something. Perhaps
a better word is needed for this feature.

>
> I suspect setting the interrupt level on a task on an ARMv-7 would result
> in the
> internal error if the user did not clear the interrupt mask before calling
> a
> blocking call. This complicates the documentation because of per arch
> differences.
>

Is this a hardware feature? I wouldn't be unhappy with this being a generic
check.

I know it has been possible to do this for 30 years but banning it wouldn't
be a
bad thing.

>
> Also, the documentation should be updated noting the SMP exceptions. I have
> raised #3309 to track this.
>

We recently went through this discussion for just SMP. It would be simpler
to just
obsolete the feature entirely.

>
> > You should never call an operating system service with interrupts
> disabled in thread context. This would destroy all the work done in the
> RTEMS implementation to keep the interrupt latency small.
>
> I agree and so I question if we should allow a task's initial mask level
> to be
> set this way?
>
> My rational is making the API consistent on non-SMP and SMP targets and
> helping
> to isolate a difficult case to catch.
>

I agree with this rationale on this feature.

But we should all remember that no matter what we do the
user and system integrator can easily destroy the performance of a system in
a way that reflects poorly on RTEMS. As someone I work with loves to say,
"You can't prevent stupid." :)

--joel

>
> Chris
>
> [1]
> https://docs.rtems.org/branches/master/c-user/task_
> manager.html#task-create-create-a-task
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180221/0bb48a12/attachment-0002.html>