Subject: Re: user address space protection in the kernel
To: Matt Thomas <>
From: Rahul Kulkarni <>
List: tech-kern
Date: 04/08/2006 10:50:01
On 4/8/06, Matt Thomas <> wrote:
> Rahul Kulkarni wrote:
> > Thanks much in advance for all you replies. appreciate it.
> >
> > Hmm..If I understand this right..since the USERSR is valid during a
> > copy{in,out} a buggy sysem call / ioctl can potentially corrupt user
> > space though highly improbable.
> >
> > I'm debugging a condition where a byte gets corrupted in the user
> > space, (extremely hard to reproduce) and after pouring over user space
> > code now trying to rule out home grown system calls/ioctls since the
> > user process does make a bunch of system calls/ioctls.
> in random processes, or in one particular process?
> > I'm thinking ways of to generate a DSI/exception to catch/rule out
> > bugs of the above type ..can you think of  any?
> Yep.  But it depends on how the bug is manifesting itself.

RK>>>Its in random processes, code asserts (post mortem) since it sees
a bad byte after 2-3 days of tests. Its the libraries or the kernel.
But I want to rule out the kernel (homegrown syscall/ioctls).
painfully isolating the libs one by one, mprotect slows down the whole
thing and reproducibility is an issue so using mprotect (4k) is ruled
out. How do you catch a bad byte?

> > Is there a way to BAT map only the first 256 MB of the physical memory
> > and move the copy{in,out} operations to that area?  If yes, what are
> > the other implications?
> No.

> > Is it mandatory to BAT map the complete physical memory for certain PPC=
> Basically, yes.
> --
> Matt Thomas                     email:
> 3am Software Foundry              www:
> Cupertino, CA              disclaimer: I avow all knowledge of this messa=