[parisc-linux] Mysterious hangs with parisc (a send_group_sig_info() analysis)

[Grant Grundler]

On Sat, Jul 22, 2006 at 06:49:18PM -0500, Michael S. Zick wrote:
> The assumption here is that the flag bit in an external variable
> is always in-sync with the interrupt status bit in the register.

The flag bit is generally the value _before_ we attempted to acquire a lock.
I'm really not comfortable with passing in a zero flags value.
I'd need to review alot more code to be happy we aren't breaking
something else that uses __raw_spin_lock.

...
> A general purpose, like we don't know what state the interrupts
> are in, and we don't want to trust an external flag bit;
> 
> Looks like:
> 
> Busy_Loop:
>    Save current interrupt status to the external variable;
>    Enable interrupts; /* a nop if already enabled */
>    Cpu_relax; /* Long enough to recognize pending interrupts */
>    Restore interrupt status from external variable;

I'm ok with this for two reasons:
1) I'm not sure looking at the _previous_ state is the intent
2) branch in perf path is always a bad thing (after cacheline misses).

However, I don't know if there is a reason to instead look at
the previous state.

> Our redefining Cpu_relax to a pair of nops was for machines that
> delay recognizing interrupts for an instruction after changing
> the status bit.  We also included an asm comment in Cpu_relax
> just in case we wanted to see that it had not gotten optimized away.

the asm comment is a good idea.

> Same reason the mb() was redefined as an asm comment that could
> be identified by inspection.

*nod*.

thanks,
grant