From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 01:50:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51A6C16A4CF; Thu, 19 Aug 2004 01:50:50 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id A125E43D64; Thu, 19 Aug 2004 01:50:49 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7J1cHjr063936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 18 Aug 2004 21:38:20 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Birrell Date: Wed, 18 Aug 2004 21:51:32 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_keAJBGsXAWHXWw+" Message-Id: <200408182152.03678.mistry.7@osu.edu> X-Spam-Status: No, hits=-2.3 required=5.0 tests=J_CHICKENPOX_34,PATCH_UNIFIED_DIFF,PGP_SIGNATURE, RCVD_IN_ORBS,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Alan Cox cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2004 01:50:50 -0000 --Boundary-00=_keAJBGsXAWHXWw+ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, I've got a patches that are against 4-STABLE and 6-CURRENT. This fixes= =20 the mmap function so that if the upper process address space is already=20 mmap'd it will start from the bottom and work it's way up. There is probab= ly=20 a much better way than the simple linear search(expensive, but not too bad= =20 with the new findspace implementation), but not being a VM person I don't=20 know. This allows wine and possibly other applications to behave how they need to= =2E =20 I haven't noticed any issues on either my 4.x or 6.x system. Now for the wine stuff. The 4.x patch allows for the june version of wine = to=20 work, but newer versions seem to die with weird sig_action signals. The 6.= x=20 patch allows wine to get to the point where it threads then dies with pthre= ad=20 errors about not being able to allocate the "red zone" I hacked up libpthre= ad=20 just to see what would happen if we can get passed this, and wine works=20 nicely, but the libpthread changes broke other apps so we should probably=20 just stick with mmap change and some modifications to the wine code. I'll= =20 try to work up some wine patches to work around the pthread issue. Hopefully someone can build off this so we can get something in after the=20 freeze. =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBJAekxqA5ziudZT0RAoVCAJsF1ErGopQW/iN2djYmmx7ANuU9GACgorIZ EufCVM28p/arV6u6lg4UIOU=3D =3DXi4i =2D----END PGP SIGNATURE----- --Boundary-00=_keAJBGsXAWHXWw+ Content-Type: text/x-diff; charset="us-ascii"; name="vm_mmap-wine-4-stable.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap-wine-4-stable.patch" --- vm_mmap.c.orig Tue Jul 2 16:06:19 2002 +++ vm_mmap.c Wed Aug 18 16:49:12 2004 @@ -194,6 +194,8 @@ vm_offset_t addr; vm_size_t size, pageoff; vm_prot_t prot, maxprot; + vm_map_t map; + void *handle; int flags, error; int disablexworkaround; @@ -264,8 +266,25 @@ */ else if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && - addr < round_page((vm_offset_t)vms->vm_daddr + maxdsiz))) - addr = round_page((vm_offset_t)vms->vm_daddr + maxdsiz); + addr < round_page((vm_offset_t)vms->vm_daddr + maxdsiz))) { + /* + * XXX So much dirtyness someone who knows what they are doing + * will want to fix this monstrosity. + */ + map = &vms->vm_map; + vm_map_lock(map); + addr = round_page((vm_offset_t)vms->vm_daddr + maxdsiz); + if(vm_map_findspace(map, addr, size, &addr) != 0) { + /* + * since we can't grab the upper process address space bruteforce it. + */ + for(addr = 0;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + } + vm_map_unlock(map); + + } if (flags & MAP_ANON) { /* --Boundary-00=_keAJBGsXAWHXWw+ Content-Type: text/x-diff; charset="us-ascii"; name="vm_mmap-wine-6-current.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap-wine-6-current.patch" --- vm_mmap.c.orig Thu Aug 5 03:04:33 2004 +++ vm_mmap.c Wed Aug 18 21:31:13 2004 @@ -208,6 +208,8 @@ vm_offset_t addr; vm_size_t size, pageoff; vm_prot_t prot, maxprot; + vm_map_t map; + void *handle; int flags, error; off_t pos; @@ -276,9 +278,26 @@ if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && addr < round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)))) + lim_max(td->td_proc, RLIMIT_DATA)))) { + /* + * XXX So much dirtyness someone who knows what they are doing + * will want to fix this monstrosity. + */ + map = &td->td_proc->p_vmspace->vm_map; + vm_map_lock(map); addr = round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)); + lim_max(td->td_proc, RLIMIT_DATA)); + if(vm_map_findspace(map, addr, size, &addr) != 0) { + /* + * since we can't grab the upper process address space bruteforce it. + */ + for(addr = 0;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + } + vm_map_unlock(map); + } + PROC_UNLOCK(td->td_proc); } if (flags & MAP_ANON) { --Boundary-00=_keAJBGsXAWHXWw+--