From owner-freebsd-current Thu Nov 12 19:07:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10164 for freebsd-current-outgoing; Thu, 12 Nov 1998 19:07:19 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA10018 for ; Thu, 12 Nov 1998 19:07:14 -0800 (PST) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.8.8/8.8.7) with ESMTP id WAA18313; Thu, 12 Nov 1998 22:06:53 -0500 (EST) Date: Thu, 12 Nov 1998 22:06:52 -0500 (EST) From: Brian Feldman X-Sender: green@janus.syracuse.net To: "Richard Seaman, Jr." cc: "current@freebsd.org" Subject: Re: RFSIGSHARE ready? In-Reply-To: <199811121741.LAA14562@ns.tar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Would you mind actually trying moving the signal masks out of struct procsig then? It would be easy, but I don't have time to be testing new kernels, I've got school to deal with. I'm still thinking about how exactly I should deal with the stack mmap problem, but so far, I am doubting it will be problematic at all. When I see that it is problematic ( valid LinuxThreads program using gobs of stack?) I will most definitely implement a change of behavior for this case. Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ On Thu, 12 Nov 1998, Richard Seaman, Jr. wrote: > Brian -- > > I've done some more thinking about making linux threads work in > linux emulation. Here are some thoughts: > > 1) I think you need to take p_sigmask out of your new procsig > structure and put it back into the proc structure. Linux threads > does lots of signal mask manipulation, and I'm pretty sure that > it expects p_sigmask to be "per thread", and not shared among > all the threads. > > 2) linux threads creates stacks for each thread it creates via > mmap. It decides on where to start allocating them using the > following algorithm (I think). > > It gets the stack pointer of the initial thread, > figures the initial thread can get by with 2*STACK_SIZE > bytes (4MB in this case), and then starts allocating > thread user stacks 2*STACK_SIZE below the initial > thread stack. > > I don't pretend to really understand FreeBSD vm, to the following > is just a guess on my part. Maybe someone else can shed more > light on this. > > The problem is that FreeBSD dedicates 64MB for a process stack > (ie. for the initial thread), so that linux threads starts out > mmaping into the initial thread stack region. I don't know > exactly what happens at that point, but it doesn't seem to > be good. > > I'm not sure why FreeBSD mmap allows a mmap into the process > user stack to succeed (but it appears to). > > You could consider patching either linux_mmap or the FreeBSD > mmap to reject attempts to mmap at virtual addresses above > p->p->vmspace->vm_maxaddr. I haven't tried this, so I don't > know if it will work. > > What this would do to an unmodified linux threads implementation > would be (I think) that the first 31 or 32 stack addresses it > tries to create would fail since they are trying to map into > the initial thread stack. But, after that, mmaps should succeed > and maybe the addresses will be ok. You'd loose the ability to > create 31 or 32 threads out of the total 1024 that linux threads > allows, but that wouldn't be the end of the world. > > 3) You need to deal with the fact that linux threads mmaps the > thread stacks with the MAP_GROWSDOWN option. Your choices would > appear to be to re-write the FreeBSD mmap syscall to implement > this feature, or to hack linux_mmap. A hack to linux_mmap that > might work (but its a bad hack) would be that when linux_mmap > detects the MAP_GROWSDOWN option it would expand the size > of the mmap request by STACK_SIZE - INITIAL_STACKSIZE, and > relocate the address requested down by the same amount. > > I haven't tried any of these ideas, so I have no clue if they > will work. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message