Date: Mon, 6 Dec 1999 19:32:34 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: freebsd-hackers@FreeBSD.ORG, dfr@nlsystems.com Subject: Re: Is part of user stack always mapped? Message-ID: <14412.21471.227840.24484@grasshopper.cs.duke.edu> In-Reply-To: <199912062216.RAA09858@lor.watermarkgroup.com> References: <199912062216.RAA09858@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Luoqi Chen writes:
> > I was under the impression that this was a no-no & one should use
> > copyin/copout & friends to access memory on users's stacks. Although
> > this appears to work on the i386, if I try this on the alpha I take a
> > fatal trap when accessing *set.
> >
> > So -- how does this work on the i386? Is the user's stack always
> > mappeped into the kernel's address space? Should it also work on the
> > alpha?
> >
> On i386, under the current implementation, the kernel can directly access
> curproc's address space (not just the stack, stack is used because we're
> sure the spare space won't/shouldn't be used by the user application).
> I don't know if the same is true for alpha, but this should definitely
> be considered an implementation dependent feature. I wish there were some
> other ways to bypass copyin/out in ioctls.
>
> -lq
I think the alpha should be capable of doing this too. From reading
the alpha pmap code, it looks like its marking memory as kernel
readable/writeable whenever it does the same for the userspace access.
I might be reading it wrong, though.
Can anybody tell me why an access to memory allocated w/stackgap_alloc()
would cause a kernel panic on alpha, but works just fine through the
copyin/copyout interface?
Eg:
#0 0xfffffc0000391054 in boot (howto=256) at ../../kern/kern_shutdown.c:271
#1 0xfffffc0000391810 in panic (fmt=0xfffffc00005a2ca4 "trap")
at ../../kern/kern_shutdown.c:523
#2 0xfffffc00005340a0 in trap (a0=301973216, a1=1, a2=1, entry=2,
framep=0xfffffe0010699ce0) at ../../alpha/alpha/trap.c:529
#3 0xfffffc00005262ec in XentMM () at ../../alpha/alpha/exception.s:94
#4 0xfffffe0001afa440 in osf1_sigsuspend (p=0xfffffe000ed4ff00, uap=0x0)
at /usr/project/ari_scratch2/gallatin/src/sys/modules/osf1/../../alpha/osf1/osf1_signal.c:613
#5 0xfffffc0000534304 in syscall (code=111, framep=0xfffffe0010699ee0)
at ../../alpha/alpha/trap.c:633
#6 0xfffffc000052634c in XentSys () at ../../alpha/alpha/exception.s:127
<...>
(gdb) frame 2
#2 0xfffffc00005340a0 in trap (a0=301973216, a1=1, a2=1, entry=2,
framep=0xfffffe0010699ce0) at ../../alpha/alpha/trap.c:529
529 panic("trap");
(gdb) p/x a0
$1 = 0x11ffbee0
(gdb) p/x curproc->p_vmspace->vm_maxsaddr
$2 = 0xfffc000
(gdb) p/x curproc->p_vmspace->vm_minsaddr
$3 = 0x11ffb2c8
For you non-alpha people -- in the above, a0 is the faulting address.
Thanks,
Drew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14412.21471.227840.24484>