From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: Add unwinding annotations for 64bit division functions
Date: Wed, 21 Sep 2011 14:33:07 +0100 [thread overview]
Message-ID: <20110921133307.GD2872@arm.com> (raw)
In-Reply-To: <20110921115553.GF17169@n2100.arm.linux.org.uk>
On Wed, Sep 21, 2011 at 12:55:53PM +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 21, 2011 at 12:39:09PM +0100, Dave Martin wrote:
> > Talking to Catalin a bit more, it sounds like prefetch aborts should not
> > happen in kernel code, and data aborts should not happen when accessing
> > the kernel stack.
>
> No faults should happen in kernel code, except for:
>
> 1. instructions specifically marked in the exception table, which are used
> to access user memory.
> 2. instructions causing an 'undefined instruction' exception.
>
> Standard ARM instructions like 'add', 'mov' etc should _never_ fault,
> and if they do that means your core isn't executing ARM instructions
> correctly (eg, the hardware design is faulty.)
>
> Instructions such as VFP, kprobes tracing, etc are expected fault
> locations, and those are fairly well controlled where they can be placed.
> With things like ftrace, it certainly is the case that the unwinder can
> theoretically be called from almost anywhere in a function.
>
> So I suggest that this does need to be fixed, and you can't rely on
> "prefetch aborts should not happen". That's true of prefetch aborts
> but not of other aborts.
The important thing for the unwinder is that it can't cope well with faults
happening in the save/restore sequences at function entry and exit, and
we may not cope well with functions which don't have a simple SAVE,
EXECUTE, RESTORE, RETURN structure.
My gut feeling is that neither (1) or (2) should happen in those sequences,
and VFP faults should not happen in these sequences because the kernel
should not contain VFP code except in particular controlled locations.
For things like kprobes which allow a trap to be set at a function's entry
point we do have a problem: if we try to backtrace from this point, the
backtracer will see we are in that function and will assume that the
function's state saving code has already executed. It might be simple
to work around this particular case by making the unwinder intelligent
enough to realise that if backtracing from the first instruction of a
function, none of the function's state save code can have executed yet.
next prev parent reply other threads:[~2011-09-21 13:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-19 22:11 [PATCH] arm: Add unwinding annotations for 64bit division functions Laura Abbott
2011-09-19 23:22 ` Nicolas Pitre
2011-09-20 1:55 ` Laura Abbott
2011-09-20 13:27 ` Nicolas Pitre
2011-09-20 14:57 ` Catalin Marinas
2011-09-21 11:39 ` Dave Martin
2011-09-21 11:55 ` Russell King - ARM Linux
2011-09-21 13:33 ` Dave Martin [this message]
2011-09-22 7:28 ` Jon Medhurst (Tixy)
2011-09-22 9:48 ` Catalin Marinas
2011-09-22 11:06 ` Jon Medhurst (Tixy)
2011-09-22 11:57 ` Catalin Marinas
2011-09-22 12:13 ` Jon Medhurst (Tixy)
2011-09-22 13:00 ` Catalin Marinas
2011-09-22 13:19 ` Jon Medhurst (Tixy)
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=20110921133307.GD2872@arm.com \
--to=dave.martin@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).