[PATCH v3 28/32] powerpc/64s: interrupt implement exit logic in C

[Nicholas Piggin]

Excerpts from Christophe Leroy's message of February 27, 2021 8:07 pm:
> 
> 
> Le 25/02/2020 à 18:35, Nicholas Piggin a écrit :
>> Implement the bulk of interrupt return logic in C. The asm return code
>> must handle a few cases: restoring full GPRs, and emulating stack store.
>> 
>> The stack store emulation is significantly simplfied, rather than creating
>> a new return frame and switching to that before performing the store, it
>> uses the PACA to keep a scratch register around to perform thestore.
>> 
>> The asm return code is moved into 64e for now. The new logic has made
>> allowance for 64e, but I don't have a full environment that works well
>> to test it, and even booting in emulated qemu is not great for stress
>> testing. 64e shouldn't be too far off working with this, given a bit
>> more testing and auditing of the logic.
>> 
>> This is slightly faster on a POWER9 (page fault speed increases about
>> 1.1%), probably due to reduced mtmsrd.
> 
> 
> This series, and especially this patch has added a awfull number of BUG_ON() traps.
> 
> We have an issue open at https://github.com/linuxppc/issues/issues/88 since 2017 for reducing the 
> number of BUG_ON()s
> 
> And the kernel Documentation is explicit on the willingness to deprecate BUG_ON(), see 
> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=bug_on :
> 
> BUG() and BUG_ON()
> Use WARN() and WARN_ON() instead, and handle the “impossible” error condition as gracefully as 
> possible. While the BUG()-family of APIs were originally designed to act as an “impossible 
> situation” assert and to kill a kernel thread “safely”, they turn out to just be too risky. (e.g. 
> “In what order do locks need to be released? Have various states been restored?”) Very commonly, 
> using BUG() will destabilize a system or entirely break it, which makes it impossible to debug or 
> even get viable crash reports. Linus has very strong feelings about this.
> 
> So ... can we do something cleaner with all the BUG_ON()s recently added ?

Yeah you're right. Some of it is probably overkill due to paranoia when 
developing the series.

Now we have a bit more confidence we could probably look at cutting down 
on these.

I do get a bit concerned about detecting a problem in some code like 
this and attempting to just continue, it usually means the system is 
going to crash pretty badly anyway (and the WARN_ON trap interrupt is
probably going to finish you off anyway). So I think removing the more
obvious checks entirely (maybe with a PPC DEBUG config option) is the
right way to go.

Thanks,
Nick