From owner-freebsd-hackers Mon Dec 6 16:33:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8844D14CC7 for ; Mon, 6 Dec 1999 16:33:06 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id TAA14617; Mon, 6 Dec 1999 19:33:04 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id TAA86625; Mon, 6 Dec 1999 19:32:34 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Dec 1999 19:32:34 -0500 (EST) To: Luoqi Chen Cc: freebsd-hackers@FreeBSD.ORG, dfr@nlsystems.com Subject: Re: Is part of user stack always mapped? In-Reply-To: <199912062216.RAA09858@lor.watermarkgroup.com> References: <199912062216.RAA09858@lor.watermarkgroup.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14412.21471.227840.24484@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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