Date: Thu, 12 Nov 1998 22:06:52 -0500 (EST) From: Brian Feldman <green@unixhelp.org> To: "Richard Seaman, Jr." <lists@tar.com> Cc: "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: RFSIGSHARE ready? Message-ID: <Pine.BSF.4.05.9811122204160.17981-100000@janus.syracuse.net> In-Reply-To: <199811121741.LAA14562@ns.tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9811122204160.17981-100000>