[PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()

Naveen N. Rao naveen.n.rao at linux.vnet.ibm.com
Tue Apr 28 03:14:14 AEST 2020


Christopher M. Riedl wrote:
> On Fri Apr 24, 2020 at 9:15 AM, Steven Rostedt wrote:
>> On Thu, 23 Apr 2020 18:21:14 +0200
>> Christophe Leroy <christophe.leroy at c-s.fr> wrote:
>>
>> 
>> > Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
>> > > With STRICT_KERNEL_RWX, we are currently ignoring return value from
>> > > __patch_instruction() in do_patch_instruction(), resulting in the error
>> > > not being propagated back. Fix the same.  
>> > 
>> > Good patch.
>> > 
>> > Be aware that there is ongoing work which tend to wanting to replace 
>> > error reporting by BUG_ON() . See 
>> > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003
>>
>> 
>> Thanks for the reference. I still believe that WARN_ON() should be used
>> in
>> 99% of the cases, including here. And only do a BUG_ON() when you know
>> there's no recovering from it.
>>
>> 
>> In fact, there's still BUG_ON()s in my code that I need to convert to
>> WARN_ON() (it was written when BUG_ON() was still acceptable ;-)
>>
> Figured I'd chime in since I am working on that other series :) The
> BUG_ON()s are _only_ in the init code to set things up to allow a
> temporary mapping for patching a STRICT_RWX kernel later. There's no
> ongoing work to "replace error reporting by BUG_ON()". If that initial
> setup fails we cannot patch under STRICT_KERNEL_RWX at all which imo
> warrants a BUG_ON(). I am still working on v2 of my RFC which does
> return any __patch_instruction() error back to the caller of
> patch_instruction() similar to this patch.

Ok, that's good to know. I will drop this patch from my series, since 
this can be done independently of the other changes.

- Naveen



More information about the Linuxppc-dev mailing list