Date: Thu, 12 Nov 98 11:41:39 -0600 From: "Richard Seaman, Jr." <lists@tar.com> To: "Brian Feldman" <green@unixhelp.org> Cc: "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: RFSIGSHARE ready? Message-ID: <199811121741.LAA14562@ns.tar.com>
next in thread | raw e-mail | index | archive | help
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?199811121741.LAA14562>