From owner-freebsd-arch Sun Aug 18 11:12: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75FD237B400 for ; Sun, 18 Aug 2002 11:12:01 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9681C43E72 for ; Sun, 18 Aug 2002 11:12:00 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.5/8.12.5) with ESMTP id g7IIEK8a013641; Sun, 18 Aug 2002 14:14:20 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.5/8.12.5/Submit) id g7IIEEvt013640; Sun, 18 Aug 2002 14:14:14 -0400 (EDT) Date: Sun, 18 Aug 2002 14:14:13 -0400 From: Jake Burkholder To: Ian Dowse Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue Message-ID: <20020818141413.E590@locore.ca> References: <20020818055951.N12475-100000@gamplex.bde.org> <200208181751.aa29455@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200208181751.aa29455@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, Aug 18, 2002 at 05:51:49PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Sun, Aug 18, 2002 at 05:51:49PM +0100, Ian Dowse said words to the effect of; > In message <20020818055951.N12475-100000@gamplex.bde.org>, Bruce Evans writes: > >enough compat code). Some compat code doesn't know this very well and > >causes panics by accessing the stack gap directly. Non-broken code > >would require lots more copyins and copyouts to avoid direct accesses: > > Yes, I noticed a lot of places where the Linux emulation code was > accessing stack gap data without using copyin/copyout. Is there a > disabled check for this somewhere in the vm_fault code? I seem to > remember it being discussed somewhere but I can't find any references > in the code. Its in trap_pfault; i386 allows faults on any user address in kernel mode without using copyin/out, alpha allows faults on the stack gap. I think there's more code that does this, possibly in the i386 floating point emulation. Accessing user memory directly from kernel mode only works on architectures where both are in the same address space, so this doesn't work at all on sparc64, don't know about others. > > >> open(struct thread *td, struct open_args *uap) > > > >I would prefer this to be named something like xxx_open() and in a > >translation layer between Xsyscall() and open(), with the translation > >layer as null as possible. > > >> int sys_open(struct thread *td, char *path, enum uio_seg pathseg, > >> int flags, int mode); > > > >I would prefer this to be named open() and take the same args as open(2). > >Passing around td args seems to just lead to pessimizations and bugs, > >since syscalls especially almost require td == curthread to work... > > The only issue with naming things this way is that all other callers > of the system call (mainly other compat modules) need to be changed > one way or another at the same time. I just did it this way so that > syscalls could be changed over one at a time without touching their > callers for now. > > If there is agreement on the td vs. curthread issue, then that would > obviously be easy to change. Note that many system calls are not > as simple as open(2), so having the same arguments for the user and > kernel versions is not always practical. For example when there is > a combination of user-supplied structures and buffers, the overhead > of copying everything into the kernel by the compat module would > be too high. For *ctl() sysctls, it may require duplicating much > of the logic of the kernel syscall in the wrapper. A copyin/copyout > function that takes a UIO_*SPACE argument might help. There's copyinfrom and copyinstrfrom, copyoutto would probably be useful as well. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message