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.

I'm thinking ways of to generate a DSI/exception to catch/rule out
bugs of the above type ..can you think of  any?

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?

Is it mandatory to BAT map the complete physical memory for certain PPC  MM=
U's?






On 4/8/06, Matt Thomas <matt@3am-software.com> wrote:
> Rahul Kulkarni wrote:
> >
> > RK->>>>>>>I did not mean user code in the kernel context..Let me
> > rephrase that  If a buggy system call or a buggy ioctl servicing a
> > user process happens to potentially trample parts of the user adress
> > space will it generate a DSI or an exception? since the USERSR is
> > invalid at that point? Is there any other window in the kernel other
> > than copy{in,out} where USERSR is valid?
>
> Really, this is a relatively minor concern.  If you have a buggy system
> call or ioctl, it is much much more likely to corrupt other parts of the
> kernel which will cause panics.
>
> --
> Matt Thomas                     email: matt@3am-software.com
> 3am Software Foundry              www: http://3am-software.com/bio/matt/
> Cupertino, CA              disclaimer: I avow all knowledge of this messa=
ge.
>