All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
To: oliver <oohall@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] Fix fall-through from case 30 (rld*) to case 31
Date: Wed, 27 Jan 2016 18:00:37 +1100	[thread overview]
Message-ID: <56A86B15.9040803@au1.ibm.com> (raw)
In-Reply-To: <CAOSf1CEh6GjJZLKGXDviVbycPUuPzb6jL05Zq5d0pzBpeiumNA@mail.gmail.com>

On 27/01/16 16:29, oliver wrote:
>>Is there anywhere else in the sstep code that deals well with malformed instructions?
>
> When you break out of the switch the opcode type is marked as unknown
> and when further attempts to parse the instruction fail it returns zero
> to indicate failure. Also, many of the instructions handled by the
> function are only valid in 64bit mode. For 32bit processors these
> instructions would be illegal and the code that handles them is
> #ifdef`ed out when compiling for 32 bit platforms so simply breaking out
> of the switch and letting it propagate should be the right move here.

analyse_instr() returns 0 whenever it analyses but does not execute an 
instruction - it's not a failure as such.

In emulate_step(), if analyse_instr() returns 0 it will test for a bunch 
of instruction classes which require memory operations, and classes 
which can't be single-stepped. UNKNOWN isn't handled specifically, so 
it'll skip all that and return 0 at the end (meaning the step was not 
successfully emulated - as opposed to -1, which is used for instructions 
that are not allowed to be stepped).

This in turn is handled differently depending on whether emulate_step() 
is invoked in the kprobes, uprobes or hw_breakpoint code.

Rather than breaking out and relying on behaviour later in the code, I'd 
suggest either:

  - creating a goto label for bad instructions that clearly sets the 
type to UNKNOWN and returns 0 (and maybe adding some handling for that 
in emulate_step(), raise some kind of nice big warning at the very least)

  - make analyse_instr() return -1 on invalid instructions, which 
emulate_step() will immediately propagate, then make sure that whoever 
calls emulate_step() handles that appropriately


Andrew

-- 
Andrew Donnellan              Software Engineer, OzLabs
andrew.donnellan@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)        IBM Australia Limited

  reply	other threads:[~2016-01-27  7:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25  6:55 [PATCH] Fix fall-through from case 30 (rld*) to case 31 Oliver O'Halloran
2016-01-27  0:52 ` Andrew Donnellan
2016-01-27  5:29   ` oliver
2016-01-27  7:00     ` Andrew Donnellan [this message]
2016-02-15 23:28 ` [PATCH] powerpc/lib/sstep.c - Fix emulation fall-through Oliver O'Halloran
2016-02-16  0:59   ` Andrew Donnellan
2016-02-16  6:31     ` [PATCH v2] powerpc/sstep.c " Oliver O'Halloran
2016-05-10 21:48       ` [v2] " Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A86B15.9040803@au1.ibm.com \
    --to=andrew.donnellan@au1.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oohall@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.