From owner-freebsd-emulation@FreeBSD.ORG Sun Mar 6 19:06:59 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 225FE106564A for ; Sun, 6 Mar 2011 19:06:59 +0000 (UTC) (envelope-from jandrese@vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id BFBB98FC16 for ; Sun, 6 Mar 2011 19:06:58 +0000 (UTC) Received: from zidane.cc.vt.edu (zidane.cc.vt.edu [198.82.163.227]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id p26J6SWN029847 for ; Sun, 6 Mar 2011 14:06:28 -0500 Received: from mail-vx0-f180.google.com (EHLO mail-vx0-f180.google.com) ([209.85.220.180]) by zidane.cc.vt.edu (MOS 4.2.2-FCS FastPath queued) with ESMTP id OFZ04571; Sun, 06 Mar 2011 14:06:27 -0500 (EST) Received: by mail-vx0-f180.google.com with SMTP id 38so5196091vxc.25 for ; Sun, 06 Mar 2011 11:06:27 -0800 (PST) Received: by 10.52.92.38 with SMTP id cj6mr4205775vdb.254.1299438387265; Sun, 06 Mar 2011 11:06:27 -0800 (PST) Received: from escaflowne.ceyah.org (pool-96-241-179-120.washdc.fios.verizon.net [96.241.179.120]) by mx.google.com with ESMTPS id e20sm1252925vbz.18.2011.03.06.11.06.25 (version=SSLv3 cipher=OTHER); Sun, 06 Mar 2011 11:06:25 -0800 (PST) Date: Sun, 6 Mar 2011 14:06:24 -0500 From: Jason Andresen To: Message-Id: <20110306140624.39c81283.jandrese@vt.edu> In-Reply-To: <27b65be99e21f2e2552163d0224d28c4@ringofsaturn.com> References: <20110224111758.840e6e3e.jandrese@vt.edu> <27b65be99e21f2e2552163d0224d28c4@ringofsaturn.com> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; i386-portbld-freebsd7.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mirapoint-Received-SPF: 209.85.220.180 mail-vx0-f180.google.com jandrese@vt.edu 4 softfail X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A020302.4D73DA49.00AB, actions=TAG SPF X-Junkmail-Status: score=10/50, host=zidane.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020202.4D73DB34.004B,ss=1,fgs=0, ip=96.241.179.120, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: freebsd-emulation@freebsd.org Subject: Re: Call for Testers: VirtualBox 4.0.4 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 19:06:59 -0000 On Sat, 05 Mar 2011 17:40:20 -0600 Rusty Nejdl wrote: > Can you give the 260.19.29 version > of the NVIDIA driver a try? It's a stable version and there's a problem > report to update the nvidia driver that hasn't been committed yet. This > is what mine shows for glxinfo: > > OpenGL vendor string: NVIDIA > Corporation > OpenGL renderer string: GeForce GTX 460/PCI/SSE2 > OpenGL > version string: 4.1.0 NVIDIA 260.19.29 > OpenGL shading language version > string: 4.10 NVIDIA via Cg compiler > > That's about the only idea I have. > The opengl that your card supports is a major rev behind what mine does. > I'm not sure what version VirtualBox requires. I think the OpenGL version difference is mostly about stuff like the number of instructions you can program in a shader program and stuff like that. I don't think it's the issue here. It shouldn't be a surprise that my card is a version behind, it's getting on 5 years old now. Still, it's a very capable card, and simply asking it to get a GL context ready shouldn't crash VirtualBox. Anyway, updating the driver didn't help. It's still failing in exactly the same way, the only difference is now glxinfo reports: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8800 GTX/PCI/SSE2 OpenGL version string: 3.3.0 NVIDIA 260.19.29 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler -- \__/ Jason Andresen -- My opinions are my own. \__/19\__/1A\__/1B\__/ /21\ That's the thing about people who think they hate computers. /2C\ \__/ What they really hate is lousy programmers. __/3B\__/ /41\ -- Larry Niven and Jerry Pournelle in "Oath of Fealty" /4B\__/4C\ \__/51\__/52\__/53\__/54\__/55\__/56\__/57\__/58\__/59\__/5A\__/5B\__/ From owner-freebsd-emulation@FreeBSD.ORG Sun Mar 6 20:56:10 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3294F106566B for ; Sun, 6 Mar 2011 20:56:10 +0000 (UTC) (envelope-from rnejdl@ringofsaturn.com) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [71.252.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id E134E8FC14 for ; Sun, 6 Mar 2011 20:56:09 +0000 (UTC) Received: from ASSP.nospam (tethys [71.252.219.43]) (authenticated bits=0) by tethys.ringofsaturn.com (8.14.4/8.14.4) with ESMTP id p26Ku9ZL053533; Sun, 6 Mar 2011 14:56:09 -0600 (CST) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com ([71.252.219.43] helo=mail.ringofsaturn.com) with IPv4:25 by ASSP.nospam; 6 Mar 2011 14:56:08 -0600 MIME-Version: 1.0 Date: Sun, 06 Mar 2011 14:56:08 -0600 From: Rusty Nejdl To: Jason Andresen Mail-Reply-To: In-Reply-To: <20110306140624.39c81283.jandrese@vt.edu> References: <20110224111758.840e6e3e.jandrese@vt.edu> <27b65be99e21f2e2552163d0224d28c4@ringofsaturn.com> <20110306140624.39c81283.jandrese@vt.edu> Message-ID: X-Sender: rnejdl@ringofsaturn.com User-Agent: Roundcube Webmail/0.6-svn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: Call for Testers: VirtualBox 4.0.4 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 20:56:10 -0000 On Sun, 6 Mar 2011 14:06:24 -0500, Jason Andresen wrote: > On Sat, 05 Mar 2011 17:40:20 -0600 > Rusty Nejdl wrote: > >> Can you give the 260.19.29 version of the NVIDIA driver a try? It's a stable version and there's a problem report to update the nvidia driver that hasn't been committed yet. This is what mine shows for glxinfo: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 460/PCI/SSE2 OpenGL version string: 4.1.0 NVIDIA 260.19.29 OpenGL shading language version string: 4.10 NVIDIA via Cg compiler That's about the only idea I have. The opengl that your card supports is a major rev behind what mine does. I'm not sure what version VirtualBox requires. > I think the OpenGL version difference is mostly about stuff like the number of instructions you can program in a shader program and stuff like that. I don't think it's the issue here. It shouldn't be a surprise that my card is a version behind, it's getting on 5 years old now. Still, it's a very capable card, and simply asking it to get a GL context ready shouldn't crash VirtualBox. Anyway, updating the driver didn't help. It's still failing in exactly the same way, the only difference is now glxinfo reports: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8800 GTX/PCI/SSE2 OpenGL version string: 3.3.0 NVIDIA 260.19.29 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler Jason, Yeah, I know... I was reaching for ideas. I'm not seeing any crashing. I do agree that your card is pretty capable and I just recently upgraded from a 9600 as well. The only issues I've had so far are incompatibilities of software within my virtual machines themselves but my Ubuntu, FreeBSD, and Windows XP vm's all run perfectly with all appropriate levels of acceleration. Rusty Nejdl Links: ------ [1] mailto:rnejdl@ringofsaturn.com From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 7 11:06:57 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4C0F1065670 for ; Mon, 7 Mar 2011 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 781C78FC0C for ; Mon, 7 Mar 2011 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p27B6vZX096915 for ; Mon, 7 Mar 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p27B6ucx096913 for freebsd-emulation@FreeBSD.org; Mon, 7 Mar 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Mar 2011 11:06:56 GMT Message-Id: <201103071106.p27B6ucx096913@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/155238 emulation 20 minute time jumps in VirtualBox o kern/155040 emulation [linux] [patch] Linux recvfrom doesn't handle proto fa o kern/153990 emulation [hyper-v]: Will not install into Hyper-V on Server 200 o kern/153887 emulation [linux] Linux emulator not understand STB_GNU_UNIQUE b o kern/153243 emulation [ibcs2] Seg fault whne running COFF binary using iBCS2 o ports/151714 emulation print/acroread9 not usable due to lack of support in t a bin/150262 emulation [patch] truss(1) -f doesn't follow descendants of the a kern/150186 emulation [parallels] [panic] Parallels Desktop: CDROM disconnec o kern/149168 emulation [linux] [patch] Linux sendmsg / recvmsg / etc fixes fo o ports/148097 emulation [patch] suggested addition to linux_base-* packages to o ports/148096 emulation emulators/linux_base-* can not be built from ports on o kern/147793 emulation [vmware] [panic] cdrom handling, panic, possible race o kern/146237 emulation [linux] Linux binaries not reading directories mounted f kern/144763 emulation [linux] [panic] Kernel panic when start linux binaries p kern/144584 emulation [linprocfs][patch] bogus values in linprocfs o ports/142837 emulation [patch] emulators/linux_base-* packages fails to insta o kern/140156 emulation [linux] cdparanoia fails to read drive data f kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest s ports/136321 emulation x11-toolkits/linux-pango: please update linux based po o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage s kern/133144 emulation [linux] linuxulator 2.6 crashes with nvidias libGL.so. o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/86619 emulation [linux] linux emulator interacts oddly with cp a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/36952 emulation [patch] [linux] ldd(1) command of linux does not work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 31 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 7 13:24:13 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id F0DAD1065670; Mon, 7 Mar 2011 13:24:13 +0000 (UTC) Date: Mon, 7 Mar 2011 13:24:13 +0000 From: Alexander Best To: Chagin Dmitry Message-ID: <20110307132413.GA72267@freebsd.org> References: <20110303212051.GA54978@freebsd.org> <20110304061328.GA4073@dchagin.static.corbina.ru> <20110304110843.GA65337@freebsd.org> <20110304174637.GA8522@dchagin.static.corbina.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110304174637.GA8522@dchagin.static.corbina.ru> Cc: freebsd-emulation@freebsd.org Subject: Re: regarding issues with futexes and multiple threads X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 13:24:14 -0000 On Fri Mar 4 11, Chagin Dmitry wrote: > On Fri, Mar 04, 2011 at 11:08:43AM +0000, Alexander Best wrote: > > On Fri Mar 4 11, Chagin Dmitry wrote: > > > On Thu, Mar 03, 2011 at 09:20:51PM +0000, Alexander Best wrote: > > > > hi there, > > > > > > > > i've been investigating this issue for quite a while now and simply wanted to > > > > post some measurements i did. > > > > > > > > basically there's a massive slowdown when a process triggers a lot of threads > > > > which are doing futex operations. the following example is from darren hart's > > > > futex test suite (performance/). the slowdown seems to SMP related. here are > > > > the measurements running with SMP enabled and with kern.smp.disabled=1: > > > > > > > > > > 1) slowdown is expected behaviour. > > > > even if the slowdown is to be expected, looking at the screenshot with the > > top(1) output it seems obvious that there are issues with the current futex > > implementation. > > > > why do you think it's a problem with the futexes? the screenshot was taken with only one flash site opened. so i assumed having so many npviewer instances in state futex and taking up so much ressources is not normaly behavior. i also added a few printf's at the end of the WAIT and WAKE cases in linux_futex.c. this showed that error is almost always != 0. i'll add a few more printf's, since a few futex related changes have been added to HEAD recently. maybe that reveals more details. cheers. alex > > > > 2) is it possible to run this test suite on FreeBSD? > > > > i used emulators/linux_dist-gentoo-stage3 to compile the testsuite and then ran > > it natively under freebsd. if you want to i can send you the file. it's > > > > futex_wait: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped > > > > ah, tests directly calls sys_futex syscall, so can't be used for umtx/futex comparison :) > It would be great to have the same set of tests to compare the linuxulator threads > and the native. > > -- > Have fun! > chd -- a13x From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 7 15:35:59 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 36AE11065672; Mon, 7 Mar 2011 15:35:59 +0000 (UTC) Date: Mon, 7 Mar 2011 15:35:59 +0000 From: Alexander Best To: Chagin Dmitry Message-ID: <20110307153559.GA94499@freebsd.org> References: <20110303212051.GA54978@freebsd.org> <20110304061328.GA4073@dchagin.static.corbina.ru> <20110304110843.GA65337@freebsd.org> <20110304174637.GA8522@dchagin.static.corbina.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110304174637.GA8522@dchagin.static.corbina.ru> Cc: freebsd-emulation@freebsd.org Subject: Re: regarding issues with futexes and multiple threads X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:35:59 -0000 On Fri Mar 4 11, Chagin Dmitry wrote: > On Fri, Mar 04, 2011 at 11:08:43AM +0000, Alexander Best wrote: > > On Fri Mar 4 11, Chagin Dmitry wrote: > > > On Thu, Mar 03, 2011 at 09:20:51PM +0000, Alexander Best wrote: > > > > hi there, > > > > > > > > i've been investigating this issue for quite a while now and simply wanted to > > > > post some measurements i did. > > > > > > > > basically there's a massive slowdown when a process triggers a lot of threads > > > > which are doing futex operations. the following example is from darren hart's > > > > futex test suite (performance/). the slowdown seems to SMP related. here are > > > > the measurements running with SMP enabled and with kern.smp.disabled=1: > > > > > > > > > > 1) slowdown is expected behaviour. > > > > even if the slowdown is to be expected, looking at the screenshot with the > > top(1) output it seems obvious that there are issues with the current futex > > implementation. > > > > why do you think it's a problem with the futexes? i added the following debug printf's to linux_futex.c: diff --git a/sys/compat/linux/linux_futex.c b/sys/compat/linux/linux_futex.c index b69936c..3d5576f 100644 --- a/sys/compat/linux/linux_futex.c +++ b/sys/compat/linux/linux_futex.c @@ -510,6 +510,8 @@ linux_sys_futex(struct thread *td, struct linux_sys_futex_args *args) } error = futex_wait(f, wp, args->timeout, args->val3); + if (error) + printf("LINUX_FUTEX_WAIT_BITSET finished with error = %d\n", error); break; case LINUX_FUTEX_WAKE: @@ -541,6 +543,8 @@ linux_sys_futex(struct thread *td, struct linux_sys_futex_args *args) } td->td_retval[0] = futex_wake(f, args->val, args->val3); futex_put(f, NULL); + if (error) + printf("LINUX_FUTEX_WAKE_BITSET finished with error = %d\n", error); break; case LINUX_FUTEX_CMP_REQUEUE: @@ -601,6 +605,8 @@ linux_sys_futex(struct thread *td, struct linux_sys_futex_args *args) td->td_retval[0] = futex_requeue(f, args->val, f2, nrwake); futex_put(f2, NULL); futex_put(f, NULL); + if (error) + printf("LINUX_FUTEX_CMP_REQUEUE finished with error = %d\n", error); break; case LINUX_FUTEX_WAKE_OP: @@ -664,6 +670,8 @@ linux_sys_futex(struct thread *td, struct linux_sys_futex_args *args) futex_put(f2, NULL); futex_put(f, NULL); td->td_retval[0] = ret; + if (error) + printf("LINUX_FUTEX_WAKE_OP finished with error = %d\n", error); break; case LINUX_FUTEX_LOCK_PI: ...then i ran chrome with some flash website. this was the dmesg output (well part of it): LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAITL_IBNIUTXS_EFTU TfEiXn_iWsAhIeTd_ BwIiTtShE Te rfrionri s=h ed6 0wi th error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 60 LINUX_FUTEX_WAIT_BITSET finished with error = 4 LINUX_FUTEX_WAIT_BITSET finisLhIeNdU Xw_iFtUhT EeXr_rWoArI T=_ B4IT SET finished with erroLrI N=U X4_F UTEX_WAIT_BITSET finLiIsNhUeXd_ FwUiTtEhX _eWrArIoTr_ B=I T4SE T finished with errLoIrN U=X _4FU TEX_WAIT_BITSET finLiIsNhUeXd_ FwUiTtEhX _eWrArIoTr_ B=I T4SE T finished with erLrIoNrU X=_ F4UT EX_WAIT_BITSET finiLsIhNeUdX _wFiUtThE Xe_rWrAoIrT _=B I4TS ET finished with error = 4 ... running the futex testsuite with #threads 1 and 32 showed no error = * output, but i'll try running the suite with more testcases in a minute. cheers. alex > > > > 2) is it possible to run this test suite on FreeBSD? > > > > i used emulators/linux_dist-gentoo-stage3 to compile the testsuite and then ran > > it natively under freebsd. if you want to i can send you the file. it's > > > > futex_wait: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped > > > > ah, tests directly calls sys_futex syscall, so can't be used for umtx/futex comparison :) > It would be great to have the same set of tests to compare the linuxulator threads > and the native. > > -- > Have fun! > chd -- a13x From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 8 06:30:16 2011 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B081065673 for ; Tue, 8 Mar 2011 06:30:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2448FC18 for ; Tue, 8 Mar 2011 06:30:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p286UG8P008844 for ; Tue, 8 Mar 2011 06:30:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p286UGKU008835; Tue, 8 Mar 2011 06:30:16 GMT (envelope-from gnats) Date: Tue, 8 Mar 2011 06:30:16 GMT Message-Id: <201103080630.p286UGKU008835@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: John Wehle Cc: Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Wehle List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 06:30:16 -0000 The following reply was made to PR kern/149168; it has been noted by GNATS. From: John Wehle To: avg@freebsd.org Cc: rdivacky@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio Date: Tue, 8 Mar 2011 02:32:09 -0500 (EST) Enclosed is yet another slightly tweaked and lightly tested version. I made a bootable amd64 drive which mirrors my existing i386 system so I was able to test these changes on both amd64 and i386. Changes from previous: 1) Include changes to amd64/linux32/linux32_dummy.c. 2) Use PTRIN in LINUX_CMSG_FIRSTHDR and LINUX_CMSG_NXTHDR so linux_socket.c compiles without complaints on amd64. 3) Invoke LINUX_CMSG_NXTHDR with the correct variable (basically I missed a place in my last round of changes). Notes: 1) This has been tested on both i386 and amd64 with Fedora 10 paplay (client) talking to FreeBSD 8.2 pulseaudio (server) over both TCP and UNIX domain sockets. 2) PulseAudio generates the socket name slightly differently between FreeBSD and Linux. When using UNIX domain sockets please set PULSE_SERVER prior to invoking the client application. E.g.: setenv PULSE_SERVER unix:/tmp/pulse-J1eO0ABCS0DM/native where /tmp/pulse-J1eO0ABCS0DM/native is the name of the FreeBSD PulseAudio socket. Someone knowledgeable may be able to muck /usr/compat/linux/etc/pulse/client.conf so this is not necessary. -- John -----------------------8<----------------------------8<------------------ --- ./compat/linux/linux_misc.h.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./compat/linux/linux_misc.h 2011-02-26 22:41:49.000000000 -0500 @@ -37,6 +37,8 @@ * Second arg is a ptr to return the * signal. */ +#define LINUX_PR_GET_KEEPCAPS 7 /* Get drop capabilities on setuid */ +#define LINUX_PR_SET_KEEPCAPS 8 /* Set drop capabilities on setuid */ #define LINUX_PR_SET_NAME 15 /* Set process name. */ #define LINUX_PR_GET_NAME 16 /* Get process name. */ --- ./compat/linux/linux_misc.c.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./compat/linux/linux_misc.c 2011-02-26 22:41:49.000000000 -0500 @@ -1733,6 +1733,87 @@ linux_exit_group(struct thread *td, stru return (0); } +#define _LINUX_CAPABILITY_VERSION 0x19980330 + +struct l_user_cap_header { + l_int version; + l_int pid; +}; + +struct l_user_cap_data { + l_int effective; + l_int permitted; + l_int inheritable; +}; + +int +linux_capget(struct thread *td, struct linux_capget_args *args) +{ + struct l_user_cap_header luch; + struct l_user_cap_data lucd; + int error; + + if (! args->hdrp) + return (EFAULT); + + error = copyin(args->hdrp, &luch, sizeof(luch)); + if (error != 0) + return (error); + + if (luch.version != _LINUX_CAPABILITY_VERSION) { + luch.version = _LINUX_CAPABILITY_VERSION; + error = copyout(&luch, args->hdrp, sizeof(luch)); + if (error) + return (error); + return (EINVAL); + } + + if (luch.pid) + return (EPERM); + + if (args->datap) { + bzero (&lucd, sizeof(lucd)); + error = copyout(&lucd, args->datap, sizeof(lucd)); + } + + return (error); +} + +int +linux_capset(struct thread *td, struct linux_capset_args *args) +{ + struct l_user_cap_header luch; + struct l_user_cap_data lucd; + int error; + + if (! args->hdrp || ! args->datap) + return (EFAULT); + + error = copyin(args->hdrp, &luch, sizeof(luch)); + if (error != 0) + return (error); + + if (luch.version != _LINUX_CAPABILITY_VERSION) { + luch.version = _LINUX_CAPABILITY_VERSION; + error = copyout(&luch, args->hdrp, sizeof(luch)); + if (error) + return (error); + return (EINVAL); + } + + if (luch.pid) + return (EPERM); + + error = copyin(args->datap, &lucd, sizeof(lucd)); + if (error != 0) + return (error); + + if (lucd.effective || lucd.permitted || lucd.inheritable) + return (EPERM); + + return (0); +} + int linux_prctl(struct thread *td, struct linux_prctl_args *args) { @@ -1766,6 +1847,11 @@ linux_prctl(struct thread *td, struct li (void *)(register_t)args->arg2, sizeof(pdeath_signal)); break; + case LINUX_PR_GET_KEEPCAPS: + td->td_retval[0] = 0; + break; + case LINUX_PR_SET_KEEPCAPS: + break; case LINUX_PR_SET_NAME: /* * To be on the safe side we need to make sure to not --- ./compat/linux/linux_socket.h.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./compat/linux/linux_socket.h 2011-03-07 23:40:31.000000000 -0500 @@ -53,6 +53,7 @@ /* Socket-level control message types */ #define LINUX_SCM_RIGHTS 0x01 +#define LINUX_SCM_CREDENTIALS 0x02 /* Ancilliary data object information macros */ @@ -66,13 +67,14 @@ #define LINUX_CMSG_FIRSTHDR(msg) \ ((msg)->msg_controllen >= \ sizeof(struct l_cmsghdr) ? \ - (struct l_cmsghdr *)((msg)->msg_control) : \ + (struct l_cmsghdr *) \ + PTRIN((msg)->msg_control) : \ (struct l_cmsghdr *)(NULL)) #define LINUX_CMSG_NXTHDR(msg, cmsg) \ ((((char *)(cmsg) + \ LINUX_CMSG_ALIGN((cmsg)->cmsg_len) + \ sizeof(*(cmsg))) > \ - (((char *)(msg)->msg_control) + \ + (((char *)PTRIN((msg)->msg_control)) + \ (msg)->msg_controllen)) ? \ (struct l_cmsghdr *) NULL : \ (struct l_cmsghdr *)((char *)(cmsg) + \ --- ./compat/linux/linux_socket.c.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./compat/linux/linux_socket.c 2011-03-07 23:38:21.000000000 -0500 @@ -433,6 +433,8 @@ linux_to_bsd_cmsg_type(int cmsg_type) switch (cmsg_type) { case LINUX_SCM_RIGHTS: return (SCM_RIGHTS); + case LINUX_SCM_CREDENTIALS: + return (SCM_CREDS); } return (-1); } @@ -444,6 +446,8 @@ bsd_to_linux_cmsg_type(int cmsg_type) switch (cmsg_type) { case SCM_RIGHTS: return (LINUX_SCM_RIGHTS); + case SCM_CREDS: + return (LINUX_SCM_CREDENTIALS); } return (-1); } @@ -459,7 +463,7 @@ linux_to_bsd_msghdr(struct msghdr *bhdr, bhdr->msg_iov = PTRIN(lhdr->msg_iov); bhdr->msg_iovlen = lhdr->msg_iovlen; bhdr->msg_control = PTRIN(lhdr->msg_control); - bhdr->msg_controllen = lhdr->msg_controllen; + /* msg_controllen skipped */ bhdr->msg_flags = linux_to_bsd_msg_flags(lhdr->msg_flags); return (0); } @@ -472,7 +476,7 @@ bsd_to_linux_msghdr(const struct msghdr lhdr->msg_iov = PTROUT(bhdr->msg_iov); lhdr->msg_iovlen = bhdr->msg_iovlen; lhdr->msg_control = PTROUT(bhdr->msg_control); - lhdr->msg_controllen = bhdr->msg_controllen; + /* msg_controllen skipped */ /* msg_flags skipped */ return (0); } @@ -1092,6 +1096,7 @@ static int linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) { struct cmsghdr *cmsg; + struct cmsgcred cmcred; struct mbuf *control; struct msghdr msg; struct l_cmsghdr linux_cmsg; @@ -1099,15 +1104,14 @@ linux_sendmsg(struct thread *td, struct struct l_msghdr linux_msg; struct iovec *iov; socklen_t datalen; + struct sockaddr *sa; + sa_family_t sa_family; void *data; int error; error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); if (error) return (error); - error = linux_to_bsd_msghdr(&msg, &linux_msg); - if (error) - return (error); /* * Some Linux applications (ping) define a non-NULL control data @@ -1116,8 +1120,12 @@ linux_sendmsg(struct thread *td, struct * order to handle this case. This should be checked, but allows the * Linux ping to work. */ - if (msg.msg_control != NULL && msg.msg_controllen == 0) - msg.msg_control = NULL; + if (PTRIN(linux_msg.msg_control) != NULL && linux_msg.msg_controllen == 0) + linux_msg.msg_control = PTROUT(NULL); + + error = linux_to_bsd_msghdr(&msg, &linux_msg); + if (error) + return (error); #ifdef COMPAT_LINUX32 error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, @@ -1128,13 +1136,21 @@ linux_sendmsg(struct thread *td, struct if (error) return (error); - if (msg.msg_control != NULL) { + control = NULL; + cmsg = NULL; + + if ((ptr_cmsg = LINUX_CMSG_FIRSTHDR(&linux_msg)) != NULL) { + error = kern_getsockname(td, args->s, &sa, &datalen); + if (error) + goto bad; + sa_family = sa->sa_family; + free(sa, M_SONAME); + error = ENOBUFS; cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); control = m_get(M_WAIT, MT_CONTROL); if (control == NULL) goto bad; - ptr_cmsg = LINUX_CMSG_FIRSTHDR(&msg); do { error = copyin(ptr_cmsg, &linux_cmsg, @@ -1147,28 +1163,58 @@ linux_sendmsg(struct thread *td, struct goto bad; /* - * Now we support only SCM_RIGHTS, so return EINVAL - * in any other cmsg_type + * Now we support only SCM_RIGHTS and SCM_CRED, + * so return EINVAL in any other cmsg_type */ - if ((cmsg->cmsg_type = - linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type)) == -1) - goto bad; + cmsg->cmsg_type = + linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type); cmsg->cmsg_level = linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level); + if (cmsg->cmsg_type == -1 + || cmsg->cmsg_level != SOL_SOCKET) + goto bad; + + /* + * Some applications (e.g. pulseaudio) attempt to + * send ancillary data even if the underlying protocol + * doesn't support it which is not allowed in the + * FreeBSD system call interface. + */ + if (sa_family != AF_UNIX) + continue; + data = LINUX_CMSG_DATA(ptr_cmsg); datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ; + + switch (cmsg->cmsg_type) + { + case SCM_RIGHTS: + break; + + case SCM_CREDS: + data = &cmcred; + datalen = sizeof(cmcred); + + /* + * The lower levels will fill in the structure + */ + bzero(data, datalen); + break; + } + cmsg->cmsg_len = CMSG_LEN(datalen); - data = LINUX_CMSG_DATA(ptr_cmsg); error = ENOBUFS; if (!m_append(control, CMSG_HDRSZ, (c_caddr_t) cmsg)) goto bad; if (!m_append(control, datalen, (c_caddr_t) data)) goto bad; - } while ((ptr_cmsg = LINUX_CMSG_NXTHDR(&msg, ptr_cmsg))); - } else { - control = NULL; - cmsg = NULL; + } while ((ptr_cmsg = LINUX_CMSG_NXTHDR(&linux_msg, ptr_cmsg))); + + if (m_length(control, NULL) == 0) { + m_freem(control); + control = NULL; + } } msg.msg_iov = iov; @@ -1193,9 +1239,11 @@ static int linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args) { struct cmsghdr *cm; + struct cmsgcred *cmcred; struct msghdr msg; struct l_cmsghdr *linux_cmsg = NULL; - socklen_t datalen, outlen, clen; + struct l_ucred linux_ucred; + socklen_t datalen, outlen; struct l_msghdr linux_msg; struct iovec *iov, *uiov; struct mbuf *control = NULL; @@ -1252,39 +1300,35 @@ linux_recvmsg(struct thread *td, struct goto bad; } - if (control) { + outbuf = PTRIN(linux_msg.msg_control); + outlen = 0; + if (control) { linux_cmsg = malloc(L_CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); - outbuf = PTRIN(linux_msg.msg_control); - cm = mtod(control, struct cmsghdr *); - outlen = 0; - clen = control->m_len; - while (cm != NULL) { + msg.msg_control = mtod(control, struct cmsghdr *); + msg.msg_controllen = control->m_len; + + cm = CMSG_FIRSTHDR(&msg); - if ((linux_cmsg->cmsg_type = - bsd_to_linux_cmsg_type(cm->cmsg_type)) == -1) + while (cm != NULL) { + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + if (linux_cmsg->cmsg_type == -1 + || cm->cmsg_level != SOL_SOCKET) { error = EINVAL; goto bad; } + data = CMSG_DATA(cm); datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data; - switch (linux_cmsg->cmsg_type) + switch (cm->cmsg_type) { - case LINUX_SCM_RIGHTS: - if (outlen + LINUX_CMSG_LEN(datalen) > - linux_msg.msg_controllen) { - if (outlen == 0) { - error = EMSGSIZE; - goto bad; - } else { - linux_msg.msg_flags |= - LINUX_MSG_CTRUNC; - goto out; - } - } + case SCM_RIGHTS: if (args->flags & LINUX_MSG_CMSG_CLOEXEC) { fds = datalen / sizeof(int); fdp = data; @@ -1295,11 +1339,40 @@ linux_recvmsg(struct thread *td, struct } } break; + + case SCM_CREDS: + /* + * Currently LOCAL_CREDS is never in + * effect for Linux so no need to worry + * about sockcred + */ + if (datalen != sizeof (*cmcred)) { + error = EMSGSIZE; + goto bad; + } + cmcred = (struct cmsgcred *)data; + bzero(&linux_ucred, sizeof(linux_ucred)); + linux_ucred.pid = cmcred->cmcred_pid; + linux_ucred.uid = cmcred->cmcred_uid; + linux_ucred.gid = cmcred->cmcred_gid; + data = &linux_ucred; + datalen = sizeof(linux_ucred); + break; + } + + if (outlen + LINUX_CMSG_LEN(datalen) > + linux_msg.msg_controllen) { + if (outlen == 0) { + error = EMSGSIZE; + goto bad; + } else { + linux_msg.msg_flags |= + LINUX_MSG_CTRUNC; + goto out; + } } linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen); - linux_cmsg->cmsg_level = - bsd_to_linux_sockopt_level(cm->cmsg_level); error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); if (error) @@ -1312,18 +1385,13 @@ linux_recvmsg(struct thread *td, struct outbuf += LINUX_CMSG_ALIGN(datalen); outlen += LINUX_CMSG_LEN(datalen); - linux_msg.msg_controllen = outlen; - if (CMSG_SPACE(datalen) < clen) { - clen -= CMSG_SPACE(datalen); - cm = (struct cmsghdr *) - ((caddr_t)cm + CMSG_SPACE(datalen)); - } else - cm = NULL; + cm = CMSG_NXTHDR(&msg, cm); } } out: + linux_msg.msg_controllen = outlen; error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg)); bad: --- ./i386/linux/linux_dummy.c.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./i386/linux/linux_dummy.c 2011-02-26 22:41:49.000000000 -0500 @@ -57,8 +57,6 @@ DUMMY(vm86); DUMMY(query_module); DUMMY(nfsservctl); DUMMY(rt_sigqueueinfo); -DUMMY(capget); -DUMMY(capset); DUMMY(sendfile); /* different semantics */ DUMMY(setfsuid); DUMMY(setfsgid); --- ./i386/linux/syscalls.master.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./i386/linux/syscalls.master 2011-02-26 22:41:49.000000000 -0500 @@ -329,8 +329,8 @@ l_uid16_t uid, l_gid16_t gid); } 183 AUE_GETCWD STD { int linux_getcwd(char *buf, \ l_ulong bufsize); } -184 AUE_CAPGET STD { int linux_capget(void); } -185 AUE_CAPSET STD { int linux_capset(void); } +184 AUE_CAPGET STD { int linux_capget(void *hdrp, void *datap); } +185 AUE_CAPSET STD { int linux_capset(void *hdrp, const void *datap); } 186 AUE_NULL STD { int linux_sigaltstack(l_stack_t *uss, \ l_stack_t *uoss); } 187 AUE_SENDFILE STD { int linux_sendfile(void); } --- ./amd64/linux32/linux32_dummy.c.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./amd64/linux32/linux32_dummy.c 2011-03-07 23:36:02.000000000 -0500 @@ -54,8 +54,6 @@ DUMMY(sysfs); DUMMY(query_module); DUMMY(nfsservctl); DUMMY(rt_sigqueueinfo); -DUMMY(capget); -DUMMY(capset); DUMMY(sendfile); DUMMY(setfsuid); DUMMY(setfsgid); --- ./amd64/linux32/syscalls.master.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 +++ ./amd64/linux32/syscalls.master 2011-02-26 22:41:49.000000000 -0500 @@ -327,8 +327,8 @@ l_uid16_t uid, l_gid16_t gid); } 183 AUE_GETCWD STD { int linux_getcwd(char *buf, \ l_ulong bufsize); } -184 AUE_CAPGET STD { int linux_capget(void); } -185 AUE_CAPSET STD { int linux_capset(void); } +184 AUE_CAPGET STD { int linux_capget(void *hdrp, void *datap); } +185 AUE_CAPSET STD { int linux_capset(void *hdrp, const void *datap); } 186 AUE_NULL STD { int linux_sigaltstack(l_stack_t *uss, \ l_stack_t *uoss); } 187 AUE_SENDFILE STD { int linux_sendfile(void); } ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 8 06:49:17 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B9A71065672; Tue, 8 Mar 2011 06:49:17 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 263DB8FC14; Tue, 8 Mar 2011 06:49:16 +0000 (UTC) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 2F2ACC9D95; Tue, 8 Mar 2011 09:49:14 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.22.99] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 306540133; Tue, 08 Mar 2011 09:49:14 +0300 Received: from dchagin.static.corbina.ru (localhost [127.0.0.1]) by dchagin.static.corbina.ru (8.14.4/8.14.4) with ESMTP id p286nDf2004249; Tue, 8 Mar 2011 09:49:13 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.4/8.14.4/Submit) id p286n8cX004248; Tue, 8 Mar 2011 09:49:08 +0300 (MSK) (envelope-from dchagin) Date: Tue, 8 Mar 2011 09:49:08 +0300 From: Chagin Dmitry To: Alexander Best Message-ID: <20110308064908.GA4198@dchagin.static.corbina.ru> References: <20110303212051.GA54978@freebsd.org> <20110304061328.GA4073@dchagin.static.corbina.ru> <20110304110843.GA65337@freebsd.org> <20110304174637.GA8522@dchagin.static.corbina.ru> <20110307153559.GA94499@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20110307153559.GA94499@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-emulation@freebsd.org Subject: Re: regarding issues with futexes and multiple threads X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 06:49:17 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2011 at 03:35:59PM +0000, Alexander Best wrote: > On Fri Mar 4 11, Chagin Dmitry wrote: > break; > =20 > case LINUX_FUTEX_LOCK_PI: >=20 > ...then i ran chrome with some flash website. this was the dmesg output (= well > part of it): >=20 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAITL_IBNIUTXS_EFTU TfEiXn_iWsAhIeTd_ BwIiTtShE Te rfrionri s= =3Dh ed6 0wi > th error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 > LINUX_FUTEX_WAIT_BITSET finished with error =3D 60 ETIMEDOUT, EINTR. it is expected. > LINUX_FUTEX_WAIT_BITSET finished with error =3D 4 > LINUX_FUTEX_WAIT_BITSET finisLhIeNdU Xw_iFtUhT EeXr_rWoArI T=3D_ B4IT > SET finished with erroLrI N=3DU X4_F > UTEX_WAIT_BITSET finLiIsNhUeXd_ FwUiTtEhX _eWrArIoTr_ B=3DI T4SE > T finished with errLoIrN U=3DX _4FU > TEX_WAIT_BITSET finLiIsNhUeXd_ FwUiTtEhX _eWrArIoTr_ B=3DI T4SE > T finished with erLrIoNrU X=3D_ F4UT > EX_WAIT_BITSET finiLsIhNeUdX _wFiUtThE Xe_rWrAoIrT _=3DB I4TS > ET finished with error =3D 4 >=20 > ... running the futex testsuite with #threads 1 and 32 showed no error = =3D * > output, but i'll try running the suite with more testcases in a minute. >=20 --=20 Have fun! chd --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk110WQACgkQ0t2Tb3OO/O0gHwCeIrve8dUnBGV3qXantx3AzsWg Z/UAnRzYNNEdy5K2RK81zxFq6aIp0rMC =8QpU -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 9 05:08:13 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC36C1065670; Wed, 9 Mar 2011 05:08:13 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8DB8FC0C; Wed, 9 Mar 2011 05:08:13 +0000 (UTC) Received: by iyj12 with SMTP id 12so207170iyj.13 for ; Tue, 08 Mar 2011 21:08:12 -0800 (PST) Received: by 10.43.54.142 with SMTP id vu14mr7430009icb.384.1299647292706; Tue, 08 Mar 2011 21:08:12 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id wo11sm495779icb.20.2011.03.08.21.08.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 21:08:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Juergen Lock" References: <201102211924.p1LJOPuw039863@triton8.kn-bremen.de> <20110221223949.GA53037@triton8.kn-bremen.de> Date: Tue, 08 Mar 2011 23:08:09 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20110221223949.GA53037@triton8.kn-bremen.de> User-Agent: Opera Mail/11.01 (FreeBSD) Cc: freebsd-emulation@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Panic from linux emulation (flashplugin) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 05:08:13 -0000 Well it started happening again. Basically what I did was rebuild all of ports which downgraded my nvidia driver. I was getting consistent crashes in youtube after this happened. I upgraded my nvidia driver to 260.19.44 by modifying the port and now I can't get it to crash anymore. *HOWEVER* This may or may not be unrelated -- I'm running opera and have a youtube video hidden in another tab. I have upgraded my nvidia driver but didn't reboot, just removed the kernel module and started X again. For some reason the Youtube video in the hidden tab is able to be seen when I put my terminal over the area where it would be if it was in the active tab. http://feld.me/stuff/flash_bug.png is an example of it. I haven't yet rebooted to see what happens on a clean boot, but this is certainly interesting... perhaps bad flash/linuxulator behavior that doesn't trip a panic in the newer nvidia drivers? Weird stuff either way... Now that I have seemingly figured out the combination to a crash I'll see if I can catch one on the console and have something worthwhile to report. Regards, Mark From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 10 10:00:28 2011 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F4E6106566B for ; Thu, 10 Mar 2011 10:00:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D80278FC0C for ; Thu, 10 Mar 2011 10:00:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2AA0RBZ054139 for ; Thu, 10 Mar 2011 10:00:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2AA0Rx8054101; Thu, 10 Mar 2011 10:00:27 GMT (envelope-from gnats) Date: Thu, 10 Mar 2011 10:00:27 GMT Message-Id: <201103101000.p2AA0Rx8054101@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 10:00:28 -0000 The following reply was made to PR kern/149168; it has been noted by GNATS. From: Andriy Gapon To: John Wehle Cc: rdivacky@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio Date: Thu, 10 Mar 2011 11:54:31 +0200 on 08/03/2011 09:32 John Wehle said the following: > Enclosed is yet another slightly tweaked and lightly tested version. > > I made a bootable amd64 drive which mirrors my existing i386 system > so I was able to test these changes on both amd64 and i386. > > Changes from previous: > > 1) Include changes to amd64/linux32/linux32_dummy.c. > > 2) Use PTRIN in LINUX_CMSG_FIRSTHDR and LINUX_CMSG_NXTHDR so > linux_socket.c compiles without complaints on amd64. > > 3) Invoke LINUX_CMSG_NXTHDR with the correct variable (basically > I missed a place in my last round of changes). Thanks a lot! This patch works as expected for me. Unless anybody objects or wants to hold this patch for further reviewing I will try to commit it this coming weekend. > Notes: > > 1) This has been tested on both i386 and amd64 with Fedora 10 paplay > (client) talking to FreeBSD 8.2 pulseaudio (server) over both TCP > and UNIX domain sockets. > > 2) PulseAudio generates the socket name slightly differently between > FreeBSD and Linux. When using UNIX domain sockets please set > PULSE_SERVER prior to invoking the client application. E.g.: > > setenv PULSE_SERVER unix:/tmp/pulse-J1eO0ABCS0DM/native > > where /tmp/pulse-J1eO0ABCS0DM/native is the name of the FreeBSD > PulseAudio socket. Someone knowledgeable may be able to muck > > /usr/compat/linux/etc/pulse/client.conf > > so this is not necessary. Looks like the pulseaudio developers changed their mind about the separator somewhere between versions 0.9.14 and 0.9.21. If we could find a more recent package for f10 that would help. Not sure if a package from later fedora versions would work. -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 10 11:41:09 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D85401065676 for ; Thu, 10 Mar 2011 11:41:09 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8327A8FC15 for ; Thu, 10 Mar 2011 11:41:09 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1554E8.dip.t-dialin.net [91.21.84.232]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id A3D4584400E; Thu, 10 Mar 2011 12:41:04 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5091327B5; Thu, 10 Mar 2011 12:41:01 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p2ABeobe001914; Thu, 10 Mar 2011 12:40:50 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 10 Mar 2011 12:40:50 +0100 Message-ID: <20110310124050.12625ar9uhfio7c4@webmail.leidinger.net> Date: Thu, 10 Mar 2011 12:40:50 +0100 From: Alexander Leidinger To: John Wehle References: <201103080630.p286UGKU008835@freefall.freebsd.org> In-Reply-To: <201103080630.p286UGKU008835@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: A3D4584400E.A75CE X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.951, required 6, autolearn=disabled, J_CHICKENPOX_47 0.60, RDNS_NONE 1.27, TW_CV 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1300362065.66046@nGiF8dxcpBW8GuqBJwVRGw X-EBL-Spam-Status: No Cc: freebsd-emulation@FreeBSD.org Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 11:41:09 -0000 Quoting John Wehle (from Tue, 8 Mar 2011 06:30:16 GMT): > --- ./compat/linux/linux_misc.c.ORIGINAL 2010-12-21 12:09:25.000000000 -0500 > +++ ./compat/linux/linux_misc.c 2011-02-26 22:41:49.000000000 -0500 > @@ -1733,6 +1733,87 @@ linux_exit_group(struct thread *td, stru > return (0); > } > > +#define _LINUX_CAPABILITY_VERSION 0x19980330 > + > +struct l_user_cap_header { > + l_int version; > + l_int pid; > +}; > + > +struct l_user_cap_data { > + l_int effective; > + l_int permitted; > + l_int inheritable; > +}; You zero the data part in capget. Does this mean that the programs gets told that we are not able to do the right thing, or gets the program tricked into thinking we are doing the right thing (= security hole)? Please add comments to document what they are supposed to do if set. > +int > +linux_capget(struct thread *td, struct linux_capget_args *args) > +{ > + struct l_user_cap_header luch; > + struct l_user_cap_data lucd; > + int error; > + > + if (! args->hdrp) > + return (EFAULT); > + > + error = copyin(args->hdrp, &luch, sizeof(luch)); > + if (error != 0) > + return (error); > + > + if (luch.version != _LINUX_CAPABILITY_VERSION) { > + luch.version = _LINUX_CAPABILITY_VERSION; > + error = copyout(&luch, args->hdrp, sizeof(luch)); Does linux do the same? I'm a little bit surprised that the kernel does not answer in the same format as the userland requests (but if the API is defined this way...). > + if (error) > + return (error); > + return (EINVAL); > + } > + > + if (luch.pid) > + return (EPERM); > + > + if (args->datap) { > + bzero (&lucd, sizeof(lucd)); > + error = copyout(&lucd, args->datap, sizeof(lucd)); > + } > + > + return (error); > +} > + > +int > +linux_capset(struct thread *td, struct linux_capset_args *args) > +{ > + struct l_user_cap_header luch; > + struct l_user_cap_data lucd; > + int error; > + > + if (! args->hdrp || ! args->datap) Style: please make explicit tests instead of negations. > + return (EFAULT); > + > + error = copyin(args->hdrp, &luch, sizeof(luch)); > + if (error != 0) > + return (error); > + > + if (luch.version != _LINUX_CAPABILITY_VERSION) { > + luch.version = _LINUX_CAPABILITY_VERSION; > + error = copyout(&luch, args->hdrp, sizeof(luch)); > + if (error) > + return (error); > + return (EINVAL); > + } > + > + if (luch.pid) > + return (EPERM); > + > + error = copyin(args->datap, &lucd, sizeof(lucd)); > + if (error != 0) > + return (error); > + > + if (lucd.effective || lucd.permitted || lucd.inheritable) > + return (EPERM); How does the userland interprete EPERM? > + return (0); > +} > + > int > linux_prctl(struct thread *td, struct linux_prctl_args *args) > { > @@ -459,7 +463,7 @@ linux_to_bsd_msghdr(struct msghdr *bhdr, > bhdr->msg_iov = PTRIN(lhdr->msg_iov); > bhdr->msg_iovlen = lhdr->msg_iovlen; > bhdr->msg_control = PTRIN(lhdr->msg_control); > - bhdr->msg_controllen = lhdr->msg_controllen; > + /* msg_controllen skipped */ Please extend the comment to explain why. > bhdr->msg_flags = linux_to_bsd_msg_flags(lhdr->msg_flags); > return (0); > } > @@ -472,7 +476,7 @@ bsd_to_linux_msghdr(const struct msghdr > lhdr->msg_iov = PTROUT(bhdr->msg_iov); > lhdr->msg_iovlen = bhdr->msg_iovlen; > lhdr->msg_control = PTROUT(bhdr->msg_control); > - lhdr->msg_controllen = bhdr->msg_controllen; > + /* msg_controllen skipped */ Same as above. > /* msg_flags skipped */ And in case you know why they are skipped, it would be nice if you could extend this comment too while you are here. :) > return (0); > } > @@ -1295,11 +1339,40 @@ linux_recvmsg(struct thread *td, struct > } > } > break; > + > + case SCM_CREDS: > + /* > + * Currently LOCAL_CREDS is never in > + * effect for Linux so no need to worry > + * about sockcred > + */ Is there a way to check this here and fail (either with an appropriate error return or a kernel panic if this is more appropriate... I'm not sure I have the big picture here)? > + if (datalen != sizeof (*cmcred)) { > + error = EMSGSIZE; > + goto bad; > + } > --- ./i386/linux/syscalls.master.ORIGINAL 2010-12-21 > 12:09:25.000000000 -0500 > +++ ./i386/linux/syscalls.master 2011-02-26 22:41:49.000000000 -0500 > @@ -329,8 +329,8 @@ > l_uid16_t uid, l_gid16_t gid); } > 183 AUE_GETCWD STD { int linux_getcwd(char *buf, \ > l_ulong bufsize); } > -184 AUE_CAPGET STD { int linux_capget(void); } > -185 AUE_CAPSET STD { int linux_capset(void); } > +184 AUE_CAPGET STD { int linux_capget(void *hdrp, void *datap); } > +185 AUE_CAPSET STD { int linux_capset(void *hdrp, const void *datap); } A quick search tells that the API is defined as cap_user_header_t and cap_user_data_t and not "void *". It may be the case that in the end those are defined to "void *" (I didn't check), but it would be nice if you could use apropriate l_cap_user_header_t and l_cap_user_data_t. > 186 AUE_NULL STD { int linux_sigaltstack(l_stack_t *uss, \ > l_stack_t *uoss); } > 187 AUE_SENDFILE STD { int linux_sendfile(void); } > --- ./amd64/linux32/syscalls.master.ORIGINAL 2010-12-21 > 12:09:25.000000000 -0500 > +++ ./amd64/linux32/syscalls.master 2011-02-26 22:41:49.000000000 -0500 > @@ -327,8 +327,8 @@ > l_uid16_t uid, l_gid16_t gid); } > 183 AUE_GETCWD STD { int linux_getcwd(char *buf, \ > l_ulong bufsize); } > -184 AUE_CAPGET STD { int linux_capget(void); } > -185 AUE_CAPSET STD { int linux_capset(void); } > +184 AUE_CAPGET STD { int linux_capget(void *hdrp, void *datap); } > +185 AUE_CAPSET STD { int linux_capset(void *hdrp, const void *datap); } The same here. > 186 AUE_NULL STD { int linux_sigaltstack(l_stack_t *uss, \ > l_stack_t *uoss); } > 187 AUE_SENDFILE STD { int linux_sendfile(void); } Thanks a lot for working on this, Alexander. -- All his life he has looked away... to the horizon, to the sky, to the future. Never his mind on where he was, on what he was doing. -- Yoda http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 10 17:06:39 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A572106564A for ; Thu, 10 Mar 2011 17:06:39 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E4F3F8FC13 for ; Thu, 10 Mar 2011 17:06:38 +0000 (UTC) Received: by gwb15 with SMTP id 15so591052gwb.13 for ; Thu, 10 Mar 2011 09:06:37 -0800 (PST) Received: by 10.43.54.210 with SMTP id vv18mr10548178icb.103.1299776797709; Thu, 10 Mar 2011 09:06:37 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id 8sm2687547iba.16.2011.03.10.09.06.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 09:06:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-emulation@freebsd.org References: <4D6B5F58.40201@freebsd.org> Date: Thu, 10 Mar 2011 11:06:34 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <4D6B5F58.40201@freebsd.org> User-Agent: Opera Mail/11.01 (FreeBSD) Subject: Re: Call for Testers: VirtualBox 4.0.4 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:06:39 -0000 I'm having issues with Virtualbox on my Desktop at home. I'm trying to install a new VM (Windows 7) and the iso is over NFS. It starts booting in the installer, screen resizes, an BAM it crashes. I'm running nvidia on the desktop with driver version 260.19.44 Here's a link to my log: http://feld.me/stuff/freebsd/vbox/Windows%207-2011-03-10-10-39-35.log Regards, Mark From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 10 17:14:50 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFF51065675 for ; Thu, 10 Mar 2011 17:14:50 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E80508FC14 for ; Thu, 10 Mar 2011 17:14:49 +0000 (UTC) Received: by gxk7 with SMTP id 7so830169gxk.13 for ; Thu, 10 Mar 2011 09:14:49 -0800 (PST) Received: by 10.43.50.196 with SMTP id vf4mr8358865icb.523.1299777288536; Thu, 10 Mar 2011 09:14:48 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id uf10sm2391995icb.17.2011.03.10.09.14.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 09:14:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-emulation@freebsd.org References: <4D6B5F58.40201@freebsd.org> Date: Thu, 10 Mar 2011 11:14:45 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.01 (FreeBSD) Subject: Re: Call for Testers: VirtualBox 4.0.4 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:14:50 -0000 Whoa! I finally got it working! Funny how you think of new ideas after you send off an email.... The VM's hard disk was on zfs and I had "copies=2" set. I disabled this, created a fresh VM, and now it lets me into the installer. Virtualbox apparently does not like ZFS's copies feature. Regards, Mark From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 10 23:06:17 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 948C11065737 for ; Thu, 10 Mar 2011 23:06:16 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8118FC17 for ; Thu, 10 Mar 2011 23:06:16 +0000 (UTC) Received: by iwn33 with SMTP id 33so2457113iwn.13 for ; Thu, 10 Mar 2011 15:06:16 -0800 (PST) Received: by 10.42.156.70 with SMTP id y6mr1860045icw.524.1299798375999; Thu, 10 Mar 2011 15:06:15 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id gy41sm2880937ibb.23.2011.03.10.15.06.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 15:06:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-emulation@freebsd.org References: <4D6B5F58.40201@freebsd.org> Date: Thu, 10 Mar 2011 17:06:12 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.01 (FreeBSD) Subject: Re: Call for Testers: VirtualBox 4.0.4 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 23:06:17 -0000 On Thu, 10 Mar 2011 11:14:45 -0600, Mark Felder wrote: > Whoa! I finally got it working! Funny how you think of new ideas after > you send off an email.... > The VM's hard disk was on zfs and I had "copies=2" set. I disabled > this, created a fresh VM, and now it lets me into the installer. > Virtualbox apparently does not like ZFS's copies feature. I'm going to have to take this back. I was distracted, came back and tried to continue farther in the installer. It crashed again and is repeating that same behavior. I'm not sure were to go from here. Regards, Mark From owner-freebsd-emulation@FreeBSD.ORG Sat Mar 12 06:54:40 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F5B106566B for ; Sat, 12 Mar 2011 06:54:40 +0000 (UTC) (envelope-from john@feith.com) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) by mx1.freebsd.org (Postfix) with ESMTP id 348628FC0A for ; Sat, 12 Mar 2011 06:54:39 +0000 (UTC) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.14.4+Sun/8.12.9) with ESMTP id p2C6fbGr025424; Sat, 12 Mar 2011 01:41:38 -0500 (EST) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.13.8+Sun/8.13.8) with ESMTP id p2C7lobw011446; Sat, 12 Mar 2011 02:47:50 -0500 (EST) Received: (from john@localhost) by jwlab.FEITH.COM (8.13.8+Sun/8.13.8/Submit) id p2C7lnRO011445; Sat, 12 Mar 2011 02:47:49 -0500 (EST) Date: Sat, 12 Mar 2011 02:47:49 -0500 (EST) From: John Wehle Message-Id: <201103120747.p2C7lnRO011445@jwlab.FEITH.COM> To: alexander@leidinger.net MIME-Version: 1.0 Content-Type: text/plain X-DCC--Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 X-Archived: cashew Cc: freebsd-emulation@FreeBSD.org Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 06:54:40 -0000 >> +struct l_user_cap_data { >> + l_int effective; >> + l_int permitted; >> + l_int inheritable; >> +}; > > You zero the data part in capget. Does this mean that the programs > gets told that we are not able to do the right thing, or gets the > program tricked into thinking we are doing the right thing (= security > hole)? I did say in the patch that the cap routines were NO-OP stubs. A full implementation is probably a fair amount of work (and not something I'm looking to do at this time). Note that these stubs are only necessary to run the Linux pulseaudio server ... they're not necessary for the pulseaudio client library so perhaps the best course of action is to skip them for the time being. Some example Linux capabilities are: CAP_MKNOD Create special files using mknod(2). CAP_NET_RAW Use RAW and PACKET sockets. CAP_SYS_BOOT Use reboot(2) and kexec_load(2). so by having capget return zero for the bits we're saying to the caller that the program does not have the necessary permissions to perform these tasks. The truth of course is the program may be able to do these things if it tries (depending on the results of the FreeBSD security checks) since currently Linux capabilities are not checked / enforced by the FreeBSD kernel. > Please add comments to document what they are supposed to do if set. Happy to add some comments to the code if you feel it's useful to continue with capget, capset, prctl PR_GET_KEEPCAPS, and prctl PR_SET_KEEPCAPS. If you feel that at this time you'd prefer to skip them due to potential security concerns, then that's fine too. >> + if (luch.version != _LINUX_CAPABILITY_VERSION) { >> + luch.version = _LINUX_CAPABILITY_VERSION; >> + error = copyout(&luch, args->hdrp, sizeof(luch)); > > Does linux do the same? I'm a little bit surprised that the kernel > does not answer in the same format as the userland requests The man page at: http://www.kernel.org/doc/man-pages/online/pages/man2/capget.2.html says: The calls will fail with the error EINVAL, and set the version field of hdrp to the kernel preferred value of _LINUX_CAPABILITY_VERSION_? when an unsupported version value is specified. In this way, one can probe what the current preferred capability revision is. so yes, I believe the implementation in the patch is correct in this regard. >> + if (lucd.effective || lucd.permitted || lucd.inheritable) >> + return (EPERM); > > How does the userland interprete EPERM? I'm not sure I understand your question. The manual page says: EPERM An attempt was made to add a capability to the Permitted set, or to set a capability in the Effective or Inheritable sets that is not in the Permitted set. Since the current implementation has minimum functionality we return EPERM if the program attempts to add or set any capabilities. >>> +184 AUE_CAPGET STD { int linux_capget(void *hdrp, void *datap); } >>> +185 AUE_CAPSET STD { int linux_capset(void *hdrp, const void *datap); } > > A quick search tells that the API is defined as cap_user_header_t and > cap_user_data_t and not "void *". It may be the case that in the end > those are defined to "void *" (I didn't check), but it would be nice > if you could use apropriate l_cap_user_header_t and l_cap_user_data_t. The first field in cap_user_header_t specifies a version number. I believe the rest of the layout of the header and data structures can depend on which version is requested. The manual page referenced above says: Not only are these system calls specific to Linux, but the kernel API is likely to change and use of these functions (in particular the format of the cap_user_*_t types) is subject to extension with each kernel revision, but old programs will keep working. Since conceptually the structures passed to the system call can vary depending on the version and it's possible for the kernel code to support more than one version, it seem appropriate to me to use void pointers which are cast as necessary in the kernel code. Granted the implementation I supplied only currently implements version 1 of the Linux API. I can add some comments to the capget / capset code mentioning the reason for the void pointers or if you feel strongly about it I can get rid of the void pointers. >> + case SCM_CREDS: >> + /* >> + * Currently LOCAL_CREDS is never in >> + * effect for Linux so no need to worry >> + * about sockcred >> + */ > > Is there a way to check this here and fail (either with an appropriate > error return or a kernel panic if this is more appropriate... I'm not > sure I have the big picture here)? I have a basic sanity check in the code which is: if (datalen != sizeof (*cmcred)) { error = EMSGSIZE; goto bad; } The problem is that unix domain sockets support two different ways of sending credentials (setsockopt LOCAL_CRED and sendmsg with SCM_CREDS). They both use the same msg type, however they each have their own unique structure. If setsockopt LOCAL_CRED is in effect for the Linux program, then the data supplied with the SCM_CREDS needs to be converted differently ... currently a nonissue since at the moment I believe the FreeBSD Linux layer doesn't support LOCAL_CRED (actually I don't know if Linux even supports LOCAL_CRED). I'm happy to take care of the style issues and add comments in some of the other places you mentioned. Let me know if there are any other questions and whether to keep the capabilities stuff as part of the patch. Once you tell me how to proceed I'll put together another patch. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-emulation@FreeBSD.ORG Sat Mar 12 15:42:35 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63DA0106564A for ; Sat, 12 Mar 2011 15:42:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id DD3E98FC0A for ; Sat, 12 Mar 2011 15:42:34 +0000 (UTC) Received: from outgoing.leidinger.net (p5B15640F.dip.t-dialin.net [91.21.100.15]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 79F8984400E; Sat, 12 Mar 2011 16:42:29 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 90C7629E9; Sat, 12 Mar 2011 16:42:25 +0100 (CET) Date: Sat, 12 Mar 2011 16:42:24 +0100 From: Alexander Leidinger To: John Wehle Message-ID: <20110312164224.000010cd@unknown> In-Reply-To: <201103120747.p2C7lnRO011445@jwlab.FEITH.COM> References: <201103120747.p2C7lnRO011445@jwlab.FEITH.COM> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 79F8984400E.A6035 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.313, required 6, autolearn=disabled, ALL_TRUSTED -1.00, J_CHICKENPOX_47 0.60, TW_CV 0.08, T_FRT_STOCK2 0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1300549349.99665@DNDmwBQO4WOOvwWsTyBYUw X-EBL-Spam-Status: No Cc: freebsd-emulation@FreeBSD.org Subject: Re: kern/149168: [linux] [patch] Linux sendmsg / recvmsg / etc fixes for pulseaudio X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 15:42:35 -0000 On Sat, 12 Mar 2011 02:47:49 -0500 (EST) John Wehle wrote: > >> +struct l_user_cap_data { > >> + l_int effective; > >> + l_int permitted; > >> + l_int inheritable; > >> +}; > > > > You zero the data part in capget. Does this mean that the programs > > gets told that we are not able to do the right thing, or gets the > > program tricked into thinking we are doing the right thing (= > > security hole)? > > I did say in the patch that the cap routines were NO-OP stubs. A full Yes, but what does it mean? A NO-OP can be to tell "I did what you requested" but in reality it was "I did nothing". It can also be that the NO-OP result is an answer as in "you are not allowed to do that or the action you requested did not succeed". Your answer below looks like it is OK to proceed here. > implementation is probably a fair amount of work (and not something > I'm looking to do at this time). Note that these stubs are only > necessary to run the Linux pulseaudio server ... they're not > necessary for the pulseaudio client library so perhaps the best > course of action is to skip them for the time being. > > Some example Linux capabilities are: > > CAP_MKNOD Create special files using mknod(2). > > CAP_NET_RAW Use RAW and PACKET sockets. > > CAP_SYS_BOOT Use reboot(2) and kexec_load(2). > > so by having capget return zero for the bits we're saying to the > caller that the program does not have the necessary permissions to > perform these tasks. The truth of course is the program may be able This is what I needed to know. "You can not do anything" is a good NO-OP implementation of this security related API. > to do these things if it tries (depending on the results of the > FreeBSD security checks) since currently Linux capabilities are not > checked / enforced by the FreeBSD kernel. > > > Please add comments to document what they are supposed to do if set. > > Happy to add some comments to the code if you feel it's useful to > continue with capget, capset, prctl PR_GET_KEEPCAPS, and prctl > PR_SET_KEEPCAPS. Yes, I think it is useful to commit this. It's a step forward and permits those which "feel to scratch what's itching them in this area" to proceed. > If you feel that at this time you'd prefer to skip them due to > potential security concerns, then that's fine too. > > >> + if (luch.version != _LINUX_CAPABILITY_VERSION) { > >> + luch.version = _LINUX_CAPABILITY_VERSION; > >> + error = copyout(&luch, args->hdrp, sizeof(luch)); > > > > Does linux do the same? I'm a little bit surprised that the kernel > > does not answer in the same format as the userland requests > > The man page at: > > http://www.kernel.org/doc/man-pages/online/pages/man2/capget.2.html > > says: > > The calls will fail with the error EINVAL, and set the version field > of hdrp to the kernel preferred value of _LINUX_CAPABILITY_VERSION_? > when an unsupported version value is specified. In this way, one > can probe what the current preferred capability revision is. > > so yes, I believe the implementation in the patch is correct in this > regard. I agree with you. > >> + if (lucd.effective || lucd.permitted || lucd.inheritable) > >> + return (EPERM); > > > > How does the userland interprete EPERM? > > I'm not sure I understand your question. The manual page says: > > EPERM An attempt was made to add a capability to the Permitted set, > or to set a capability in the Effective or Inheritable sets > that is not in the Permitted set. > > Since the current implementation has minimum functionality we return > EPERM if the program attempts to add or set any capabilities. Good. Even better would be to print out that a program tried to set an unsupported capability (like we do e.g. for unsupported ioctl's). If you do not have the the spare time to handle this, I will add something like this myself. > >>> +184 AUE_CAPGET STD { int linux_capget(void *hdrp, void > >>> *datap); } +185 AUE_CAPSET STD { int linux_capset(void *hdrp, > >>> const void *datap); } > > > > A quick search tells that the API is defined as cap_user_header_t > > and cap_user_data_t and not "void *". It may be the case that in > > the end those are defined to "void *" (I didn't check), but it > > would be nice if you could use apropriate l_cap_user_header_t and > > l_cap_user_data_t. > > The first field in cap_user_header_t specifies a version number. I > believe the rest of the layout of the header and data structures can > depend on which version is requested. The manual page referenced > above says: > > Not only are these system calls specific to Linux, but the kernel > API is likely to change and use of these functions (in particular the > format of the cap_user_*_t types) is subject to extension with each > kernel revision, but old programs will keep working. > > Since conceptually the structures passed to the system call can vary > depending on the version and it's possible for the kernel code to > support more than one version, it seem appropriate to me to use void > pointers which are cast as necessary in the kernel code. Granted the > implementation I supplied only currently implements version 1 of the > Linux API. > > I can add some comments to the capget / capset code mentioning the > reason for the void pointers or if you feel strongly about it I can > get rid of the void pointers. If you do not have the time to handle it, I am OK to commit it with the void pointers, but I would prefer to have some real structures there instead of void pointers. > >> + case SCM_CREDS: > >> + /* > >> + * Currently LOCAL_CREDS is never in > >> + * effect for Linux so no need to > >> worry > >> + * about sockcred > >> + */ > > > > Is there a way to check this here and fail (either with an > > appropriate error return or a kernel panic if this is more > > appropriate... I'm not sure I have the big picture here)? > > I have a basic sanity check in the code which is: > > if (datalen != sizeof (*cmcred)) { > error = EMSGSIZE; > goto bad; > } > > The problem is that unix domain sockets support two different ways of > sending credentials (setsockopt LOCAL_CRED and sendmsg with > SCM_CREDS). They both use the same msg type, however they each have > their own unique structure. If setsockopt LOCAL_CRED is in effect > for the Linux program, then the data supplied with the SCM_CREDS > needs to be converted differently ... currently a nonissue since at > the moment I believe the FreeBSD Linux layer doesn't support > LOCAL_CRED (actually I don't know if Linux even supports LOCAL_CRED). OK. > I'm happy to take care of the style issues and add comments in some of > the other places you mentioned. Great! > Let me know if there are any other questions and whether to keep the > capabilities stuff as part of the patch. Once you tell me how to > proceed I'll put together another patch. With the capabilities please. Thanks a lot! Bye, Alexander.