[PATCH 0/2] powerpc: Disable syscall emulation and stepping

[Naveen N. Rao]

[Sorry if you receive this in duplicate. Resending since this message 
didn't hit the list]


On 2022-01-25 11:23, Christophe Leroy wrote:
> Le 25/01/2022 à 04:04, Nicholas Piggin a écrit :
>> +Naveen (sorry missed cc'ing you at first)
>> 
>> Excerpts from Christophe Leroy's message of January 24, 2022 4:39 pm:
>>> 
>>> 
>>> Le 24/01/2022 à 06:57, Nicholas Piggin a écrit :
>>>> As discussed previously
>>>> 
>>>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/238946.html
>>>> 
>>>> I'm wondering whether PPC32 should be returning -1 for syscall
>>>> instructions too here? That could be done in another patch anyway.
>>>> 
>>> 
>>> The 'Programming Environments Manual for 32-Bit Implementations of 
>>> the
>>> PowerPC™ Architecture' says:
>>> 
>>> The following are not traced:
>>> • rfi instruction
>>> • sc and trap instructions that trap
>>> • Other instructions that cause interrupts (other than trace 
>>> interrupts)
>>> • The first instruction of any interrupt handler
>>> • Instructions that are emulated by software
>>> 
>>> 
>>> So I think PPC32 should return -1 as well.
>> 
>> I agree.
>> 
>> What about the trap instructions? analyse_instr returns 0 for them
>> which falls through to return 0 for emulate_step, should they
>> return -1 as well or am I missing something?

Yeah, good point about the trap instructions.

>> 
> 
> For the traps I don't know. The manual says "trap instructions that
> trap" are not traced. It means that "trap instructions that _don't_
> trap" are traced. Taking into account that trap instructions don't trap
> at least 99.9% of the time, not sure if returning -1 is needed.
> 
> Allthought that'd probably be the safest.

'trap' is a special case since it is predominantly used by debuggers
and/or tracing infrastructure. Kprobes and Uprobes do not allow probes
on a trap instruction. But, xmon can be asked to step on a trap
instruction and that can interfere with kprobes in weird ways.

So, I think it is best if we also exclude trap instructions from being
single stepped.

> 
> But then what happens with other instruction that will sparsely 
> generate
> an exception like a DSI or so ? If we do it for the traps then we 
> should
> do it for this as well, and then it becomes a non ending story.

For a DSI, we restart the same instruction after handling the page 
fault.
The single step exception is raised on the subsequent successful
completion of the instruction. For most other interrupts (alignment, vsx
unavailable, ...), we end up emulating the single step exception itself
(see emulate_single_step()). So, those are ok if caused by an 
instruction
being stepped.


- Naveen