| Message ID | 20220124055741.3686496-1-npiggin@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | powerpc: Disable syscall emulation and stepping | expand |
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. Christophe
+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? Thanks, Nick
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? > 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. 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. So at the end it's probably ok with return 0, both for them and for traps. Christophe
Excerpts from naverao1's message of January 25, 2022 8:48 pm: > 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. Although it can cause a signal, and the signal handler can decide to resume somewhere else. Or kernel mode equivalent it can go to a fixup handler and resume somewhere else. How are those handled? Thanks, Nick > 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 >
[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
On 2022-01-27 13:09, Nicholas Piggin wrote: > Excerpts from naverao1's message of January 25, 2022 8:48 pm: >> 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. > > Although it can cause a signal, and the signal handler can decide > to resume somewhere else. If a signal is generated while we are single-stepping, we delay signal delivery (see uprobe_deny_signal()) until after the single stepping. For fatal signals, single stepping is disabled before we allow the signal to be delivered. > Or kernel mode equivalent it can go to a > fixup handler and resume somewhere else. For kprobes, we do not allow probing instructions that have an extable entry. - Naveen