From owner-cvs-src@FreeBSD.ORG Tue Feb 1 15:26:52 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D127E16A4CE; Tue, 1 Feb 2005 15:26:52 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD5F43D39; Tue, 1 Feb 2005 15:26:52 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [127.0.0.1] (fxp1.moxa.united.net.ua [195.234.212.69]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j11FQkJ0056379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Feb 2005 16:26:48 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41FF9FB1.10107@portaone.com> Date: Tue, 01 Feb 2005 17:26:41 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200501292312.j0TNC0VE052634@repoman.freebsd.org> <200501311441.24275.jhb@FreeBSD.org> <41FEBAE5.7010201@portaone.com> <200502010643.45784.jhb@FreeBSD.org> In-Reply-To: <200502010643.45784.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/linux linux_sysvec.csrc/sys/alpha/osf1 src/sys/compat/ia32imgact_svr4.c svr4_sysvec.c ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 15:26:53 -0000 John Baldwin wrote: > On Monday 31 January 2005 06:10 pm, Maxim Sobolev wrote: > >>John Baldwin wrote: >> >>>On Saturday 29 January 2005 06:12 pm, Maxim Sobolev wrote: >>> >>>>sobomax 2005-01-29 23:12:00 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> sys/alpha/linux linux_sysvec.c >>>> sys/alpha/osf1 imgact_osf1.c osf1_sysvec.c >>>> sys/amd64/linux32 linux32_sysvec.c >>>> sys/compat/ia32 ia32_sysvec.c >>>> sys/compat/pecoff imgact_pecoff.c >>>> sys/compat/svr4 imgact_svr4.c svr4_sysvec.c >>>> sys/i386/ibcs2 ibcs2_sysvec.c imgact_coff.c >>>> sys/i386/linux imgact_linux.c linux_sysvec.c >>>> linux_machdep.c >>>> sys/kern imgact_aout.c imgact_elf.c imgact_gzip.c >>>> imgact_shell.c kern_exec.c kern_kse.c >>>> sys/modules Makefile >>>> sys/sys imgact.h syscallsubr.h >>>> Log: >>>> o Split out kernel part of execve(2) syscall into two parts: one that >>>> copies arguments into the kernel space and one that operates >>>> completely in the kernel space; >>>> >>>> o use kernel-only version of execve(2) to kill another stackgap in >>>> linuxlator/i386. >>>> >>>> Obtained from: DragonFlyBSD (partially) >>>> MFC after: 2 weeks >>> >>>Cool, this had been on my anti-stackgap todo list as well. >>> >> >>:-) >> >>We have been tolerating this stackgap hack for too long. >> >>Right now linuxlator/i386 is almost stackgap-free. The only remaining >>stackgap is in semctl(2) syscal, which in my opinion it is very >>over/under engineered API, so that there is no a good clean way to do >>the split. At the same time, it's not the one used oftenly, so that I >>can wait when I (or somebody else) is in the right mood to do the >>remaining work. >> >>Other arches/emulation layers are awaiting for somebody (maintainers?) >>to do the work, which will be very easy one, since most popular kernel >>interfaces that work on userland structures/buffers have been split. > > > That's not the only one. All the filesystem system calls use the stackgap to > handle the /compat/linux namespace. Fixing that will not be trivial, as it > will involve teaching namei() to retrieve filenames using a uio or some such > so that names can either be in user space or in kernel space. Either that or > we add native support for prefixes like /compat/foo to namei() by sticking a > pointer to a prefix in struct sysent or some such. Hmm, are you 100% sure? As long as I can see they all use LCONVPATH() macros, which in turn uses linux_emul_convpath() function from linux_util.c. The latter function is stackgap-free. The only commonly-used function "infected" with stackgap in linuxlator is linux_emul_find (and so that CHECKALT*() macroses that use it). My plan was to remove that function entirely, but apparently it is still used in non-i386 versions of linuxlator, so that it can be done yet. -Maxim