From: Scott Wood <scottwood@freescale•com>
To: perth1415 <saikia.partha@gmail•com>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)
Date: Thu, 20 Jun 2013 14:15:37 -0500 [thread overview]
Message-ID: <1371755737.11064.13@snotra> (raw)
In-Reply-To: <1371724960184-72625.post@n7.nabble.com> (from saikia.partha@gmail.com on Thu Jun 20 05:42:40 2013)
On 06/20/2013 05:42:40 AM, perth1415 wrote:
> Hi Scott,
>=20
> Thanks for the reply, though a bit disheartening :-)
> My understanding on e500 MMU is not clear. It'd be nice if I could =20
> find some
> way (may be ad-hoc) to debug some use-after-free page corruptions. =20
> SLAB
> debug tells me the page was modified by someone after it was freed but
> DEBUG_PAGEALLOC would have been more specific, as to tell me where =20
> exactly
> it was getting modified.
> Any debugging clues will be much appreciated.
If you know an exact address that's being corrupted, you could set a =20
data breakpoint (by manually setting the registers, and making sure =20
that the exception handler will produce a dump and not ignore it as a =20
spurious event). You could add code to periodically check for =20
corruption (from a timer, from codepaths which you suspect, =20
before/after IRQ handlers, etc). If you have specific code that you =20
suspect may be responsible, you can have it check for poison values =20
before writing. I'm not sure if slab debugging already does this, but =20
if not you could have it record the address of the code that last =20
allocated and freed the corrupted memory chunk.
If you have access to a tool such as Virtutech Simics, you could use =20
reverse execution to find the corruption.
Or you could find a way to separate the code/data needed by exceptions =20
(including page tables, kernel stacks, etc) from everything else, and =20
only pin the former, but that's probably a lot of work.
-Scott=
next prev parent reply other threads:[~2013-06-20 19:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 13:09 DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34) saikia.partha
2013-06-19 21:00 ` Scott Wood
2013-06-20 10:42 ` perth1415
2013-06-20 19:15 ` Scott Wood [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-06-19 12:58 saikia.partha
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=1371755737.11064.13@snotra \
--to=scottwood@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=saikia.partha@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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