ppc32 exception handling broken

[Jakub Jermář]

This problem is described in ​this mailing list thread.

Excerpt from symptoms:

On PowerPC I sometimes trigger the assertion

        PREEMPTION_DISABLED in preemption_enable() with stack trace:
           preemption_enable()
           event_is_subscribed()
           putchar()
           vprintf_str_write()
           printf_core()
           vprintf()
           printf()
           waitq_sleep_timeout()
           _semaphore_down_timeout()
           _mutex_lock_timeout()
           pt_lock()
           page_table_lock()
           pht_refill()
           exc_dispatch()

    and

        (!PREEMPTION_DISABLED) || (PARAM_NON_BLOCKING(flags, usec)) with
        stack trace:
           waitq_sleep_timeout()
           _mutex_lock_timeout()
           pt_lock()
           page_table_lock()
           pht_refill()
           exc_dispatch()

Initial assesment by Martin:

I believe that I already know the reason for the problems on ppc32: The 
code does not respect the assumption that the THE structure must be 
always valid, even in the interrupt context.

The reason lies in the complicated exception handling mechanism where 
all memory virtualization is turned off. Thus you cannot use the 
thread's original stack for storing the context (because generally you 
don't know where in the physical memory the kernel stack is).

Currently we use a dedicated kernel stack, which certainly does not 
contain the THE structure. Suprisingly this worked fine for many years 
until your changeset 434 where you added the !PREEMPTION_DISABLED 
assertion. Even more suprisingly this was probably the first time the 
exception code started to touch the THE structure.

[Jakub Jermář]

And couldn't we fix this by using a different mechanism for remembering thread local data on ppc32? On ia32, we also needn't use the stack based solution, but we could make use of e.g. segmentation or on sparc64 and ia64 we could use a banked register.

[Martin Decky]

Fixed as of mainline,971, more details in ​mailing list.

[Jakub Jermář]

This should be theoretically non-reproducible in changeset:mainline,981. Unfortunately, ppc32 suffers occasional panics on various assertions triggered usually from as_destroy() and as_area_destroy(). The issue seems to be ppc32 specific.

[Martin Decky]

Although I have not fully reviewed the changeset, the conceptual idea has been discussed on the mailing list and the implementation seems to work fine. Therefore I am marking this ticket as closed and fixed again.