From: Scott Wood <scottwood@freescale•com>
To: saikia.partha <saikia.partha@gmail•com>
Cc: linuxppc-dev@lists•ozlabs.org
Subject: Re: DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)
Date: Wed, 19 Jun 2013 16:00:46 -0500 [thread overview]
Message-ID: <1371675646.9073.39@snotra> (raw)
In-Reply-To: <CABeCxOKXpgVaoigGBdCVo3tYgbfJnesNPOuOyTc0EKv_CTKoyg@mail.gmail.com> (from saikia.partha@gmail.com on Wed Jun 19 08:09:44 2013)
On 06/19/2013 08:09:44 AM, saikia.partha wrote:
> Hi,
>=20
> We have two Freescale PowerPC boards on which we're trying to enable
> DEBUG_PAGEALLOC with the hope that we'll see an exception whenever =20
> some
> code tries to modify a page that's been already freed. To test it, we =20
> wrote
> this sample code -
>=20
> =3D=3D=3D
> #define BUF_SIZE 4096
> void
> pagealloc_test(void)
> {
> char *buf =3D kmalloc(BUF_SIZE, GFP_KERNEL);
>=20
> if (!buf) {
> printk("%s[%d] - alloc failed!\n", __func__, __LINE__);
> return;
> }
> printk("%s[%d] - alloc'd\n", __func__, __LINE__);
> memset(&buf[0], 0, BUF_SIZE);
> printk("%s[%d] - memset'd\n", __func__, __LINE__);
> kfree(buf);
> printk("%s[%d] - free'd\n", __func__, __LINE__);
> memset(&buf[0], 1, BUF_SIZE);
> printk("%s[%d] - memset'd after free!\n", __func__, __LINE__);
> }
> =3D=3D=3D
>=20
> Here, the last memset() should generate an exception if PAGEALLOC code
> correctly unmapped the page during kfree(). However, kernel is happily
> running after the memset post-free. Any clue?
> Also, the 2nd board has Book-E which has a different MMU architecture.
> Here, I saw that the function __change_page_attr() always returns as =20
> the
> condition v_mapped_by_tlbcam() is true. How do we remove the pte =20
> entry from
> the TLB in this case? Has anyone tried DEBUG_PAGEALLOC on Book-E?
This is not supported on booke -- the tlbcam mapping is required for =20
all lowmem.
> Please find the board details below -
> Board 1: CPU - e300c4, kernel 2.6-25
For e300, I think I had it working at one point a few years ago (see =20
commit bde6c6e16aa489ea76c762fb7ffb0abb48660dd8).
The reason we can do it on e300 and not on booke is because e300 takes =20
exceptions in real mode. On e500 the MMU is always enabled, so we need =20
bolted TLB1 entries that cover at least all exception code (up to the =20
point where a TLB miss could safely be taken) and all page tables (in =20
practice, we just bolt all lowmem) and other data that can be =20
referenced from said exception code. There are not enough TLB1 entries =20
to do this on a fine-grained basis.
-Scott=
next prev parent reply other threads:[~2013-06-19 21:00 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 [this message]
2013-06-20 10:42 ` perth1415
2013-06-20 19:15 ` Scott Wood
-- 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=1371675646.9073.39@snotra \
--to=scottwood@freescale$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.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