From linimon at FreeBSD.org  Mon Sep  1 00:44:06 2008
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Mon Sep  1 00:44:12 2008
Subject: ports/123960: Port fix: archivers/linux-par2cmdline - better
	handling of NOPORTDOCS
Message-ID: <200809010044.m810i5sC078331@freefall.freebsd.org>

Synopsis: Port fix: archivers/linux-par2cmdline - better handling of NOPORTDOCS

State-Changed-From-To: open->closed
State-Changed-By: linimon
State-Changed-When: Mon Sep 1 00:43:48 UTC 2008
State-Changed-Why: 
Should be taken care of by the commit in ports/123964.

http://www.freebsd.org/cgi/query-pr.cgi?pr=123960
From bugmaster at FreeBSD.org  Mon Sep  1 11:06:54 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep  1 11:07:33 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200809011106.m81B6rrI068393@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/21463   emulation  [linux] Linux compatability mode should not allow setu
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove

3 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/11165   emulation  [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999
o kern/29698   emulation  [linux] [patch] linux ipcs doesn'work
o kern/39201   emulation  [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu
o kern/41543   emulation  [patch] [request] easier wine/w23 support
a kern/72920   emulation  [linux]: path "prefixing" is not done on unix domain s
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
o kern/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails

11 problems total.

From pav at FreeBSD.org  Mon Sep  1 19:50:13 2008
From: pav at FreeBSD.org (Pav Lucistnik)
Date: Mon Sep  1 19:50:20 2008
Subject: [Fwd: linux_kdump-1.5_2 failed on amd64 7]
Message-ID: <1220296983.73021.2.camel@ikaros.oook.cz>

-------- P?eposlan? zpr?va --------
> Od: User Ports-amd64 <ports-amd64@FreeBSD.org>
> Komu: cvs@oook.cz
> P?edm?t: linux_kdump-1.5_2 failed on amd64 7
> Datum: Sun, 31 Aug 2008 06:55:26 GMT
> 
> You can also find this build log at
> 
>   http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/a.7.20080829144448/linux_kdump-1.5_2.log
> 
> building linux_kdump-1.5_2 on hammer1.isc.gumbysoft.com
> in directory /usr2/pkgbuild/7/20080829144448/chroot/3142
> building for: 7.1-PRERELEASE amd64
> maintained by: freebsd-emulation@FreeBSD.org
> port directory: /usr/ports/devel/linux_kdump
> Makefile ident: $FreeBSD: ports/devel/linux_kdump/Makefile,v 1.30 2007/10/04 00:41:08 edwin Exp $
> build started at Sun Aug 31 06:50:34 UTC 2008
> FETCH_DEPENDS=
> PATCH_DEPENDS=
> EXTRACT_DEPENDS=
> BUILD_DEPENDS=linux_base-gentoo-stage3-2006.0_2.tbz
> RUN_DEPENDS=
> prefixes: LOCALBASE=usr/local X11BASE=usr/local
> add_pkg
> ================================================================
> ====================<phase 1: make checksum>====================
> ===> Using the FreeBSD source tree under /usr/src
> ===> Set SRCDIR to use an alternate source tree
> => linux_kdump-1.5.tar.gz doesn't seem to exist in /tmp/distfiles/.
> => Attempting to fetch from ftp://freebsd.isc.org/pub/FreeBSD/ports/distfiles/.
> linux_kdump-1.5.tar.gz                                6166  B   54 kBps
> => MD5 Checksum OK for linux_kdump-1.5.tar.gz.
> => SHA256 Checksum OK for linux_kdump-1.5.tar.gz.
> ================================================================
> ====================<phase 2: make extract>====================
> add_pkg
> ===> Using the FreeBSD source tree under /usr/src
> ===> Set SRCDIR to use an alternate source tree
> ===>  Extracting for linux_kdump-1.5_2
> => MD5 Checksum OK for linux_kdump-1.5.tar.gz.
> => SHA256 Checksum OK for linux_kdump-1.5.tar.gz.
> ================================================================
> ====================<phase 3: make patch>====================
> add_pkg
> ===>  Patching for linux_kdump-1.5_2
> ===>  Applying FreeBSD patches for linux_kdump-1.5_2
> ================================================================
> ====================<phase 4: make build>====================
> add_pkg linux_base-gentoo-stage3-2006.0_2.tbz
> adding dependencies
> pkg_add linux_base-gentoo-stage3-2006.0_2.tbz
> grep: /etc/fstab: No such file or directory
> 
> +++ Some programs may need the linprocfs, please add it to /etc/fstab! +++
> 
> Running linux ldconfig...
> 
> * The port/package has attempted to enable Linux compatibility mode by loading
> * the linux.ko kernel module.  You can load the module manually as root with the
> * command "kldload linux" or have it load automatically at boot time by adding
> * to /etc/rc.conf the line:
> *
> *   linux_enable="YES"
> *
> * You may wish to enable emulation of the Linux proc filesystem.  See the
> * linprocfs(5) man page.
> *
> * To download Portage, do "chroot /compat/linux/ emerge sync" as root.  Then you
> * may want to do "chroot /compat/linux/ /usr/portage/scripts/bootstrap.sh" to
> * rebuild binutils, gcc, gettext, and glibc.  See
> * <URL:http://www.gentoo.org/doc/en/gentoo-alpha-install.xml> or
> * <URL:http://www.gentoo.org/doc/en/gentoo-x86-install.xml> for more complete 
> * instructions.
> 
> ===>   linux_kdump-1.5_2 depends on file: /compat/linux/usr/bin/gcc - found
> ===>  Configuring for linux_kdump-1.5_2
> ===>  Building for linux_kdump-1.5_2
> Warning: Object directory not changed from original /work/a/ports/devel/linux_kdump/work/linux_kdump-1.5
> cc -O2 -fno-strict-aliasing -pipe  -I/usr/src/usr.bin/ktrace -I/usr/src/usr.bin/kdump -I/usr/src  -c kdump.c
> kdump.c: In function 'main':
> kdump.c:85: error: 'KTRFAC_STRUCT' undeclared (first use in this function)
> kdump.c:85: error: (Each undeclared identifier is reported only once
> kdump.c:85: error: for each function it appears in.)
> *** Error code 1
> 
> Stop in /work/a/ports/devel/linux_kdump/work/linux_kdump-1.5.
> *** Error code 1
> 
> Stop in /a/ports/devel/linux_kdump.
> ================================================================
> build of /usr/ports/devel/linux_kdump ended at Sun Aug 31 06:55:27 UTC 2008

-- 
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>
You can't expect to wield supreme executive power just 'cause some
watery tart threw a sword at you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?=
	=?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?=
	=?ISO-8859-1?Q?_zpr=E1vy?=
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080901/0282237a/attachment.pgp
From rdivacky at freebsd.org  Tue Sep  2 08:56:12 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Sep  2 08:56:19 2008
Subject: MPSAFE TTY: Linux PTY's
In-Reply-To: <20080831110610.GA2380@dchagin.dialup.corbina.ru>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
Message-ID: <20080902085623.GA12395@freebsd.org>

On Sun, Aug 31, 2008 at 03:06:10PM +0400, Chagin Dmitry wrote:
> On Fri, Aug 22, 2008 at 01:29:46PM +0200, Roman Divacky wrote:
> > On Fri, Aug 22, 2008 at 01:29:27PM +0200, Ed Schouten wrote:
> > > Hello Emulation folks,
> > > 
> > > I just wanted to send you all a message to say one of the things I tried
> > > to improve in the MPSAFE TTY branch was support for PTY's for Linux
> > > binaries.
> > > 
> > > At home I've got a FreeBSD Jail running Debian Etch. Unfortunately,
> > > Linux sendmsg() is a little broken on FreeBSD/amd64, but so far I've
> > > been able to at least get OpenSSH (as root) and GNU Screen working.
> > 
> > I believe dmitry has a patch for this..
> 
> the patch is bellow, I tested a patch only on LTP tests (with little changes),
> it's necessary to test on real apps, it will be good if Ed will test..

this should be reviewed by someone with a knowledge of how networking works in 
FreeBSD. Any volunteer? Dmitry, can you send a mail to net@ describing the changes
in the patch and ask for a review there?

thnx!

roman
From scf at FreeBSD.org  Tue Sep  2 20:56:36 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Tue Sep  2 20:57:16 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <20080830113448.GA2152@dchagin.dialup.corbina.ru>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
Message-ID: <alpine.BSF.2.00.0809021552040.7934@thor.farley.org>

On Sat, 30 Aug 2008, Chagin Dmitry wrote:

> On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
>> I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
>> the following command, Linux applications (chroot, acroread, ls) will
>> start core dumping:
>>     qemu-system-x86_64 -m 512 \
>>     -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
>>     -std-vga -parallel none -serial none -monitor stdio \
>>     -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
>>
>> Loading kqemu.ko does not cause the problem, but the cores start a
>> little after WinXP starts running.  Unloading kqemu.ko does not help;
>> the cores still happen but more randomly.  I even tried unloading all
>> linux modules and reloading them without luck.  It takes a reboot.
>>
>> Packages:
>> qemu-devel-0.9.1s.20080620_1
>> kqemu-kmod-devel-1.4.0.p1
>> linux_base-f8-8_4
>>
>> sysctl:
>> compat.linux.osrelease: 2.6.16
>>
>> dmesg:
>> kqemu version 0x00010400
>> kqemu: KQEMU installed, max_locked_mem=1792492kB.
>>
>> System is 7-STABLE as of r181963 with or without the patch to fix RT
>> signals from Chagin.
>
> Interestingly... Sean, can you provide ktrace/kdump log of coring
> apps?  thnx!

Here they are (good and bad):
http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/

The good trace is after the bad trace.  I just kept running ktrace
/compat/linux/bin/date over and over until I got a good trace.  Before
loading kqemu and running qemu, there were no core dumps.  Also, I
compared two bad traces and they were basically the same except for PID
and a couple of addresses (still very close in value).

Sean
-- 
scf@FreeBSD.org
From ghost-sw at yandex.ru  Wed Sep  3 10:00:31 2008
From: ghost-sw at yandex.ru (Mike Sw)
Date: Wed Sep  3 10:00:37 2008
Subject: VMware3 from ports on FreeBSD 7.0
Message-ID: <516693407.20080903133349@yandex.ru>

Hello There!

I have a trouble with installing vmware3 from
/usr/ports/emulators/vmware3 on FreeBSD 7.0

When I try to install I see this error:

...
...
(some processes)
...
...

/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/task.c
In file included from
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/taskswitch.h:25,
from
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/task.c:54:
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:
In function 'Div643264':
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:1033:
error: memory input 4 is not directly addressable
*** Error code 1

Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only.
*** Error code 1

Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only.
*** Error code 1

Stop in /usr/ports/emulators/vmware3/work/vmware-distrib.
*** Error code 1

Stop in /usr/ports/emulators/vmware3.
*** Error code 1

Stop in /usr/ports/emulators/vmware3.
[sw]#

Also I've installed all of packages that VMware requires.
Result is same.

May be someone knows what is wrong here?
Please help me with it or recommend another emulator :)

Thank you...
Mike


From dchagin at freebsd.org  Sat Sep  6 10:47:08 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sat Sep  6 10:47:14 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
Message-ID: <20080906104659.GA2113@dchagin.dialup.corbina.ru>

On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
> On Sat, 30 Aug 2008, Chagin Dmitry wrote:
> 
> >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
> >>the following command, Linux applications (chroot, acroread, ls) will
> >>start core dumping:
> >>    qemu-system-x86_64 -m 512 \
> >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
> >>    -std-vga -parallel none -serial none -monitor stdio \
> >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> >>
> >>Loading kqemu.ko does not cause the problem, but the cores start a
> >>little after WinXP starts running.  Unloading kqemu.ko does not help;
> >>the cores still happen but more randomly.  I even tried unloading all
> >>linux modules and reloading them without luck.  It takes a reboot.
> >>
> >>Packages:
> >>qemu-devel-0.9.1s.20080620_1
> >>kqemu-kmod-devel-1.4.0.p1
> >>linux_base-f8-8_4
> >>
> >>sysctl:
> >>compat.linux.osrelease: 2.6.16
> >>
> >>dmesg:
> >>kqemu version 0x00010400
> >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
> >>
> >>System is 7-STABLE as of r181963 with or without the patch to fix RT
> >>signals from Chagin.
> >
> >Interestingly... Sean, can you provide ktrace/kdump log of coring
> >apps?  thnx!
> 
> Here they are (good and bad):
> http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
> 
> The good trace is after the bad trace.  I just kept running ktrace
> /compat/linux/bin/date over and over until I got a good trace.  Before
> loading kqemu and running qemu, there were no core dumps.  Also, I
> compared two bad traces and they were basically the same except for PID
> and a couple of addresses (still very close in value).
> 

Most likely it is a tls problem again, some days ago kib@ has made MFC
r182684, probably it will help..

thnx!

-- 
Have fun!
chd
From kostikbel at gmail.com  Sat Sep  6 16:08:07 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sat Sep  6 16:08:14 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <20080906104659.GA2113@dchagin.dialup.corbina.ru>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
Message-ID: <20080906152929.GB2038@deviant.kiev.zoral.com.ua>

On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
> > 
> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
> > >>the following command, Linux applications (chroot, acroread, ls) will
> > >>start core dumping:
> > >>    qemu-system-x86_64 -m 512 \
> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
> > >>    -std-vga -parallel none -serial none -monitor stdio \
> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> > >>
> > >>Loading kqemu.ko does not cause the problem, but the cores start a
> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
> > >>the cores still happen but more randomly.  I even tried unloading all
> > >>linux modules and reloading them without luck.  It takes a reboot.
> > >>
> > >>Packages:
> > >>qemu-devel-0.9.1s.20080620_1
> > >>kqemu-kmod-devel-1.4.0.p1
> > >>linux_base-f8-8_4
> > >>
> > >>sysctl:
> > >>compat.linux.osrelease: 2.6.16
> > >>
> > >>dmesg:
> > >>kqemu version 0x00010400
> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
> > >>
> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
> > >>signals from Chagin.
> > >
> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
> > >apps?  thnx!
> > 
> > Here they are (good and bad):
> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
> > 
> > The good trace is after the bad trace.  I just kept running ktrace
> > /compat/linux/bin/date over and over until I got a good trace.  Before
> > loading kqemu and running qemu, there were no core dumps.  Also, I
> > compared two bad traces and they were basically the same except for PID
> > and a couple of addresses (still very close in value).
> > 
> 
> Most likely it is a tls problem again, some days ago kib@ has made MFC
> r182684, probably it will help..

I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
it tries to use GDT/LDT. This probably has unwanted interaction with
PCB_GS32BIT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080906/47d92c6b/attachment.pgp
From nox at jelal.kn-bremen.de  Sat Sep  6 22:17:29 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sat Sep  6 22:17:36 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <20080906152929.GB2038@deviant.kiev.zoral.com.ua>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
Message-ID: <200809062215.m86MF6NS040797@saturn.kn-bremen.de>

In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write:
>-=-=-=-=-=-
>
>On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
>> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
>> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
>> > 
>> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
>> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
>> > >>the following command, Linux applications (chroot, acroread, ls) will
>> > >>start core dumping:
>> > >>    qemu-system-x86_64 -m 512 \
>> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
>> > >>    -std-vga -parallel none -serial none -monitor stdio \
>> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
>> > >>
>> > >>Loading kqemu.ko does not cause the problem, but the cores start a
>> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
>> > >>the cores still happen but more randomly.  I even tried unloading all
>> > >>linux modules and reloading them without luck.  It takes a reboot.
>> > >>
>> > >>Packages:
>> > >>qemu-devel-0.9.1s.20080620_1
>> > >>kqemu-kmod-devel-1.4.0.p1
>> > >>linux_base-f8-8_4
>> > >>
>> > >>sysctl:
>> > >>compat.linux.osrelease: 2.6.16
>> > >>
>> > >>dmesg:
>> > >>kqemu version 0x00010400
>> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
>> > >>
>> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
>> > >>signals from Chagin.
>> > >
>> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
>> > >apps?  thnx!
>> > 
>> > Here they are (good and bad):
>> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
>> > 
>> > The good trace is after the bad trace.  I just kept running ktrace
>> > /compat/linux/bin/date over and over until I got a good trace.  Before
>> > loading kqemu and running qemu, there were no core dumps.  Also, I
>> > compared two bad traces and they were basically the same except for PID
>> > and a couple of addresses (still very close in value).
>> > 
>> 
>> Most likely it is a tls problem again, some days ago kib@ has made MFC
>> r182684, probably it will help..
>
>I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
>it tries to use GDT/LDT. This probably has unwanted interaction with
>PCB_GS32BIT.

Wow.  That corner of the code had escaped me so far, and yes this (in
amd64/linux32) looks like it won't like kqemu's seperating of the gdts
on SMP indeed.  (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and
lets linux processes manipulate the segment pointed to by it, and when
kqemu is (or was) running this won't be used by all cpus, see older threads
like
	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html
for the reasons.)

 What I wonder tho is, won't this also cause problems without kqemu when
there are linux processes running on multiple cpus that manipulate this
segment because the gdt is then shared between the cpus?  (like, linux
process on cpu 0 changes the segment, then linux process on cpu 1 comes
along and changes it again and then the linux process on cpu 0 will pick
it up from cpu 1?)  At least I must have somehow assumed the shared gdt
wouldn't be changed later because of reasons like this...

 Anyway, fixing this will require changes to the kernel, I don't see how
kqemu could fix it by itself alone. :(

 Sorry,
	Juergen
From nox at jelal.kn-bremen.de  Sun Sep  7 18:53:57 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sun Sep  7 18:54:04 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <200809062215.m86MF6NS040797@saturn.kn-bremen.de>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
	<200809062215.m86MF6NS040797@saturn.kn-bremen.de>
Message-ID: <20080907185231.GA72139@saturn.kn-bremen.de>

On Sun, Sep 07, 2008 at 12:15:06AM +0200, I wrote:
> In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write:
> >-=-=-=-=-=-
> >
> >On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
> >> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
> >> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
> >> > 
> >> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> >> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
> >> > >>the following command, Linux applications (chroot, acroread, ls) will
> >> > >>start core dumping:
> >> > >>    qemu-system-x86_64 -m 512 \
> >> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
> >> > >>    -std-vga -parallel none -serial none -monitor stdio \
> >> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> >> > >>
> >> > >>Loading kqemu.ko does not cause the problem, but the cores start a
> >> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
> >> > >>the cores still happen but more randomly.  I even tried unloading all
> >> > >>linux modules and reloading them without luck.  It takes a reboot.
> >> > >>
> >> > >>Packages:
> >> > >>qemu-devel-0.9.1s.20080620_1
> >> > >>kqemu-kmod-devel-1.4.0.p1
> >> > >>linux_base-f8-8_4
> >> > >>
> >> > >>sysctl:
> >> > >>compat.linux.osrelease: 2.6.16
> >> > >>
> >> > >>dmesg:
> >> > >>kqemu version 0x00010400
> >> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
> >> > >>
> >> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
> >> > >>signals from Chagin.
> >> > >
> >> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
> >> > >apps?  thnx!
> >> > 
> >> > Here they are (good and bad):
> >> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
> >> > 
> >> > The good trace is after the bad trace.  I just kept running ktrace
> >> > /compat/linux/bin/date over and over until I got a good trace.  Before
> >> > loading kqemu and running qemu, there were no core dumps.  Also, I
> >> > compared two bad traces and they were basically the same except for PID
> >> > and a couple of addresses (still very close in value).
> >> > 
> >> 
> >> Most likely it is a tls problem again, some days ago kib@ has made MFC
> >> r182684, probably it will help..
> >
> >I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
> >it tries to use GDT/LDT. This probably has unwanted interaction with
> >PCB_GS32BIT.
> 
> Wow.  That corner of the code had escaped me so far, and yes this (in
> amd64/linux32) looks like it won't like kqemu's seperating of the gdts
> on SMP indeed.  (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and
> lets linux processes manipulate the segment pointed to by it, and when
> kqemu is (or was) running this won't be used by all cpus, see older threads
> like
> 	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html
> for the reasons.)
> 
>  What I wonder tho is, won't this also cause problems without kqemu when
> there are linux processes running on multiple cpus that manipulate this
> segment because the gdt is then shared between the cpus?  (like, linux
> process on cpu 0 changes the segment, then linux process on cpu 1 comes
> along and changes it again and then the linux process on cpu 0 will pick
> it up from cpu 1?)  At least I must have somehow assumed the shared gdt
> wouldn't be changed later because of reasons like this...
> 
>  Anyway, fixing this will require changes to the kernel, I don't see how
> kqemu could fix it by itself alone. :(

There is a possible workaround tho that you can try if you are on
RELENG_7 or HEAD (and you are running ULE):
	cpuset -l 0 qemu...
(Obviously this is less than ideal if you need more than one qemu at a time,
so we still want a proper fix.)

 Btw I couldn't reproduce the crashing linux date(1) on RELENG_7_0, so I
guess it was only later commits that uncovered the problem...

 HTH, (or at least a bit :)
	Juergen
From mita at ee.t.u-tokyo.ac.jp  Sun Sep  7 20:25:20 2008
From: mita at ee.t.u-tokyo.ac.jp (MITA Yoshio)
Date: Sun Sep  7 20:25:26 2008
Subject: Skype core dumps as normal user
In-Reply-To: <200803162311.25730.beech@freebsd.org>
Message-ID: <7ozlmjag2w.wl%mita@ee.t.u-tokyo.ac.jp>

Hello,

> On Sun, 16 Mar 2008 23:11:21 -0800 Beech Rintoul wrote:
> 
> > I've run into a problem starting skype as a normal user:
> 
> > $ skype --resources=/usr/local/share/skype
> > *** glibc detected *** skype: double free or corruption (!prev): 
> > 0x092ad7f0 ***
> > ======= Backtrace: =========
> > /lib/libc.so.6[0x295c3f64]
> > /lib/libc.so.6(cfree+0x90)[0x295c7630]
> > /lib/libc.so.6(closedir+0x28)[0x295e8308]
> > /usr/lib/libfontconfig.so.1(FcDirScan+0x1f2)[0x2931321d]
> > /usr/lib/libfontconfig.so.1(FcConfigBuildFonts+0x94)[0x2930dd51]
> > /usr/lib/libfontconfig.so.1(FcInitLoadConfigAndFonts+0x26)[0x293150b3]
> > /usr/lib/libfontconfig.so.1(FcInit+0x2e)[0x293152b0]
> 
> [skip]
> 
> > Does anyone have any ideas on where to go with this, or should I kick 
> > it upstream?
> 
> Looks like http://www.freebsd.org/cgi/query-pr.cgi?pr=117010 .
> 
> 
> WBR, bsam


Yes it appears to be the same problem reported at pr=117010.  By
applying the patch posted as a followup to that PR, my skype begun
to work correctly.

The strange thing is that, using the identical packages and on the
same 7.0-RELEASE, skype on one computer works, but another
doesn't.  Maybe it depends on font path configuration? as skype
seems to crash on font configuration.

All the best,

Tested Environment: 
FreeBSD 7.0-RELEASE
linux_base-fc6-6_5
linux-glib2-2.6.6
skype-2.0.0.68,1 

/etc/sysctl.conf:
compat.linux.osrelease=2.6.16

/etc/make.conf:
OVERRIDE_LINUX_BASE_PORT=fc6 

---
MITA Yoshio
From mita at ee.t.u-tokyo.ac.jp  Sun Sep  7 20:30:04 2008
From: mita at ee.t.u-tokyo.ac.jp (MITA Yoshio)
Date: Sun Sep  7 20:30:11 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
	overflow or else
Message-ID: <200809072030.m87KU44I064646@freefall.freebsd.org>

The following reply was made to PR kern/117010; it has been noted by GNATS.

From: MITA Yoshio <mita@ee.t.u-tokyo.ac.jp>
To: bug-followup@FreeBSD.org,samflanker@gmail.com,
    Chagin Dmitry <chagin.dmitry@gmail.com>,
    beech@FreeBSD.org
Cc:  
Subject: Re: kern/117010: [linux] linux_getdents() get something like buffer overflow or else
Date: Sun, 07 Sep 2008 21:42:15 +0200

 Hello, 
 
 I've tested a patch from Mr. Dmitry concerning Mr. Ermakov's PR:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=117010
 
 Patch:
 >From:	Chagin Dmitry <chagin.dmitry@gmail.com>
 >Date:	Fri, 25 Jul 2008 10:22:46 +0400 (MSD)
 
 This worked!!! to make skype2 work.  
 Otherwise skype2 dumped core as Mr.  reported. 
 
 Regards,
 -----
 Tested Environment: 
 FreeBSD 7.0-RELEASE
 linux_base-fc6-6_5
 linux-glib2-2.6.6
 skype-2.0.0.68,1 
 
 /etc/sysctl.conf:
 compat.linux.osrelease=2.6.16
 
 /etc/make.conf:
 OVERRIDE_LINUX_BASE_PORT=fc6 
 -----
 MITA Yoshio
From bsam at ipt.ru  Sun Sep  7 20:36:56 2008
From: bsam at ipt.ru (Boris Samorodov)
Date: Sun Sep  7 20:37:11 2008
Subject: Skype core dumps as normal user
In-Reply-To: <7ozlmjag2w.wl%mita@ee.t.u-tokyo.ac.jp> (MITA Yoshio's message of
	"Sun\, 07 Sep 2008 21\:52\:55 +0200")
References: <7ozlmjag2w.wl%mita@ee.t.u-tokyo.ac.jp>
Message-ID: <83313575@bs1.sp34.ru>

On Sun, 07 Sep 2008 21:52:55 +0200 MITA Yoshio wrote:
> > On Sun, 16 Mar 2008 23:11:21 -0800 Beech Rintoul wrote:
> > 
> > > I've run into a problem starting skype as a normal user:
> > 
> > > $ skype --resources=/usr/local/share/skype
> > > *** glibc detected *** skype: double free or corruption (!prev): 
> > > 0x092ad7f0 ***
> > > ======= Backtrace: =========
> > > /lib/libc.so.6[0x295c3f64]
> > > /lib/libc.so.6(cfree+0x90)[0x295c7630]
> > > /lib/libc.so.6(closedir+0x28)[0x295e8308]
> > > /usr/lib/libfontconfig.so.1(FcDirScan+0x1f2)[0x2931321d]
> > > /usr/lib/libfontconfig.so.1(FcConfigBuildFonts+0x94)[0x2930dd51]
> > > /usr/lib/libfontconfig.so.1(FcInitLoadConfigAndFonts+0x26)[0x293150b3]
> > > /usr/lib/libfontconfig.so.1(FcInit+0x2e)[0x293152b0]
> > 
> > [skip]
> > 
> > > Does anyone have any ideas on where to go with this, or should I kick 
> > > it upstream?
> > 
> > Looks like http://www.freebsd.org/cgi/query-pr.cgi?pr=117010 .

> Yes it appears to be the same problem reported at pr=117010.  By
> applying the patch posted as a followup to that PR, my skype begun
> to work correctly.

It will be great if you can write a follow-up to the PR so this
information won't get lost.

> The strange thing is that, using the identical packages and on the
> same 7.0-RELEASE, skype on one computer works, but another
> doesn't.  Maybe it depends on font path configuration? as skype
> seems to crash on font configuration.

AFAIK directoriea are read by a program by blocks, say 1024 bytes
long. If it so happens that current portion of directory entries
equals to that length, than that error occures.

> All the best,

> Tested Environment: 
> FreeBSD 7.0-RELEASE
> linux_base-fc6-6_5

Seems that there were reports that the patch you had used is not
needed with linux_base-f8 port.

> linux-glib2-2.6.6
> skype-2.0.0.68,1 

> /etc/sysctl.conf:
> compat.linux.osrelease=2.6.16

> /etc/make.conf:
> OVERRIDE_LINUX_BASE_PORT=fc6 

WBR
-- 
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
From mita at ee.t.u-tokyo.ac.jp  Sun Sep  7 20:42:36 2008
From: mita at ee.t.u-tokyo.ac.jp (MITA Yoshio)
Date: Sun Sep  7 20:42:42 2008
Subject: Skype core dumps as normal user
In-Reply-To: <83313575@bs1.sp34.ru>
References: <7ozlmjag2w.wl%mita@ee.t.u-tokyo.ac.jp>
	<83313575@bs1.sp34.ru>
Message-ID: <7ovdx7adsw.wl%mita@ee.t.u-tokyo.ac.jp>

Hello, 

>It will be great if you can write a follow-up to the PR so this
>information won't get lost.

Yes in parallel I made a follow-up Mail to that PR (followup mail
to bug-followup@FreeBSD.org will be resistered to that PR?? non??)


> > Tested Environment: 
> > FreeBSD 7.0-RELEASE
> > linux_base-fc6-6_5
> 
> Seems that there were reports that the patch you had used is not
> needed with linux_base-f8 port.

Well, fc6 was recommended as skype installation procedure in
/usr/ports/README for 7.0-RELEASE.  So I don't know what should be
changed either README or kernel...

Cheers,
---
MITA Yoshio
From bsam at ipt.ru  Sun Sep  7 20:58:42 2008
From: bsam at ipt.ru (Boris Samorodov)
Date: Sun Sep  7 20:58:48 2008
Subject: Skype core dumps as normal user
In-Reply-To: <7ovdx7adsw.wl%mita@ee.t.u-tokyo.ac.jp> (MITA Yoshio's message of
	"Sun\, 07 Sep 2008 22\:42\:07 +0200")
References: <7ozlmjag2w.wl%mita@ee.t.u-tokyo.ac.jp> <83313575@bs1.sp34.ru>
	<7ovdx7adsw.wl%mita@ee.t.u-tokyo.ac.jp>
Message-ID: <51150592@bs1.sp34.ru>

On Sun, 07 Sep 2008 22:42:07 +0200 MITA Yoshio wrote:

> >It will be great if you can write a follow-up to the PR so this
> >information won't get lost.

> Yes in parallel I made a follow-up Mail to that PR (followup mail
> to bug-followup@FreeBSD.org will be resistered to that PR?? non??)

Yep, it is registered by now, thanks.

> > > Tested Environment: 
> > > FreeBSD 7.0-RELEASE
> > > linux_base-fc6-6_5
> > 
> > Seems that there were reports that the patch you had used is not
> > needed with linux_base-f8 port.

> Well, fc6 was recommended as skype installation procedure in
> /usr/ports/README for 7.0-RELEASE.  So I don't know what should be
> changed either README or kernel...

I wrote that only to inform you about other possibilities. ;-)


WBR
-- 
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
From dchagin at freebsd.org  Sun Sep  7 21:12:37 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Sep  7 21:12:45 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
	overflow or else
In-Reply-To: <200809072030.m87KU44I064646@freefall.freebsd.org>
References: <200809072030.m87KU44I064646@freefall.freebsd.org>
Message-ID: <20080907211228.GA51816@dchagin.dialup.corbina.ru>

On Sun, Sep 07, 2008 at 08:30:04PM +0000, MITA Yoshio wrote:
> The following reply was made to PR kern/117010; it has been noted by GNATS.
> 
> From: MITA Yoshio <mita@ee.t.u-tokyo.ac.jp>
> To: bug-followup@FreeBSD.org,samflanker@gmail.com,
>     Chagin Dmitry <chagin.dmitry@gmail.com>,
>     beech@FreeBSD.org
> Cc:  
> Subject: Re: kern/117010: [linux] linux_getdents() get something like buffer overflow or else
> Date: Sun, 07 Sep 2008 21:42:15 +0200
> 
>  Hello, 
>  
>  I've tested a patch from Mr. Dmitry concerning Mr. Ermakov's PR:
>  
>  http://www.freebsd.org/cgi/query-pr.cgi?pr=117010
>  
>  Patch:
>  >From:	Chagin Dmitry <chagin.dmitry@gmail.com>
>  >Date:	Fri, 25 Jul 2008 10:22:46 +0400 (MSD)
>  
>  This worked!!! to make skype2 work.  
>  Otherwise skype2 dumped core as Mr.  reported. 
>  
>  Regards,
>  -----
>  Tested Environment: 
>  FreeBSD 7.0-RELEASE
>  linux_base-fc6-6_5
>  linux-glib2-2.6.6
>  skype-2.0.0.68,1 
>  
>  /etc/sysctl.conf:
>  compat.linux.osrelease=2.6.16
>  
>  /etc/make.conf:
>  OVERRIDE_LINUX_BASE_PORT=fc6 

Please, try a patch bellow:

diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file.c
index 303bc3f..413e597 100644
--- a/src/sys/compat/linux/linux_file.c
+++ b/src/sys/compat/linux/linux_file.c
@@ -303,9 +303,20 @@ struct l_dirent64 {
 	char		d_name[LINUX_NAME_MAX + 1];
 };
 
-#define LINUX_RECLEN(de,namlen) \
-    ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1))
+/*
+ * Linux uses the last byte in the dirent buffer to store d_type,
+ * at least glibc-2.7 requires it. For what l_dirent padded on 2 bytes.
+ */
+#define LINUX_RECLEN(namlen)						\
+    roundup((offsetof(struct l_dirent, d_name) + (namlen) + 2),		\
+    sizeof(l_ulong))
+
+#define LINUX_RECLEN64(namlen)						\
+    roundup((offsetof(struct l_dirent64, d_name) + (namlen) + 1),	\
+    sizeof(uint64_t))
 
+#define LINUX_MAXRECLEN		max(LINUX_RECLEN(LINUX_NAME_MAX),	\
+				    LINUX_RECLEN64(LINUX_NAME_MAX))
 #define	LINUX_DIRBLKSIZ		512
 
 static int
@@ -318,12 +329,13 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
 	int len, reclen;		/* BSD-format */
 	caddr_t outp;			/* Linux-format */
 	int resid, linuxreclen=0;	/* Linux-format */
+	caddr_t lbuf;			/* Linux-format */
 	struct file *fp;
 	struct uio auio;
 	struct iovec aiov;
 	off_t off;
-	struct l_dirent linux_dirent;
-	struct l_dirent64 linux_dirent64;
+	struct l_dirent *linux_dirent;
+	struct l_dirent64 *linux_dirent64;
 	int buflen, error, eofflag, nbytes, justone;
 	u_long *cookies = NULL, *cookiep;
 	int ncookies, vfslocked;
@@ -359,6 +371,7 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
 	buflen = max(LINUX_DIRBLKSIZ, nbytes);
 	buflen = min(buflen, MAXBSIZE);
 	buf = malloc(buflen, M_TEMP, M_WAITOK);
+	lbuf = malloc(LINUX_MAXRECLEN, M_TEMP, M_WAITOK | M_ZERO);
 	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
 
 again:
@@ -436,8 +449,8 @@ again:
 		}
 
 		linuxreclen = (is64bit)
-		    ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen)
-		    : LINUX_RECLEN(&linux_dirent, bdp->d_namlen);
+		    ? LINUX_RECLEN64(bdp->d_namlen)
+		    : LINUX_RECLEN(bdp->d_namlen);
 
 		if (reclen > len || resid < linuxreclen) {
 			outp++;
@@ -446,34 +459,41 @@ again:
 
 		if (justone) {
 			/* readdir(2) case. */
-			linux_dirent.d_ino = bdp->d_fileno;
-			linux_dirent.d_off = (l_off_t)linuxreclen;
-			linux_dirent.d_reclen = (l_ushort)bdp->d_namlen;
-			strcpy(linux_dirent.d_name, bdp->d_name);
-			error = copyout(&linux_dirent, outp, linuxreclen);
-		} else {
-			if (is64bit) {
-				linux_dirent64.d_ino = bdp->d_fileno;
-				linux_dirent64.d_off = (cookiep)
-				    ? (l_off_t)*cookiep
-				    : (l_off_t)(off + reclen);
-				linux_dirent64.d_reclen =
-				    (l_ushort)linuxreclen;
-				linux_dirent64.d_type = bdp->d_type;
-				strcpy(linux_dirent64.d_name, bdp->d_name);
-				error = copyout(&linux_dirent64, outp,
-				    linuxreclen);
-			} else {
-				linux_dirent.d_ino = bdp->d_fileno;
-				linux_dirent.d_off = (cookiep)
-				    ? (l_off_t)*cookiep
-				    : (l_off_t)(off + reclen);
-				linux_dirent.d_reclen = (l_ushort)linuxreclen;
-				strcpy(linux_dirent.d_name, bdp->d_name);
-				error = copyout(&linux_dirent, outp,
-				    linuxreclen);
-			}
+			linux_dirent = (struct l_dirent*)lbuf;
+			linux_dirent->d_ino = bdp->d_fileno;
+			linux_dirent->d_off = (l_off_t)linuxreclen;
+			linux_dirent->d_reclen = (l_ushort)bdp->d_namlen;
+			strlcpy(linux_dirent->d_name, bdp->d_name,
+			    linuxreclen - offsetof(struct l_dirent, d_name));
+			error = copyout(linux_dirent, outp, linuxreclen);
 		}
+		if (is64bit) {
+			linux_dirent64 = (struct l_dirent64*)lbuf;
+			linux_dirent64->d_ino = bdp->d_fileno;
+			linux_dirent64->d_off = (cookiep)
+			    ? (l_off_t)*cookiep
+			    : (l_off_t)(off + reclen);
+			linux_dirent64->d_reclen = (l_ushort)linuxreclen;
+			linux_dirent64->d_type = bdp->d_type;
+			strlcpy(linux_dirent64->d_name, bdp->d_name,
+			    linuxreclen - offsetof(struct l_dirent64, d_name));
+			error = copyout(linux_dirent64, outp, linuxreclen);
+		} else if (!justone) {
+			linux_dirent = (struct l_dirent*)lbuf;
+			linux_dirent->d_ino = bdp->d_fileno;
+			linux_dirent->d_off = (cookiep)
+			    ? (l_off_t)*cookiep
+			    : (l_off_t)(off + reclen);
+			linux_dirent->d_reclen = (l_ushort)linuxreclen;
+			/*
+			 * Copy d_type to last byte of l_dirent buffer
+			 */
+			lbuf[linuxreclen-1] = bdp->d_type;
+			strlcpy(linux_dirent->d_name, bdp->d_name,
+			    linuxreclen - offsetof(struct l_dirent, d_name)-1);
+			error = copyout(linux_dirent, outp, linuxreclen);
+		}
+
 		if (error)
 			goto out;
 
@@ -509,6 +529,7 @@ out:
 	VFS_UNLOCK_GIANT(vfslocked);
 	fdrop(fp, td);
 	free(buf, M_TEMP);
+	free(lbuf, M_TEMP);
 	return (error);
 }
 

Roman, I think that this patch can be commited (if testing passes :))
thnx!
-- 
Have fun!
chd
From kostikbel at gmail.com  Sun Sep  7 21:53:11 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep  7 21:53:19 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <200809062215.m86MF6NS040797@saturn.kn-bremen.de>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
	<200809062215.m86MF6NS040797@saturn.kn-bremen.de>
Message-ID: <20080907215300.GH2038@deviant.kiev.zoral.com.ua>

On Sun, Sep 07, 2008 at 12:15:06AM +0200, Juergen Lock wrote:
> In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write:
> >-=-=-=-=-=-
> >
> >On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
> >> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
> >> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
> >> > 
> >> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> >> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
> >> > >>the following command, Linux applications (chroot, acroread, ls) will
> >> > >>start core dumping:
> >> > >>    qemu-system-x86_64 -m 512 \
> >> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
> >> > >>    -std-vga -parallel none -serial none -monitor stdio \
> >> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> >> > >>
> >> > >>Loading kqemu.ko does not cause the problem, but the cores start a
> >> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
> >> > >>the cores still happen but more randomly.  I even tried unloading all
> >> > >>linux modules and reloading them without luck.  It takes a reboot.
> >> > >>
> >> > >>Packages:
> >> > >>qemu-devel-0.9.1s.20080620_1
> >> > >>kqemu-kmod-devel-1.4.0.p1
> >> > >>linux_base-f8-8_4
> >> > >>
> >> > >>sysctl:
> >> > >>compat.linux.osrelease: 2.6.16
> >> > >>
> >> > >>dmesg:
> >> > >>kqemu version 0x00010400
> >> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
> >> > >>
> >> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
> >> > >>signals from Chagin.
> >> > >
> >> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
> >> > >apps?  thnx!
> >> > 
> >> > Here they are (good and bad):
> >> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
> >> > 
> >> > The good trace is after the bad trace.  I just kept running ktrace
> >> > /compat/linux/bin/date over and over until I got a good trace.  Before
> >> > loading kqemu and running qemu, there were no core dumps.  Also, I
> >> > compared two bad traces and they were basically the same except for PID
> >> > and a couple of addresses (still very close in value).
> >> > 
> >> 
> >> Most likely it is a tls problem again, some days ago kib@ has made MFC
> >> r182684, probably it will help..
> >
> >I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
> >it tries to use GDT/LDT. This probably has unwanted interaction with
> >PCB_GS32BIT.
> 
> Wow.  That corner of the code had escaped me so far, and yes this (in
> amd64/linux32) looks like it won't like kqemu's seperating of the gdts
> on SMP indeed.  (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and
> lets linux processes manipulate the segment pointed to by it, and when
> kqemu is (or was) running this won't be used by all cpus, see older threads
> like
> 	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html
> for the reasons.)
> 
>  What I wonder tho is, won't this also cause problems without kqemu when
> there are linux processes running on multiple cpus that manipulate this
> segment because the gdt is then shared between the cpus?  (like, linux
> process on cpu 0 changes the segment, then linux process on cpu 1 comes
> along and changes it again and then the linux process on cpu 0 will pick
> it up from cpu 1?)  At least I must have somehow assumed the shared gdt
> wouldn't be changed later because of reasons like this...

Very nice catch! Me and Peter Wemm discussed the right approach,
that consists of actually providing per-cpu GDT. Patch is at
http://people.freebsd.org/~kib/misc/amd64_gdt.1.patch

Please, test and give a feedback. Even reports about thinks working
the same as before the patch are important.
> 
>  Anyway, fixing this will require changes to the kernel, I don't see how
> kqemu could fix it by itself alone. :(

See above. If you need some further kernel changes for kqemu, this is
the best time to discuss them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080907/45b14ba4/attachment.pgp
From nox at jelal.kn-bremen.de  Sun Sep  7 22:45:56 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sun Sep  7 22:46:03 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <20080907215300.GH2038@deviant.kiev.zoral.com.ua>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
	<200809062215.m86MF6NS040797@saturn.kn-bremen.de>
Message-ID: <200809072244.m87MiiWO078502@saturn.kn-bremen.de>

In article <20080907215300.GH2038@deviant.kiev.zoral.com.ua> you write:
>-=-=-=-=-=-
>
>On Sun, Sep 07, 2008 at 12:15:06AM +0200, Juergen Lock wrote:
>> In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write:
>> >-=-=-=-=-=-
>> >
>> >On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
>> >> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
>> >> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
>> >> > 
>> >> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
>> >> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
>> >> > >>the following command, Linux applications (chroot, acroread, ls) will
>> >> > >>start core dumping:
>> >> > >>    qemu-system-x86_64 -m 512 \
>> >> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
>> >> > >>    -std-vga -parallel none -serial none -monitor stdio \
>> >> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
>> >> > >>
>> >> > >>Loading kqemu.ko does not cause the problem, but the cores start a
>> >> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
>> >> > >>the cores still happen but more randomly.  I even tried unloading all
>> >> > >>linux modules and reloading them without luck.  It takes a reboot.
>> >> > >>
>> >> > >>Packages:
>> >> > >>qemu-devel-0.9.1s.20080620_1
>> >> > >>kqemu-kmod-devel-1.4.0.p1
>> >> > >>linux_base-f8-8_4
>> >> > >>
>> >> > >>sysctl:
>> >> > >>compat.linux.osrelease: 2.6.16
>> >> > >>
>> >> > >>dmesg:
>> >> > >>kqemu version 0x00010400
>> >> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
>> >> > >>
>> >> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
>> >> > >>signals from Chagin.
>> >> > >
>> >> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
>> >> > >apps?  thnx!
>> >> > 
>> >> > Here they are (good and bad):
>> >> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
>> >> > 
>> >> > The good trace is after the bad trace.  I just kept running ktrace
>> >> > /compat/linux/bin/date over and over until I got a good trace.  Before
>> >> > loading kqemu and running qemu, there were no core dumps.  Also, I
>> >> > compared two bad traces and they were basically the same except for PID
>> >> > and a couple of addresses (still very close in value).
>> >> > 
>> >> 
>> >> Most likely it is a tls problem again, some days ago kib@ has made MFC
>> >> r182684, probably it will help..
>> >
>> >I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
>> >it tries to use GDT/LDT. This probably has unwanted interaction with
>> >PCB_GS32BIT.
>> 
>> Wow.  That corner of the code had escaped me so far, and yes this (in
>> amd64/linux32) looks like it won't like kqemu's seperating of the gdts
>> on SMP indeed.  (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and
>> lets linux processes manipulate the segment pointed to by it, and when
>> kqemu is (or was) running this won't be used by all cpus, see older threads
>> like
>> 	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html
>> for the reasons.)
>> 
>>  What I wonder tho is, won't this also cause problems without kqemu when
>> there are linux processes running on multiple cpus that manipulate this
>> segment because the gdt is then shared between the cpus?  (like, linux
>> process on cpu 0 changes the segment, then linux process on cpu 1 comes
>> along and changes it again and then the linux process on cpu 0 will pick
>> it up from cpu 1?)  At least I must have somehow assumed the shared gdt
>> wouldn't be changed later because of reasons like this...
>
>Very nice catch! Me and Peter Wemm discussed the right approach,
>that consists of actually providing per-cpu GDT. Patch is at
>http://people.freebsd.org/~kib/misc/amd64_gdt.1.patch
>
Cool!

>Please, test and give a feedback. Even reports about thinks working
>the same as before the patch are important.
>> 
>>  Anyway, fixing this will require changes to the kernel, I don't see how
>> kqemu could fix it by itself alone. :(
>
>See above. If you need some further kernel changes for kqemu, this is
>the best time to discuss them.

 Well I haven't got around to testing the patch yet, but you could do
an OSVERSION bump once this gets committed so that we can compile out
the (then-to-be) obsolete gdt fixup code in kqemu.  (Yes it should do
nothing with the patched kernel except rewriting cpu 0's tss once with
data it already will have, but still its unnecessary cycles. :)

 Thanx,
	Juergen
From bugmaster at FreeBSD.org  Mon Sep  8 02:22:19 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep  8 02:22:48 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200809080222.m882MIdL006640@freefall.freebsd.org>

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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
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/29698   emulation  [linux] [patch] linux ipcs doesn'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

14 problems total.


Bugs can be in one of several states:

o - open
A problem report has been submitted, no sanity checking performed.

a - analyzed
The problem is understood and a solution is being sought.

f - feedback
Further work requires additional information from the
     originator or the community - possibly confirmation of
     the effectiveness of a proposed solution.

p - patched
A patch has been committed, but some issues (MFC and / or
     confirmation from originator) are still open.

r - repocopy
The resolution of the problem report is dependent on
     a repocopy operation within the CVS repository which
     is awaiting completion.

s - suspended
The problem is not being worked on, due to lack of information
     or resources.  This is a prime candidate
     for somebody who is looking for a project to do.
     If the problem cannot be solved at all,
     it will be closed, rather than suspended.

c - closed
A problem report is closed when any changes have been integrated,
     documented, and tested -- or when fixing the problem is abandoned.

From rdivacky at freebsd.org  Mon Sep  8 07:04:56 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Mon Sep  8 07:05:03 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
	overflow or else
In-Reply-To: <20080907211228.GA51816@dchagin.dialup.corbina.ru>
References: <200809072030.m87KU44I064646@freefall.freebsd.org>
	<20080907211228.GA51816@dchagin.dialup.corbina.ru>
Message-ID: <20080908070505.GA20963@freebsd.org>

On Mon, Sep 08, 2008 at 01:12:28AM +0400, Chagin Dmitry wrote:
> On Sun, Sep 07, 2008 at 08:30:04PM +0000, MITA Yoshio wrote:
> > The following reply was made to PR kern/117010; it has been noted by GNATS.
> > 
> > From: MITA Yoshio <mita@ee.t.u-tokyo.ac.jp>
> > To: bug-followup@FreeBSD.org,samflanker@gmail.com,
> >     Chagin Dmitry <chagin.dmitry@gmail.com>,
> >     beech@FreeBSD.org
> > Cc:  
> > Subject: Re: kern/117010: [linux] linux_getdents() get something like buffer overflow or else
> > Date: Sun, 07 Sep 2008 21:42:15 +0200
> > 
> >  Hello, 
> >  
> >  I've tested a patch from Mr. Dmitry concerning Mr. Ermakov's PR:
> >  
> >  http://www.freebsd.org/cgi/query-pr.cgi?pr=117010
> >  
> >  Patch:
> >  >From:	Chagin Dmitry <chagin.dmitry@gmail.com>
> >  >Date:	Fri, 25 Jul 2008 10:22:46 +0400 (MSD)
> >  
> >  This worked!!! to make skype2 work.  
> >  Otherwise skype2 dumped core as Mr.  reported. 
> >  
> >  Regards,
> >  -----
> >  Tested Environment: 
> >  FreeBSD 7.0-RELEASE
> >  linux_base-fc6-6_5
> >  linux-glib2-2.6.6
> >  skype-2.0.0.68,1 
> >  
> >  /etc/sysctl.conf:
> >  compat.linux.osrelease=2.6.16
> >  
> >  /etc/make.conf:
> >  OVERRIDE_LINUX_BASE_PORT=fc6 
> 
> Please, try a patch bellow:
> 
> diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file.c
> index 303bc3f..413e597 100644
> --- a/src/sys/compat/linux/linux_file.c
> +++ b/src/sys/compat/linux/linux_file.c
> @@ -303,9 +303,20 @@ struct l_dirent64 {
>  	char		d_name[LINUX_NAME_MAX + 1];
>  };
>  
> -#define LINUX_RECLEN(de,namlen) \
> -    ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1))
> +/*
> + * Linux uses the last byte in the dirent buffer to store d_type,
> + * at least glibc-2.7 requires it. For what l_dirent padded on 2 bytes.
> + */
> +#define LINUX_RECLEN(namlen)						\
> +    roundup((offsetof(struct l_dirent, d_name) + (namlen) + 2),		\
> +    sizeof(l_ulong))
> +
> +#define LINUX_RECLEN64(namlen)						\
> +    roundup((offsetof(struct l_dirent64, d_name) + (namlen) + 1),	\
> +    sizeof(uint64_t))
>  
> +#define LINUX_MAXRECLEN		max(LINUX_RECLEN(LINUX_NAME_MAX),	\
> +				    LINUX_RECLEN64(LINUX_NAME_MAX))
>  #define	LINUX_DIRBLKSIZ		512
>  
>  static int
> @@ -318,12 +329,13 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
>  	int len, reclen;		/* BSD-format */
>  	caddr_t outp;			/* Linux-format */
>  	int resid, linuxreclen=0;	/* Linux-format */
> +	caddr_t lbuf;			/* Linux-format */
>  	struct file *fp;
>  	struct uio auio;
>  	struct iovec aiov;
>  	off_t off;
> -	struct l_dirent linux_dirent;
> -	struct l_dirent64 linux_dirent64;
> +	struct l_dirent *linux_dirent;
> +	struct l_dirent64 *linux_dirent64;
>  	int buflen, error, eofflag, nbytes, justone;
>  	u_long *cookies = NULL, *cookiep;
>  	int ncookies, vfslocked;
> @@ -359,6 +371,7 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
>  	buflen = max(LINUX_DIRBLKSIZ, nbytes);
>  	buflen = min(buflen, MAXBSIZE);
>  	buf = malloc(buflen, M_TEMP, M_WAITOK);
> +	lbuf = malloc(LINUX_MAXRECLEN, M_TEMP, M_WAITOK | M_ZERO);
>  	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
>  
>  again:
> @@ -436,8 +449,8 @@ again:
>  		}
>  
>  		linuxreclen = (is64bit)
> -		    ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen)
> -		    : LINUX_RECLEN(&linux_dirent, bdp->d_namlen);
> +		    ? LINUX_RECLEN64(bdp->d_namlen)
> +		    : LINUX_RECLEN(bdp->d_namlen);
>  
>  		if (reclen > len || resid < linuxreclen) {
>  			outp++;
> @@ -446,34 +459,41 @@ again:
>  
>  		if (justone) {
>  			/* readdir(2) case. */
> -			linux_dirent.d_ino = bdp->d_fileno;
> -			linux_dirent.d_off = (l_off_t)linuxreclen;
> -			linux_dirent.d_reclen = (l_ushort)bdp->d_namlen;
> -			strcpy(linux_dirent.d_name, bdp->d_name);
> -			error = copyout(&linux_dirent, outp, linuxreclen);
> -		} else {
> -			if (is64bit) {
> -				linux_dirent64.d_ino = bdp->d_fileno;
> -				linux_dirent64.d_off = (cookiep)
> -				    ? (l_off_t)*cookiep
> -				    : (l_off_t)(off + reclen);
> -				linux_dirent64.d_reclen =
> -				    (l_ushort)linuxreclen;
> -				linux_dirent64.d_type = bdp->d_type;
> -				strcpy(linux_dirent64.d_name, bdp->d_name);
> -				error = copyout(&linux_dirent64, outp,
> -				    linuxreclen);
> -			} else {
> -				linux_dirent.d_ino = bdp->d_fileno;
> -				linux_dirent.d_off = (cookiep)
> -				    ? (l_off_t)*cookiep
> -				    : (l_off_t)(off + reclen);
> -				linux_dirent.d_reclen = (l_ushort)linuxreclen;
> -				strcpy(linux_dirent.d_name, bdp->d_name);
> -				error = copyout(&linux_dirent, outp,
> -				    linuxreclen);
> -			}
> +			linux_dirent = (struct l_dirent*)lbuf;
> +			linux_dirent->d_ino = bdp->d_fileno;
> +			linux_dirent->d_off = (l_off_t)linuxreclen;
> +			linux_dirent->d_reclen = (l_ushort)bdp->d_namlen;
> +			strlcpy(linux_dirent->d_name, bdp->d_name,
> +			    linuxreclen - offsetof(struct l_dirent, d_name));
> +			error = copyout(linux_dirent, outp, linuxreclen);
>  		}
> +		if (is64bit) {
> +			linux_dirent64 = (struct l_dirent64*)lbuf;
> +			linux_dirent64->d_ino = bdp->d_fileno;
> +			linux_dirent64->d_off = (cookiep)
> +			    ? (l_off_t)*cookiep
> +			    : (l_off_t)(off + reclen);
> +			linux_dirent64->d_reclen = (l_ushort)linuxreclen;
> +			linux_dirent64->d_type = bdp->d_type;
> +			strlcpy(linux_dirent64->d_name, bdp->d_name,
> +			    linuxreclen - offsetof(struct l_dirent64, d_name));
> +			error = copyout(linux_dirent64, outp, linuxreclen);
> +		} else if (!justone) {
> +			linux_dirent = (struct l_dirent*)lbuf;
> +			linux_dirent->d_ino = bdp->d_fileno;
> +			linux_dirent->d_off = (cookiep)
> +			    ? (l_off_t)*cookiep
> +			    : (l_off_t)(off + reclen);
> +			linux_dirent->d_reclen = (l_ushort)linuxreclen;
> +			/*
> +			 * Copy d_type to last byte of l_dirent buffer
> +			 */
> +			lbuf[linuxreclen-1] = bdp->d_type;
> +			strlcpy(linux_dirent->d_name, bdp->d_name,
> +			    linuxreclen - offsetof(struct l_dirent, d_name)-1);
> +			error = copyout(linux_dirent, outp, linuxreclen);
> +		}
> +
>  		if (error)
>  			goto out;
>  
> @@ -509,6 +529,7 @@ out:
>  	VFS_UNLOCK_GIANT(vfslocked);
>  	fdrop(fp, td);
>  	free(buf, M_TEMP);
> +	free(lbuf, M_TEMP);
>  	return (error);
>  }
>  
> 
> Roman, I think that this patch can be commited (if testing passes :))
> thnx!

yes.... this is the version of the patch I posted to you + the comment changed, right?
From dchagin at freebsd.org  Mon Sep  8 07:30:23 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Mon Sep  8 07:30:30 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
	overflow or else
In-Reply-To: <20080908070505.GA20963@freebsd.org>
References: <200809072030.m87KU44I064646@freefall.freebsd.org>
	<20080907211228.GA51816@dchagin.dialup.corbina.ru>
	<20080908070505.GA20963@freebsd.org>
Message-ID: <20080908073014.GA1429@dchagin.dialup.corbina.ru>

On Mon, Sep 08, 2008 at 09:05:05AM +0200, Roman Divacky wrote:
> On Mon, Sep 08, 2008 at 01:12:28AM +0400, Chagin Dmitry wrote:
> > On Sun, Sep 07, 2008 at 08:30:04PM +0000, MITA Yoshio wrote:
> > > The following reply was made to PR kern/117010; it has been noted by GNATS.
> > > 
> > > From: MITA Yoshio <mita@ee.t.u-tokyo.ac.jp>
> > > To: bug-followup@FreeBSD.org,samflanker@gmail.com,
> > >     Chagin Dmitry <chagin.dmitry@gmail.com>,
> > >     beech@FreeBSD.org
> > > Cc:  
> > > Subject: Re: kern/117010: [linux] linux_getdents() get something like buffer overflow or else
> > > Date: Sun, 07 Sep 2008 21:42:15 +0200
> > > 
> > >  Hello, 
> > >  
> > >  I've tested a patch from Mr. Dmitry concerning Mr. Ermakov's PR:
> > >  
> > >  http://www.freebsd.org/cgi/query-pr.cgi?pr=117010
> > >  
> > >  Patch:
> > >  >From:	Chagin Dmitry <chagin.dmitry@gmail.com>
> > >  >Date:	Fri, 25 Jul 2008 10:22:46 +0400 (MSD)
> > >  
> > >  This worked!!! to make skype2 work.  
> > >  Otherwise skype2 dumped core as Mr.  reported. 
> > >  
> > >  Regards,
> > >  -----
> > >  Tested Environment: 
> > >  FreeBSD 7.0-RELEASE
> > >  linux_base-fc6-6_5
> > >  linux-glib2-2.6.6
> > >  skype-2.0.0.68,1 
> > >  
> > >  /etc/sysctl.conf:
> > >  compat.linux.osrelease=2.6.16
> > >  
> > >  /etc/make.conf:
> > >  OVERRIDE_LINUX_BASE_PORT=fc6 
> > 
> > Please, try a patch bellow:
> > 
> > diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file.c
> > index 303bc3f..413e597 100644
> > --- a/src/sys/compat/linux/linux_file.c
> > +++ b/src/sys/compat/linux/linux_file.c
> > @@ -303,9 +303,20 @@ struct l_dirent64 {
> >  	char		d_name[LINUX_NAME_MAX + 1];
> >  };
> >  
> > -#define LINUX_RECLEN(de,namlen) \
> > -    ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1))
> > +/*
> > + * Linux uses the last byte in the dirent buffer to store d_type,
> > + * at least glibc-2.7 requires it. For what l_dirent padded on 2 bytes.
> > + */
> > +#define LINUX_RECLEN(namlen)						\
> > +    roundup((offsetof(struct l_dirent, d_name) + (namlen) + 2),		\
> > +    sizeof(l_ulong))
> > +
> > +#define LINUX_RECLEN64(namlen)						\
> > +    roundup((offsetof(struct l_dirent64, d_name) + (namlen) + 1),	\
> > +    sizeof(uint64_t))
> >  
> > +#define LINUX_MAXRECLEN		max(LINUX_RECLEN(LINUX_NAME_MAX),	\
> > +				    LINUX_RECLEN64(LINUX_NAME_MAX))
> >  #define	LINUX_DIRBLKSIZ		512
> >  
> >  static int
> > @@ -318,12 +329,13 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
> >  	int len, reclen;		/* BSD-format */
> >  	caddr_t outp;			/* Linux-format */
> >  	int resid, linuxreclen=0;	/* Linux-format */
> > +	caddr_t lbuf;			/* Linux-format */
> >  	struct file *fp;
> >  	struct uio auio;
> >  	struct iovec aiov;
> >  	off_t off;
> > -	struct l_dirent linux_dirent;
> > -	struct l_dirent64 linux_dirent64;
> > +	struct l_dirent *linux_dirent;
> > +	struct l_dirent64 *linux_dirent64;
> >  	int buflen, error, eofflag, nbytes, justone;
> >  	u_long *cookies = NULL, *cookiep;
> >  	int ncookies, vfslocked;
> > @@ -359,6 +371,7 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
> >  	buflen = max(LINUX_DIRBLKSIZ, nbytes);
> >  	buflen = min(buflen, MAXBSIZE);
> >  	buf = malloc(buflen, M_TEMP, M_WAITOK);
> > +	lbuf = malloc(LINUX_MAXRECLEN, M_TEMP, M_WAITOK | M_ZERO);
> >  	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
> >  
> >  again:
> > @@ -436,8 +449,8 @@ again:
> >  		}
> >  
> >  		linuxreclen = (is64bit)
> > -		    ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen)
> > -		    : LINUX_RECLEN(&linux_dirent, bdp->d_namlen);
> > +		    ? LINUX_RECLEN64(bdp->d_namlen)
> > +		    : LINUX_RECLEN(bdp->d_namlen);
> >  
> >  		if (reclen > len || resid < linuxreclen) {
> >  			outp++;
> > @@ -446,34 +459,41 @@ again:
> >  
> >  		if (justone) {
> >  			/* readdir(2) case. */
> > -			linux_dirent.d_ino = bdp->d_fileno;
> > -			linux_dirent.d_off = (l_off_t)linuxreclen;
> > -			linux_dirent.d_reclen = (l_ushort)bdp->d_namlen;
> > -			strcpy(linux_dirent.d_name, bdp->d_name);
> > -			error = copyout(&linux_dirent, outp, linuxreclen);
> > -		} else {
> > -			if (is64bit) {
> > -				linux_dirent64.d_ino = bdp->d_fileno;
> > -				linux_dirent64.d_off = (cookiep)
> > -				    ? (l_off_t)*cookiep
> > -				    : (l_off_t)(off + reclen);
> > -				linux_dirent64.d_reclen =
> > -				    (l_ushort)linuxreclen;
> > -				linux_dirent64.d_type = bdp->d_type;
> > -				strcpy(linux_dirent64.d_name, bdp->d_name);
> > -				error = copyout(&linux_dirent64, outp,
> > -				    linuxreclen);
> > -			} else {
> > -				linux_dirent.d_ino = bdp->d_fileno;
> > -				linux_dirent.d_off = (cookiep)
> > -				    ? (l_off_t)*cookiep
> > -				    : (l_off_t)(off + reclen);
> > -				linux_dirent.d_reclen = (l_ushort)linuxreclen;
> > -				strcpy(linux_dirent.d_name, bdp->d_name);
> > -				error = copyout(&linux_dirent, outp,
> > -				    linuxreclen);
> > -			}
> > +			linux_dirent = (struct l_dirent*)lbuf;
> > +			linux_dirent->d_ino = bdp->d_fileno;
> > +			linux_dirent->d_off = (l_off_t)linuxreclen;
> > +			linux_dirent->d_reclen = (l_ushort)bdp->d_namlen;
> > +			strlcpy(linux_dirent->d_name, bdp->d_name,
> > +			    linuxreclen - offsetof(struct l_dirent, d_name));
> > +			error = copyout(linux_dirent, outp, linuxreclen);
> >  		}
> > +		if (is64bit) {
> > +			linux_dirent64 = (struct l_dirent64*)lbuf;
> > +			linux_dirent64->d_ino = bdp->d_fileno;
> > +			linux_dirent64->d_off = (cookiep)
> > +			    ? (l_off_t)*cookiep
> > +			    : (l_off_t)(off + reclen);
> > +			linux_dirent64->d_reclen = (l_ushort)linuxreclen;
> > +			linux_dirent64->d_type = bdp->d_type;
> > +			strlcpy(linux_dirent64->d_name, bdp->d_name,
> > +			    linuxreclen - offsetof(struct l_dirent64, d_name));
> > +			error = copyout(linux_dirent64, outp, linuxreclen);
> > +		} else if (!justone) {
> > +			linux_dirent = (struct l_dirent*)lbuf;
> > +			linux_dirent->d_ino = bdp->d_fileno;
> > +			linux_dirent->d_off = (cookiep)
> > +			    ? (l_off_t)*cookiep
> > +			    : (l_off_t)(off + reclen);
> > +			linux_dirent->d_reclen = (l_ushort)linuxreclen;
> > +			/*
> > +			 * Copy d_type to last byte of l_dirent buffer
> > +			 */
> > +			lbuf[linuxreclen-1] = bdp->d_type;
> > +			strlcpy(linux_dirent->d_name, bdp->d_name,
> > +			    linuxreclen - offsetof(struct l_dirent, d_name)-1);
> > +			error = copyout(linux_dirent, outp, linuxreclen);
> > +		}
> > +
> >  		if (error)
> >  			goto out;
> >  
> > @@ -509,6 +529,7 @@ out:
> >  	VFS_UNLOCK_GIANT(vfslocked);
> >  	fdrop(fp, td);
> >  	free(buf, M_TEMP);
> > +	free(lbuf, M_TEMP);
> >  	return (error);
> >  }
> >  
> > 
> > Roman, I think that this patch can be commited (if testing passes :))
> > thnx!
> 
> yes.... this is the version of the patch I posted to you + the comment changed, right?

yes

-- 
Have fun!
chd
From uspoerlein at gmail.com  Mon Sep  8 17:46:24 2008
From: uspoerlein at gmail.com (Ulrich Spoerlein)
Date: Mon Sep  8 17:46:35 2008
Subject: Update of linux-gtk2 (for linux-firefox3) possible?
Message-ID: <20080908174617.GB1543@roadrunner.spoerlein.net>

Hi,

since I'm using linux-firefox2 and the flash-plugin, I wanted to update
linux-firefox to version 3.0.1 but it wants gtk version 2.10 or newer
when only 2.6 is in ports.

Now, I don't think there are Fedora Core 4 packages of gtk2/atk2 (and
what not else) for version 2.10 available anywhere.

Any ideas what to do? Which ports need to be updated in sync with gtk2?

Cheers,
Ulrich Spoerlein
-- 
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
From mita at ee.t.u-tokyo.ac.jp  Mon Sep  8 19:38:50 2008
From: mita at ee.t.u-tokyo.ac.jp (MITA Yoshio)
Date: Mon Sep  8 19:38:57 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
	overflow or else
In-Reply-To: <20080907211228.GA51816@dchagin.dialup.corbina.ru>
References: <200809072030.m87KU44I064646@freefall.freebsd.org>
	<20080907211228.GA51816@dchagin.dialup.corbina.ru>
Message-ID: <7o4p4q4edz.wl%mita@ee.t.u-tokyo.ac.jp>

Hello,

> Please, try a patch bellow:
> 
> diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file.c
> index 303bc3f..413e597 100644
> --- a/src/sys/compat/linux/linux_file.c
> +++ b/src/sys/compat/linux/linux_file.c
[Snip]

>Roman, I think that this patch can be commited (if testing passes :))
>thnx!

Yes, this works also nicely!  Tested both on multi-core machine
(Core2Duo 6550 2.33GHz) and single-core notebook (Pentium M
1.30GHz) under 7.0-RELEASE(-p4)


>-- 
>Have fun!  chd

Thank you very much!
---
MITA Yoshio
From rdivacky at FreeBSD.org  Mon Sep  8 20:05:14 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Mon Sep  8 20:05:20 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <200809080222.m882MIdL006640@freefall.freebsd.org>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
Message-ID: <20080908200524.GA74912@freebsd.org>

On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
> o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux

kostik, I believe you commited a fix for this... can be closed

> o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
> o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove

fix for this is about to be commited

> o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
> o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
> o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
> o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
> 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/29698   emulation  [linux] [patch] linux ipcs doesn'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

can you ports guys look at the ports related issues?
From kib at FreeBSD.org  Mon Sep  8 20:08:46 2008
From: kib at FreeBSD.org (kib@FreeBSD.org)
Date: Mon Sep  8 20:08:52 2008
Subject: kern/122318: [linux] [cmake]: Segmentation fault when running
	Linux cmake
Message-ID: <200809082008.m88K8jkT040357@freefall.freebsd.org>

Synopsis: [linux] [cmake]: Segmentation fault when running Linux cmake

State-Changed-From-To: open->patched
State-Changed-By: kib
State-Changed-When: Mon Sep 8 20:07:53 UTC 2008
State-Changed-Why: 
Chagin supplied the patch. Patch committed to HEAD, MFC set.


Responsible-Changed-From-To: freebsd-emulation->kib
Responsible-Changed-By: kib
Responsible-Changed-When: Mon Sep 8 20:07:53 UTC 2008
Responsible-Changed-Why: 
Chagin supplied the patch. Patch committed to HEAD, MFC set.

http://www.freebsd.org/cgi/query-pr.cgi?pr=122318
From scf at FreeBSD.org  Mon Sep  8 20:21:59 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Mon Sep  8 20:22:15 2008
Subject: kern/122318: [linux] [cmake]: Segmentation fault when running
 Linux cmake
In-Reply-To: <200809082008.m88K8jkT040357@freefall.freebsd.org>
References: <200809082008.m88K8jkT040357@freefall.freebsd.org>
Message-ID: <alpine.BSF.2.00.0809081511220.70036@thor.farley.org>

On Mon, 8 Sep 2008, kib@FreeBSD.org wrote:

> Synopsis: [linux] [cmake]: Segmentation fault when running Linux cmake
>
> State-Changed-From-To: open->patched
> State-Changed-By: kib
> State-Changed-When: Mon Sep 8 20:07:53 UTC 2008
> State-Changed-Why:
> Chagin supplied the patch. Patch committed to HEAD, MFC set.
>
>
> Responsible-Changed-From-To: freebsd-emulation->kib
> Responsible-Changed-By: kib
> Responsible-Changed-When: Mon Sep 8 20:07:53 UTC 2008
> Responsible-Changed-Why:
> Chagin supplied the patch. Patch committed to HEAD, MFC set.

Thank you Chagin and Kostik!

Sean
-- 
scf@FreeBSD.org
From nox at jelal.kn-bremen.de  Mon Sep  8 20:35:55 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Mon Sep  8 20:36:01 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <20080907215300.GH2038@deviant.kiev.zoral.com.ua>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
	<200809062215.m86MF6NS040797@saturn.kn-bremen.de>
	<20080907215300.GH2038@deviant.kiev.zoral.com.ua>
Message-ID: <20080908203423.GA12147@saturn.kn-bremen.de>

On Mon, Sep 08, 2008 at 12:53:00AM +0300, Kostik Belousov wrote:
> On Sun, Sep 07, 2008 at 12:15:06AM +0200, Juergen Lock wrote:
> > In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write:
> > >-=-=-=-=-=-
> > >
> > >On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
> > >> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
> > >> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
> > >> > 
> > >> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> > >> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
> > >> > >>the following command, Linux applications (chroot, acroread, ls) will
> > >> > >>start core dumping:
> > >> > >>    qemu-system-x86_64 -m 512 \
> > >> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
> > >> > >>    -std-vga -parallel none -serial none -monitor stdio \
> > >> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> > >> > >>
> > >> > >>Loading kqemu.ko does not cause the problem, but the cores start a
> > >> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
> > >> > >>the cores still happen but more randomly.  I even tried unloading all
> > >> > >>linux modules and reloading them without luck.  It takes a reboot.
> > >> > >>
> > >> > >>Packages:
> > >> > >>qemu-devel-0.9.1s.20080620_1
> > >> > >>kqemu-kmod-devel-1.4.0.p1
> > >> > >>linux_base-f8-8_4
> > >> > >>
> > >> > >>sysctl:
> > >> > >>compat.linux.osrelease: 2.6.16
> > >> > >>
> > >> > >>dmesg:
> > >> > >>kqemu version 0x00010400
> > >> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
> > >> > >>
> > >> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
> > >> > >>signals from Chagin.
> > >> > >
> > >> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
> > >> > >apps?  thnx!
> > >> > 
> > >> > Here they are (good and bad):
> > >> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
> > >> > 
> > >> > The good trace is after the bad trace.  I just kept running ktrace
> > >> > /compat/linux/bin/date over and over until I got a good trace.  Before
> > >> > loading kqemu and running qemu, there were no core dumps.  Also, I
> > >> > compared two bad traces and they were basically the same except for PID
> > >> > and a couple of addresses (still very close in value).
> > >> > 
> > >> 
> > >> Most likely it is a tls problem again, some days ago kib@ has made MFC
> > >> r182684, probably it will help..
> > >
> > >I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
> > >it tries to use GDT/LDT. This probably has unwanted interaction with
> > >PCB_GS32BIT.
> > 
> > Wow.  That corner of the code had escaped me so far, and yes this (in
> > amd64/linux32) looks like it won't like kqemu's seperating of the gdts
> > on SMP indeed.  (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and
> > lets linux processes manipulate the segment pointed to by it, and when
> > kqemu is (or was) running this won't be used by all cpus, see older threads
> > like
> > 	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html
> > for the reasons.)
> > 
> >  What I wonder tho is, won't this also cause problems without kqemu when
> > there are linux processes running on multiple cpus that manipulate this
> > segment because the gdt is then shared between the cpus?  (like, linux
> > process on cpu 0 changes the segment, then linux process on cpu 1 comes
> > along and changes it again and then the linux process on cpu 0 will pick
> > it up from cpu 1?)  At least I must have somehow assumed the shared gdt
> > wouldn't be changed later because of reasons like this...
> 
> Very nice catch! Me and Peter Wemm discussed the right approach,
> that consists of actually providing per-cpu GDT. Patch is at
> http://people.freebsd.org/~kib/misc/amd64_gdt.1.patch
> 
> Please, test and give a feedback. Even reports about thinks working
> the same as before the patch are important.

OK I just tested the patch on RELENG_7 (updated my amd64 SMP box from
RELENG_7_0) and found no problems.  (I tested linux date(1), googleearth,
kqemu, and a few other non-linux things so far.)

 Thanx,
	Juergen
From kostikbel at gmail.com  Mon Sep  8 20:43:38 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Sep  8 20:43:44 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <20080908203423.GA12147@saturn.kn-bremen.de>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
	<20080830113448.GA2152@dchagin.dialup.corbina.ru>
	<alpine.BSF.2.00.0809021552040.7934@thor.farley.org>
	<20080906104659.GA2113@dchagin.dialup.corbina.ru>
	<200809062215.m86MF6NS040797@saturn.kn-bremen.de>
	<20080907215300.GH2038@deviant.kiev.zoral.com.ua>
	<20080908203423.GA12147@saturn.kn-bremen.de>
Message-ID: <20080908204331.GC39652@deviant.kiev.zoral.com.ua>

On Mon, Sep 08, 2008 at 10:34:23PM +0200, Juergen Lock wrote:
> On Mon, Sep 08, 2008 at 12:53:00AM +0300, Kostik Belousov wrote:
> > On Sun, Sep 07, 2008 at 12:15:06AM +0200, Juergen Lock wrote:
> > > In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write:
> > > >-=-=-=-=-=-
> > > >
> > > >On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote:
> > > >> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote:
> > > >> > On Sat, 30 Aug 2008, Chagin Dmitry wrote:
> > > >> > 
> > > >> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> > > >> > >>I am having trouble with kqemu.ko and linux.ko.  If I run qemu with
> > > >> > >>the following command, Linux applications (chroot, acroread, ls) will
> > > >> > >>start core dumping:
> > > >> > >>    qemu-system-x86_64 -m 512 \
> > > >> > >>    -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
> > > >> > >>    -std-vga -parallel none -serial none -monitor stdio \
> > > >> > >>    -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> > > >> > >>
> > > >> > >>Loading kqemu.ko does not cause the problem, but the cores start a
> > > >> > >>little after WinXP starts running.  Unloading kqemu.ko does not help;
> > > >> > >>the cores still happen but more randomly.  I even tried unloading all
> > > >> > >>linux modules and reloading them without luck.  It takes a reboot.
> > > >> > >>
> > > >> > >>Packages:
> > > >> > >>qemu-devel-0.9.1s.20080620_1
> > > >> > >>kqemu-kmod-devel-1.4.0.p1
> > > >> > >>linux_base-f8-8_4
> > > >> > >>
> > > >> > >>sysctl:
> > > >> > >>compat.linux.osrelease: 2.6.16
> > > >> > >>
> > > >> > >>dmesg:
> > > >> > >>kqemu version 0x00010400
> > > >> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB.
> > > >> > >>
> > > >> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT
> > > >> > >>signals from Chagin.
> > > >> > >
> > > >> > >Interestingly... Sean, can you provide ktrace/kdump log of coring
> > > >> > >apps?  thnx!
> > > >> > 
> > > >> > Here they are (good and bad):
> > > >> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/
> > > >> > 
> > > >> > The good trace is after the bad trace.  I just kept running ktrace
> > > >> > /compat/linux/bin/date over and over until I got a good trace.  Before
> > > >> > loading kqemu and running qemu, there were no core dumps.  Also, I
> > > >> > compared two bad traces and they were basically the same except for PID
> > > >> > and a couple of addresses (still very close in value).
> > > >> > 
> > > >> 
> > > >> Most likely it is a tls problem again, some days ago kib@ has made MFC
> > > >> r182684, probably it will help..
> > > >
> > > >I doubt it. This seems to be an ingenious kqemu bug. As far as I remember,
> > > >it tries to use GDT/LDT. This probably has unwanted interaction with
> > > >PCB_GS32BIT.
> > > 
> > > Wow.  That corner of the code had escaped me so far, and yes this (in
> > > amd64/linux32) looks like it won't like kqemu's seperating of the gdts
> > > on SMP indeed.  (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and
> > > lets linux processes manipulate the segment pointed to by it, and when
> > > kqemu is (or was) running this won't be used by all cpus, see older threads
> > > like
> > > 	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html
> > > for the reasons.)
> > > 
> > >  What I wonder tho is, won't this also cause problems without kqemu when
> > > there are linux processes running on multiple cpus that manipulate this
> > > segment because the gdt is then shared between the cpus?  (like, linux
> > > process on cpu 0 changes the segment, then linux process on cpu 1 comes
> > > along and changes it again and then the linux process on cpu 0 will pick
> > > it up from cpu 1?)  At least I must have somehow assumed the shared gdt
> > > wouldn't be changed later because of reasons like this...
> > 
> > Very nice catch! Me and Peter Wemm discussed the right approach,
> > that consists of actually providing per-cpu GDT. Patch is at
> > http://people.freebsd.org/~kib/misc/amd64_gdt.1.patch
> > 
> > Please, test and give a feedback. Even reports about thinks working
> > the same as before the patch are important.
> 
> OK I just tested the patch on RELENG_7 (updated my amd64 SMP box from
> RELENG_7_0) and found no problems.  (I tested linux date(1), googleearth,
> kqemu, and a few other non-linux things so far.)

Thank you for the testing. Patch was committed to HEAD already (separated
into four mostly self-contained commits).
I expect the MFC in one week, your testing is important for MFC decision.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080908/3b6d8335/attachment.pgp
From dchagin at freebsd.org  Tue Sep  9 07:16:47 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Sep  9 07:16:53 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080908200524.GA74912@freebsd.org>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
Message-ID: <20080909071335.GA1522@dchagin.dialup.corbina.ru>

On Mon, Sep 08, 2008 at 10:05:24PM +0200, Roman Divacky wrote:
> On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> > 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails

what we will do with it? as I already wrote it not a bug.
it's glibc isatty() call, which is used by many programs for check file
descriptors.

thnx!

-- 
Have fun!
chd
From rdivacky at freebsd.org  Tue Sep  9 07:25:00 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Sep  9 07:25:07 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080909071335.GA1522@dchagin.dialup.corbina.ru>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
	<20080909071335.GA1522@dchagin.dialup.corbina.ru>
Message-ID: <20080909072509.GA10750@freebsd.org>

On Tue, Sep 09, 2008 at 11:13:35AM +0400, Chagin Dmitry wrote:
> On Mon, Sep 08, 2008 at 10:05:24PM +0200, Roman Divacky wrote:
> > On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> > > 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
> 
> what we will do with it? as I already wrote it not a bug.
> it's glibc isatty() call, which is used by many programs for check file
> descriptors.

I dont understand the PR much.... the TCGETS is already implemented but it fails
for some fd... I didnt find any check in the linux code for the fd being a tty.

Can we close this PR as invalid? Does the error actually cause some problems, Yuri?
From dchagin at freebsd.org  Tue Sep  9 07:31:28 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Sep  9 07:31:35 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080909072509.GA10750@freebsd.org>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
	<20080909071335.GA1522@dchagin.dialup.corbina.ru>
	<20080909072509.GA10750@freebsd.org>
Message-ID: <20080909073108.GA1665@dchagin.dialup.corbina.ru>

On Tue, Sep 09, 2008 at 09:25:09AM +0200, Roman Divacky wrote:
> On Tue, Sep 09, 2008 at 11:13:35AM +0400, Chagin Dmitry wrote:
> > On Mon, Sep 08, 2008 at 10:05:24PM +0200, Roman Divacky wrote:
> > > On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> > > > 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
> > 
> > what we will do with it? as I already wrote it not a bug.
> > it's glibc isatty() call, which is used by many programs for check file
> > descriptors.
> 
> I dont understand the PR much.... the TCGETS is already implemented but it fails
> for some fd... I didnt find any check in the linux code for the fd being a tty.
> 

csh for example


-- 
Have fun!
chd
From rdivacky at freebsd.org  Tue Sep  9 07:34:32 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Sep  9 07:34:38 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080909073108.GA1665@dchagin.dialup.corbina.ru>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
	<20080909071335.GA1522@dchagin.dialup.corbina.ru>
	<20080909072509.GA10750@freebsd.org>
	<20080909073108.GA1665@dchagin.dialup.corbina.ru>
Message-ID: <20080909073443.GA11721@freebsd.org>

On Tue, Sep 09, 2008 at 11:31:08AM +0400, Chagin Dmitry wrote:
> On Tue, Sep 09, 2008 at 09:25:09AM +0200, Roman Divacky wrote:
> > On Tue, Sep 09, 2008 at 11:13:35AM +0400, Chagin Dmitry wrote:
> > > On Mon, Sep 08, 2008 at 10:05:24PM +0200, Roman Divacky wrote:
> > > > On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> > > > > 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
> > > 
> > > what we will do with it? as I already wrote it not a bug.
> > > it's glibc isatty() call, which is used by many programs for check file
> > > descriptors.
> > 
> > I dont understand the PR much.... the TCGETS is already implemented but it fails
> > for some fd... I didnt find any check in the linux code for the fd being a tty.
> > 
> 
> csh for example

csh does what?
From dchagin at freebsd.org  Tue Sep  9 07:58:33 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Sep  9 07:58:39 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080909073443.GA11721@freebsd.org>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
	<20080909071335.GA1522@dchagin.dialup.corbina.ru>
	<20080909072509.GA10750@freebsd.org>
	<20080909073108.GA1665@dchagin.dialup.corbina.ru>
	<20080909073443.GA11721@freebsd.org>
Message-ID: <20080909075636.GA1763@dchagin.dialup.corbina.ru>

On Tue, Sep 09, 2008 at 09:34:43AM +0200, Roman Divacky wrote:
> On Tue, Sep 09, 2008 at 11:31:08AM +0400, Chagin Dmitry wrote:
> > On Tue, Sep 09, 2008 at 09:25:09AM +0200, Roman Divacky wrote:
> > > On Tue, Sep 09, 2008 at 11:13:35AM +0400, Chagin Dmitry wrote:
> > > > On Mon, Sep 08, 2008 at 10:05:24PM +0200, Roman Divacky wrote:
> > > > > On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> > > > > > 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
> > > > 
> > > > what we will do with it? as I already wrote it not a bug.
> > > > it's glibc isatty() call, which is used by many programs for check file
> > > > descriptors.
> > > 
> > > I dont understand the PR much.... the TCGETS is already implemented but it fails
> > > for some fd... I didnt find any check in the linux code for the fd being a tty.
> > > 
> > 
> > csh for example
> 
> csh does what?

very often uses isatty(), it from fbsd:

 19750 csh      0.000010 CALL  fcntl(0x6,F_SETFD,FD_CLOEXEC)
 19750 csh      0.000010 RET   fcntl 0
 19750 csh      0.000023 CALL  ioctl(0x6,TIOCGETA,0x7fffffffc740)
 19750 csh      0.000011 RET   ioctl -1 errno 25 Inappropriate ioctl for device
 19750 csh      0.000011 CALL  sigprocmask(SIG_BLOCK,0,0x57b1c8)

-- 
Have fun!
chd
From rdivacky at freebsd.org  Tue Sep  9 08:00:05 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Sep  9 08:00:11 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080909075636.GA1763@dchagin.dialup.corbina.ru>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
	<20080909071335.GA1522@dchagin.dialup.corbina.ru>
	<20080909072509.GA10750@freebsd.org>
	<20080909073108.GA1665@dchagin.dialup.corbina.ru>
	<20080909073443.GA11721@freebsd.org>
	<20080909075636.GA1763@dchagin.dialup.corbina.ru>
Message-ID: <20080909080011.GA13405@freebsd.org>

On Tue, Sep 09, 2008 at 11:56:36AM +0400, Chagin Dmitry wrote:
> On Tue, Sep 09, 2008 at 09:34:43AM +0200, Roman Divacky wrote:
> > On Tue, Sep 09, 2008 at 11:31:08AM +0400, Chagin Dmitry wrote:
> > > On Tue, Sep 09, 2008 at 09:25:09AM +0200, Roman Divacky wrote:
> > > > On Tue, Sep 09, 2008 at 11:13:35AM +0400, Chagin Dmitry wrote:
> > > > > On Mon, Sep 08, 2008 at 10:05:24PM +0200, Roman Divacky wrote:
> > > > > > On Mon, Sep 08, 2008 at 02:22:18AM +0000, FreeBSD bugmaster wrote:
> > > > > > > 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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
> > > > > 
> > > > > what we will do with it? as I already wrote it not a bug.
> > > > > it's glibc isatty() call, which is used by many programs for check file
> > > > > descriptors.
> > > > 
> > > > I dont understand the PR much.... the TCGETS is already implemented but it fails
> > > > for some fd... I didnt find any check in the linux code for the fd being a tty.
> > > > 
> > > 
> > > csh for example
> > 
> > csh does what?
> 
> very often uses isatty(), it from fbsd:
> 
>  19750 csh      0.000010 CALL  fcntl(0x6,F_SETFD,FD_CLOEXEC)
>  19750 csh      0.000010 RET   fcntl 0
>  19750 csh      0.000023 CALL  ioctl(0x6,TIOCGETA,0x7fffffffc740)
>  19750 csh      0.000011 RET   ioctl -1 errno 25 Inappropriate ioctl for device
>  19750 csh      0.000011 CALL  sigprocmask(SIG_BLOCK,0,0x57b1c8)

what is the 0x6 fd? I'll see if it fails on linux too (I believe it does)
From rdivacky at freebsd.org  Tue Sep  9 08:03:28 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Sep  9 08:03:35 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080909075636.GA1763@dchagin.dialup.corbina.ru>
References: <200809080222.m882MIdL006640@freefall.freebsd.org>
	<20080908200524.GA74912@freebsd.org>
	<20080909071335.GA1522@dchagin.dialup.corbina.ru>
	<20080909072509.GA10750@freebsd.org>
	<20080909073108.GA1665@dchagin.dialup.corbina.ru>
	<20080909073443.GA11721@freebsd.org>
	<20080909075636.GA1763@dchagin.dialup.corbina.ru>
Message-ID: <20080909080339.GA13747@freebsd.org>

> very often uses isatty(), it from fbsd:
> 
>  19750 csh      0.000010 CALL  fcntl(0x6,F_SETFD,FD_CLOEXEC)
>  19750 csh      0.000010 RET   fcntl 0
>  19750 csh      0.000023 CALL  ioctl(0x6,TIOCGETA,0x7fffffffc740)
>  19750 csh      0.000011 RET   ioctl -1 errno 25 Inappropriate ioctl for device
>  19750 csh      0.000011 CALL  sigprocmask(SIG_BLOCK,0,0x57b1c8)

exactly the same happens on Linux

ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff02f1db00) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff02f1de10) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff02f1dae0) = -1 ENOTTY (Inappropriate ioctl for device)

this is an app bug, anyone against me closing the PR?

roman
From saper at system.pl  Tue Sep  9 16:05:03 2008
From: saper at system.pl (Marcin Cieslak)
Date: Tue Sep  9 16:05:14 2008
Subject: kern/102956: [linux] [patch] Add partial support for SO_PEERCRED
 in Linux emulation
Message-ID: <48C691A7.5060302@system.pl>


Hello,

> (1) The value of LINUX_SO_PEERCRED is incorrect for Alpha, it should be 18 on
> that platform.

Well, in the meantime Alpha support is gone...

> (2) I'm a bit worried about pid not being set, but this may (may) be OK. On
> Linux, generally speaking you are guaranteed that either you get (0, -1,
> -1) or (pid, uid, gid), but not a blend of both. As we support the pid
> for SCM_CREDS, we might also consider adding a LOCAL_PEERPID for use by
> the linux emulator to query the remote pid (we'd need to add that where
> the peercred is currently cached though).

Will remote PID always be available?
> 
> (3) LOG_WARNING should perhaps be LOG_DEBUG or something more consistent with
> the res of the linuxulator.

I agree. This should be LOG_DEBUG.

  > FYI, I'm not sure I like that we just pass all other socket options 
through to
> getsockopt() without transformation or an error, it seems failure-prone. We
> may end up returning invalid data, etc, but that's not caused by this patch,
> but a generally poor failure mode in the linuxulator.

I agree. Probably we should explicitly list all supported socket option. 
I think most of the translation layer is coded for "fixing known 
differences" vs. "explicit support for X, Y, Z returning EA, EB or EC".

--Marcin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080909/aad11c7d/signature.pgp
From rdivacky at FreeBSD.org  Tue Sep  9 16:10:31 2008
From: rdivacky at FreeBSD.org (rdivacky@FreeBSD.org)
Date: Tue Sep  9 16:10:38 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
	overflow or else
Message-ID: <200809091610.m89GAUPi084832@freefall.freebsd.org>

Synopsis: [linux] linux_getdents() get something like buffer overflow or else

State-Changed-From-To: open->closed
State-Changed-By: rdivacky
State-Changed-When: Tue Sep 9 16:07:44 UTC 2008
State-Changed-Why: 
Fix commited in r182892.


http://www.freebsd.org/cgi/query-pr.cgi?pr=117010
From dfilter at FreeBSD.ORG  Tue Sep  9 16:20:04 2008
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Tue Sep  9 16:21:00 2008
Subject: kern/117010: commit references a PR
Message-ID: <200809091620.m89GK3aN086511@freefall.freebsd.org>

The following reply was made to PR kern/117010; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/117010: commit references a PR
Date: Tue,  9 Sep 2008 16:00:49 +0000 (UTC)

 rdivacky    2008-09-09 16:00:17 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/compat/linux     linux_file.c 
   Log:
   SVN rev 182892 on 2008-09-09 16:00:17Z by rdivacky
   
   Getdents requires padding with 2 bytes instead of 1 byte
   as with getdents64. The last byte is used for storing
   the d_type, add this to plain getdents case where it was
   missing before. Also change the code to use strlcpy instead
   of plain strcpy. This changes fix the getdents crash we
   had reports about (hl2 server etc.)
   
   PR:             kern/117010
   MFC after:      1 week
   Submitted by:   Dmitry Chagin (dchagin@)
   Tested by:      MITA Yoshio <mita ee.t.u-tokyo.ac jp>
   Approved by:    kib (mentor)
   
   Revision  Changes    Path
   1.115     +54 -33    src/sys/compat/linux/linux_file.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
From samflanker at gmail.com  Wed Sep 10 08:07:41 2008
From: samflanker at gmail.com (sam)
Date: Wed Sep 10 08:07:54 2008
Subject: kern/117010: [linux] linux_getdents() get something like buffer
 overflow or else
Message-ID: <48C77AE9.90700@gmail.com>

On Mon, Sep 08, 2008 at 01:12:28AM +0400, Chagin Dmitry wrote:
>/ Please, try a patch bellow:
/>/ 
/>/ diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file.c
/>/ index 303bc3f..413e597 100644
/>/ --- a/src/sys/compat/linux/linux_file.c
/>/ +++ b/src/sys/compat/linux/linux_file.c
/>/ @@ -303,9 +303,20 @@ struct l_dirent64 {
/>/  	char		d_name[LINUX_NAME_MAX + 1];
/>/  };
/>/  
/>/ -#define LINUX_RECLEN(de,namlen) \
/>/ -    ALIGN((((char *)&(de)->d_name - (char *)de) + (namlen) + 1))
/>/ +/*
/>/ + * Linux uses the last byte in the dirent buffer to store d_type,
/>/ + * at least glibc-2.7 requires it. For what l_dirent padded on 2 bytes.
/>/ + */
/>/ +#define LINUX_RECLEN(namlen)						\
/>/ +    roundup((offsetof(struct l_dirent, d_name) + (namlen) + 2),		\
/>/ +    sizeof(l_ulong))
/>/ +
/>/ +#define LINUX_RECLEN64(namlen)						\
/>/ +    roundup((offsetof(struct l_dirent64, d_name) + (namlen) + 1),	\
/>/ +    sizeof(uint64_t))
/>/  
/>/ +#define LINUX_MAXRECLEN		max(LINUX_RECLEN(LINUX_NAME_MAX),	\
/>/ +				    LINUX_RECLEN64(LINUX_NAME_MAX))
/>/  #define	LINUX_DIRBLKSIZ		512
/>/  
/>/  static int
/>/ @@ -318,12 +329,13 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
/>/  	int len, reclen;		/* BSD-format */
/>/  	caddr_t outp;			/* Linux-format */
/>/  	int resid, linuxreclen=0;	/* Linux-format */
/>/ +	caddr_t lbuf;			/* Linux-format */
/>/  	struct file *fp;
/>/  	struct uio auio;
/>/  	struct iovec aiov;
/>/  	off_t off;
/>/ -	struct l_dirent linux_dirent;
/>/ -	struct l_dirent64 linux_dirent64;
/>/ +	struct l_dirent *linux_dirent;
/>/ +	struct l_dirent64 *linux_dirent64;
/>/  	int buflen, error, eofflag, nbytes, justone;
/>/  	u_long *cookies = NULL, *cookiep;
/>/  	int ncookies, vfslocked;
/>/ @@ -359,6 +371,7 @@ getdents_common(struct thread *td, struct linux_getdents64_args *args,
/>/  	buflen = max(LINUX_DIRBLKSIZ, nbytes);
/>/  	buflen = min(buflen, MAXBSIZE);
/>/  	buf = malloc(buflen, M_TEMP, M_WAITOK);
/>/ +	lbuf = malloc(LINUX_MAXRECLEN, M_TEMP, M_WAITOK | M_ZERO);
/>/  	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
/>/  
/>/  again:
/>/ @@ -436,8 +449,8 @@ again:
/>/  		}
/>/  
/>/  		linuxreclen = (is64bit)
/>/ -		    ? LINUX_RECLEN(&linux_dirent64, bdp->d_namlen)
/>/ -		    : LINUX_RECLEN(&linux_dirent, bdp->d_namlen);
/>/ +		    ? LINUX_RECLEN64(bdp->d_namlen)
/>/ +		    : LINUX_RECLEN(bdp->d_namlen);
/>/  
/>/  		if (reclen > len || resid < linuxreclen) {
/>/  			outp++;
/>/ @@ -446,34 +459,41 @@ again:
/>/  
/>/  		if (justone) {
/>/  			/* readdir(2) case. */
/>/ -			linux_dirent.d_ino = bdp->d_fileno;
/>/ -			linux_dirent.d_off = (l_off_t)linuxreclen;
/>/ -			linux_dirent.d_reclen = (l_ushort)bdp->d_namlen;
/>/ -			strcpy(linux_dirent.d_name, bdp->d_name);
/>/ -			error = copyout(&linux_dirent, outp, linuxreclen);
/>/ -		} else {
/>/ -			if (is64bit) {
/>/ -				linux_dirent64.d_ino = bdp->d_fileno;
/>/ -				linux_dirent64.d_off = (cookiep)
/>/ -				    ? (l_off_t)*cookiep
/>/ -				    : (l_off_t)(off + reclen);
/>/ -				linux_dirent64.d_reclen =
/>/ -				    (l_ushort)linuxreclen;
/>/ -				linux_dirent64.d_type = bdp->d_type;
/>/ -				strcpy(linux_dirent64.d_name, bdp->d_name);
/>/ -				error = copyout(&linux_dirent64, outp,
/>/ -				    linuxreclen);
/>/ -			} else {
/>/ -				linux_dirent.d_ino = bdp->d_fileno;
/>/ -				linux_dirent.d_off = (cookiep)
/>/ -				    ? (l_off_t)*cookiep
/>/ -				    : (l_off_t)(off + reclen);
/>/ -				linux_dirent.d_reclen = (l_ushort)linuxreclen;
/>/ -				strcpy(linux_dirent.d_name, bdp->d_name);
/>/ -				error = copyout(&linux_dirent, outp,
/>/ -				    linuxreclen);
/>/ -			}
/>/ +			linux_dirent = (struct l_dirent*)lbuf;
/>/ +			linux_dirent->d_ino = bdp->d_fileno;
/>/ +			linux_dirent->d_off = (l_off_t)linuxreclen;
/>/ +			linux_dirent->d_reclen = (l_ushort)bdp->d_namlen;
/>/ +			strlcpy(linux_dirent->d_name, bdp->d_name,
/>/ +			    linuxreclen - offsetof(struct l_dirent, d_name));
/>/ +			error = copyout(linux_dirent, outp, linuxreclen);
/>/  		}
/>/ +		if (is64bit) {
/>/ +			linux_dirent64 = (struct l_dirent64*)lbuf;
/>/ +			linux_dirent64->d_ino = bdp->d_fileno;
/>/ +			linux_dirent64->d_off = (cookiep)
/>/ +			    ? (l_off_t)*cookiep
/>/ +			    : (l_off_t)(off + reclen);
/>/ +			linux_dirent64->d_reclen = (l_ushort)linuxreclen;
/>/ +			linux_dirent64->d_type = bdp->d_type;
/>/ +			strlcpy(linux_dirent64->d_name, bdp->d_name,
/>/ +			    linuxreclen - offsetof(struct l_dirent64, d_name));
/>/ +			error = copyout(linux_dirent64, outp, linuxreclen);
/>/ +		} else if (!justone) {
/>/ +			linux_dirent = (struct l_dirent*)lbuf;
/>/ +			linux_dirent->d_ino = bdp->d_fileno;
/>/ +			linux_dirent->d_off = (cookiep)
/>/ +			    ? (l_off_t)*cookiep
/>/ +			    : (l_off_t)(off + reclen);
/>/ +			linux_dirent->d_reclen = (l_ushort)linuxreclen;
/>/ +			/*
/>/ +			 * Copy d_type to last byte of l_dirent buffer
/>/ +			 */
/>/ +			lbuf[linuxreclen-1] = bdp->d_type;
/>/ +			strlcpy(linux_dirent->d_name, bdp->d_name,
/>/ +			    linuxreclen - offsetof(struct l_dirent, d_name)-1);
/>/ +			error = copyout(linux_dirent, outp, linuxreclen);
/>/ +		}
/>/ +
/>/  		if (error)
/>/  			goto out;
/>/  
/>/ @@ -509,6 +529,7 @@ out:
/>/  	VFS_UNLOCK_GIANT(vfslocked);
/>/  	fdrop(fp, td);
/>/  	free(buf, M_TEMP);
/>/ +	free(lbuf, M_TEMP);
/>/  	return (error);
/>/  }
/>/  
/>/ 
/>/ Roman, I think that this patch can be commited (if testing passes :))
/>/ thnx!

Hello

Iam tested this patch on my old testing pack (with source)
http://cs.udmvt.ru/files/temp/linux_getdents.tar.bz2
(bin.file linux_getdents_static compiled on system Linux 2.6.9 with old glibc version)

# uname -a
FreeBSD damascus 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 25 12:41:55 MSD 2008     root@static:/usr/obj/usr/src/sys/DAMASCUS  i386

# sysctl compat.linux.osrelease
compat.linux.osrelease: 2.6.16

# pkg_info|grep linux
linux_base-fc-4_13  Base set of packages needed in Linux mode (for i386/amd64)


/before patch
-------------------------------------------------------------------
# ./linux_getdents_static ./temp/
Reading...
.
..
ak47-1.wav
ak47-2.wav
***
sliderelease1.wav

Closing...
*** glibc detected *** ./linux_getdents_static: double free or corruption (!prev): 0x080c7688 ***
======= Backtrace: =========
[0x80515fe]
[0x8054cdb]
[0x80564b8]
[0x804828b]
[0x80484ab]
[0x8048151]
======= Memory map: ========
08048000-080c3000 r-xp 0008d000 00:00 4168734     /usr/home/venom/temp/temp/devel/linux/linux_getdents_static
080c3000-080c6000 rw-p 00025000 00:00 0
080c6000-080e8000 rwxp 00025000 00:00 0
480c3000-480c4000 rwxp 0013d000 00:00 0
48100000-48121000 rwxp 0013d000 00:00 0
48121000-48200000 ---p 0013d000 00:00 0
bfbe0000-bfc00000 rwxp 00020000 00:00 0
Abort trap: 6 (core dumped)
-------------------------------------------------------------------

after patch

-------------------------------------------------------------------
# ./linux_getdents_static ./temp/
Reading...
.
..
ak47-1.wav
ak47-2.wav
***
sliderelease1.wav


Closing...Done!
-------------------------------------------------------------------

thanks

/Vladimir Ermakov


From pfgshield-freebsd at yahoo.com  Fri Sep 12 16:58:12 2008
From: pfgshield-freebsd at yahoo.com (Pedro Giffuni)
Date: Fri Sep 12 16:58:19 2008
Subject: VirtualBox looks for FreeBSD developer
Message-ID: <880886.92445.qm@web32705.mail.mud.yahoo.com>

Hi Klaus;

Thank you for your posting on -ports:

http://docs.freebsd.org/cgi/mid.cgi?48C8F051.7060107

I think either -emulation or -virtualization might be better targets for such discussion though (indeed we did discuss it briefly in the virtualization list). 

Some of us are very interested in having VirtualBox on FreeBSD, and I understand the FreeBSD Foundation would consider sponsoring such effort if someone with the know-how makes the proposal.

I don't have what's needed but I was thinking maybe someone that knows well the kqemu module would have that know-how... Perhaps you could give us more insight on what needs to be done/documented?

Pedro.


__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 
From julian at elischer.org  Fri Sep 12 17:59:38 2008
From: julian at elischer.org (Julian Elischer)
Date: Fri Sep 12 17:59:46 2008
Subject: VirtualBox looks for FreeBSD developer
In-Reply-To: <880886.92445.qm@web32705.mail.mud.yahoo.com>
References: <880886.92445.qm@web32705.mail.mud.yahoo.com>
Message-ID: <48CAAAC5.2050707@elischer.org>

Pedro Giffuni wrote:
> Hi Klaus;
> 
> Thank you for your posting on -ports:
> 
> http://docs.freebsd.org/cgi/mid.cgi?48C8F051.7060107
> 
> I think either -emulation or -virtualization might be better
> targets for such discussion though (indeed we did discuss it
> briefly in the virtualization list).
> 
> Some of us are very interested in having VirtualBox on FreeBSD, and
> I understand the FreeBSD Foundation would consider sponsoring such
> effort if someone with the know-how makes the proposal.

Klause,

freebsd-virtualization@freebsd.org (this mail is there) is the place 
you want but it is a new list and not everyone on
freebsd-emulation@freebsd.org will be on it (yet).

Freebsd ports is for ported software, but virtualbox doesn't
really come into that category yet..

> 
> I don't have what's needed but I was thinking maybe someone that
> knows well the kqemu module would have that know-how... Perhaps you
> could give us more insight on what needs to be done/documented?

A laundry list of what is needed would be good..
Remember that we have had vmware running on FreeBSD so it can be done.

> 
> Pedro.
> 
> 
> __________________________________________________ Do You Yahoo!? 
> Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti
> da tanto spazio gratuito per i tuoi file e i messaggi 
> http://mail.yahoo.it 
> _______________________________________________ 
> freebsd-virtualization@freebsd.org mailing list 
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To
> unsubscribe, send any mail to
> "freebsd-virtualization-unsubscribe@freebsd.org"

From jjuanino at gmail.com  Fri Sep 12 21:19:03 2008
From: jjuanino at gmail.com (Jose Garcia Juanino)
Date: Fri Sep 12 21:19:09 2008
Subject: sqlplus segfaults when receiving INT signal
Message-ID: <20080912205202.GA83925@sanabria>

Hello

I have installed databases/linux-oracle-instantclient-sqlplus port with
emulators/linux_base-f8 linux base port (and
compat.linux.osrelease=2.6.16):

When I hit "CTRL+C" inside sqlplus or send INT signal to sqlplus process, I get a
segfautl:


$ sqlplus /nolog
SQL> select [hit CTRL+C here]
Segmentation fault

In /var/log/messages I get:

Sep 12 22:37:47 ..... kernel: linux_sys_futex: unknown op 129 
Sep 12 22:37:48 ..... kernel: pid 83975 (sqlplus), uid 1002: exited on signal 11 

(the linux_sys_futex message is harmless, as I have read in other
mailing list).

The truss command gives:

linux_rt_sigprocmask(0x0,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
linux_rt_sigprocmask(0x1,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
linux_rt_sigreturn(0xbfbf9c8c,0x2915fff4,0x2,0x292d6420,0x292da6c0,0x6) = 3 (0x3)
read(0,"\n",4096)                                = 1 (0x1)
SIGNAL 11 (SIGSEGV)


Note that this does not happen with emulators/linux_base-fc4  port and
compat.linux.osrelease=2.4.2.

Anybody has suffered this trouble?

Thanks in advanced

(Please Cc: me, as I have not subscribed to the list)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080912/142c4cfa/attachment.pgp
From dchagin at freebsd.org  Sat Sep 13 07:09:29 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sat Sep 13 07:09:35 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080912205202.GA83925@sanabria>
References: <20080912205202.GA83925@sanabria>
Message-ID: <20080913070920.GA1440@dchagin.dialup.corbina.ru>

On Fri, Sep 12, 2008 at 10:52:03PM +0200, Jose Garcia Juanino wrote:
> Hello
> 
> I have installed databases/linux-oracle-instantclient-sqlplus port with
> emulators/linux_base-f8 linux base port (and
> compat.linux.osrelease=2.6.16):
> 
> When I hit "CTRL+C" inside sqlplus or send INT signal to sqlplus process, I get a
> segfautl:
> 
> 
> $ sqlplus /nolog
> SQL> select [hit CTRL+C here]
> Segmentation fault
> 
> In /var/log/messages I get:
> 
> Sep 12 22:37:47 ..... kernel: linux_sys_futex: unknown op 129 
> Sep 12 22:37:48 ..... kernel: pid 83975 (sqlplus), uid 1002: exited on signal 11 
> 
> (the linux_sys_futex message is harmless, as I have read in other
> mailing list).
> 
> The truss command gives:
> 
> linux_rt_sigprocmask(0x0,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> linux_rt_sigprocmask(0x1,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> linux_rt_sigreturn(0xbfbf9c8c,0x2915fff4,0x2,0x292d6420,0x292da6c0,0x6) = 3 (0x3)
> read(0,"\n",4096)                                = 1 (0x1)
> SIGNAL 11 (SIGSEGV)
> 
> 
> Note that this does not happen with emulators/linux_base-fc4  port and
> compat.linux.osrelease=2.4.2.
> 
> Anybody has suffered this trouble?
> 

Please, show uname -vp output

-- 
Have fun!
chd
From jjuanino at gmail.com  Sat Sep 13 08:44:22 2008
From: jjuanino at gmail.com (Jose Garcia Juanino)
Date: Sat Sep 13 08:44:30 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080913070920.GA1440@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
Message-ID: <20080913084412.GA1263@sanabria>

El s?bado 13 de septiembre a las 09:09:20 CEST, Chagin Dmitry escribi?:
> On Fri, Sep 12, 2008 at 10:52:03PM +0200, Jose Garcia Juanino wrote:
> >
> > [ ... ]
> > 
> > The truss command gives:
> > 
> > linux_rt_sigprocmask(0x0,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> > linux_rt_sigprocmask(0x1,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> > linux_rt_sigreturn(0xbfbf9c8c,0x2915fff4,0x2,0x292d6420,0x292da6c0,0x6) = 3 (0x3)
> > read(0,"\n",4096)                                = 1 (0x1)
> > SIGNAL 11 (SIGSEGV)
> > 
> > 
> > Note that this does not happen with emulators/linux_base-fc4  port and
> > compat.linux.osrelease=2.4.2.
> > 
> > Anybody has suffered this trouble?
> > 
> 
> Please, show uname -vp output

Thank you for your response.

The output is:

# uname -vp
FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386

The kernel configuration is here:

http://perso.orange.es/jogaju5001/MK2008Jun06

and the make.conf contains:

MODULES_OVERRIDE=   if_tap if_bridge bridgestp \
		    sound/sound sound/driver/ich \
		    acpi/acpi acpi/acpi_video \
		    linprocfs linux linsysfs \
		    syscons/green \
		    smbfs libiconv libmchain aio \
		    xl ath ath_hal ath_rate_sample wlan wlan_wep wlan_ccmp \
		    wlan_tkip wlan_scan_sta geom



Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080913/ec0a6d5a/attachment.pgp
From dchagin at freebsd.org  Sat Sep 13 08:53:14 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sat Sep 13 08:53:20 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080913084412.GA1263@sanabria>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
Message-ID: <20080913085108.GA2308@dchagin.dialup.corbina.ru>

On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> El s?bado 13 de septiembre a las 09:09:20 CEST, Chagin Dmitry escribi?:
> > On Fri, Sep 12, 2008 at 10:52:03PM +0200, Jose Garcia Juanino wrote:
> > >
> > > [ ... ]
> > > 
> > > The truss command gives:
> > > 
> > > linux_rt_sigprocmask(0x0,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> > > linux_rt_sigprocmask(0x1,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> > > linux_rt_sigreturn(0xbfbf9c8c,0x2915fff4,0x2,0x292d6420,0x292da6c0,0x6) = 3 (0x3)
> > > read(0,"\n",4096)                                = 1 (0x1)
> > > SIGNAL 11 (SIGSEGV)
> > > 
> > > 
> > > Note that this does not happen with emulators/linux_base-fc4  port and
> > > compat.linux.osrelease=2.4.2.
> > > 
> > > Anybody has suffered this trouble?
> > > 
> > 
> > Please, show uname -vp output
> 
> Thank you for your response.
> 
> The output is:
> 
> # uname -vp
> FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> 
> The kernel configuration is here:
> 
> http://perso.orange.es/jogaju5001/MK2008Jun06
> 
> and the make.conf contains:
> 
> MODULES_OVERRIDE=   if_tap if_bridge bridgestp \
> 		    sound/sound sound/driver/ich \
> 		    acpi/acpi acpi/acpi_video \
> 		    linprocfs linux linsysfs \
> 		    syscons/green \
> 		    smbfs libiconv libmchain aio \
> 		    xl ath ath_hal ath_rate_sample wlan wlan_wep wlan_ccmp \
> 		    wlan_tkip wlan_scan_sta geom
> 
> 
> 
> Best regards

thnx, I believe you problem already fixed at 07.09.08,
please cvsup and try yet...


-- 
Have fun!
chd
From kostikbel at gmail.com  Sat Sep 13 13:01:22 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sat Sep 13 13:01:29 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080913085108.GA2308@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
Message-ID: <20080913130111.GQ39652@deviant.kiev.zoral.com.ua>

On Sat, Sep 13, 2008 at 12:51:08PM +0400, Chagin Dmitry wrote:
> On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > El s?bado 13 de septiembre a las 09:09:20 CEST, Chagin Dmitry escribi?:
> > > On Fri, Sep 12, 2008 at 10:52:03PM +0200, Jose Garcia Juanino wrote:
> > > >
> > > > [ ... ]
> > > > 
> > > > The truss command gives:
> > > > 
> > > > linux_rt_sigprocmask(0x0,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> > > > linux_rt_sigprocmask(0x1,0xbfbf9b28,0x0,0x8,0x292d5ff4,0x6) = 0 (0x0)
> > > > linux_rt_sigreturn(0xbfbf9c8c,0x2915fff4,0x2,0x292d6420,0x292da6c0,0x6) = 3 (0x3)
> > > > read(0,"\n",4096)                                = 1 (0x1)
> > > > SIGNAL 11 (SIGSEGV)
> > > > 
> > > > 
> > > > Note that this does not happen with emulators/linux_base-fc4  port and
> > > > compat.linux.osrelease=2.4.2.
> > > > 
> > > > Anybody has suffered this trouble?
> > > > 
> > > 
> > > Please, show uname -vp output
> > 
> > Thank you for your response.
> > 
> > The output is:
> > 
> > # uname -vp
> > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > 
> > The kernel configuration is here:
> > 
> > http://perso.orange.es/jogaju5001/MK2008Jun06
> > 
> > and the make.conf contains:
> > 
> > MODULES_OVERRIDE=   if_tap if_bridge bridgestp \
> > 		    sound/sound sound/driver/ich \
> > 		    acpi/acpi acpi/acpi_video \
> > 		    linprocfs linux linsysfs \
> > 		    syscons/green \
> > 		    smbfs libiconv libmchain aio \
> > 		    xl ath ath_hal ath_rate_sample wlan wlan_wep wlan_ccmp \
> > 		    wlan_tkip wlan_scan_sta geom
> > 
> > 
> > 
> > Best regards
> 
> thnx, I believe you problem already fixed at 07.09.08,
> please cvsup and try yet...
Note that Dmitry suggested to update to latest RELENG_7, not latest
patchlevel of 7.0-RELEASE.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080913/1b2da429/attachment.pgp
From jjuanino at gmail.com  Sat Sep 13 20:55:26 2008
From: jjuanino at gmail.com (Jose Garcia Juanino)
Date: Sat Sep 13 20:55:33 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080913085108.GA2308@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
Message-ID: <20080913205515.GA6158@sanabria>

El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > 
> > Thank you for your response.
> > 
> > The output is:
> > 
> > # uname -vp
> > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > 
> > [ .... ]
> >
> 
> thnx, I believe you problem already fixed at 07.09.08,
> please cvsup and try yet...

I have done that now, but sadly, there is no difference with 7.0:

$ uname -r
7.1-PRERELEASE

$ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

SQL> [hit CTRL+C]
Segmentation fault

Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080913/38a38940/attachment.pgp
From dchagin at freebsd.org  Sun Sep 14 08:20:34 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Sep 14 08:20:42 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080913205515.GA6158@sanabria>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
Message-ID: <20080914082025.GA2792@dchagin.dialup.corbina.ru>

On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> > On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > > 
> > > Thank you for your response.
> > > 
> > > The output is:
> > > 
> > > # uname -vp
> > > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > > 
> > > [ .... ]
> > >
> > 
> > thnx, I believe you problem already fixed at 07.09.08,
> > please cvsup and try yet...
> 
> I have done that now, but sadly, there is no difference with 7.0:
> 
> $ uname -r
> 7.1-PRERELEASE
> 
> $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> 
> SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> 
> Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> 
> SQL> [hit CTRL+C]
> Segmentation fault
> 

thnx! on amd64 I can't repeat this:

dchagin# chroot /compat/linux /bin/bash
bash-3.2#
bash-3.2# uname -a
Linux dchagin.dialup.corbina.ru 2.6.16 FreeBSD 8.0-CURRENT #2: Fri Sep 12 10:36:
07 MSD 2008 i686 i686 i386 GNU/Linux
bash-3.2#
bash-3.2# sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Sun Sep 14 08:10:40 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

SQL> ^C

SQL>

but I see strange behaviour of read() call:

1428 sqlplus  6.276496 CALL  write(0x1,0x28066000,0x5)
1428 sqlplus  6.276514 GIO   fd 1 wrote 5 bytes
     "SQL> "
1428 sqlplus  6.276526 RET   write 5
1428 sqlplus  6.276545 CALL  read(0,0x28067000,0x1000)
1428 sqlplus  21.321774 RET   read -1 errno 1 (EPERM) Operation not permitted
1428 sqlplus  21.321832 PSIG  SIGINT caught handler=0x28c06c2c code=0x0
1428 sqlplus  21.321856 CALL  linux_rt_sigprocmask(SIG_BLOCK,0xffff8de8,0,0x8)
1428 sqlplus  21.321867 RET   linux_rt_sigprocmask 0
1428 sqlplus  21.321877 CALL  linux_rt_sigprocmask(SIG_UNBLOCK,0xffff8de8,0,0x8)
1428 sqlplus  21.321886 RET   linux_rt_sigprocmask 0
1428 sqlplus  21.321896 CALL  linux_rt_sigreturn(0xffff8f4c)
1428 sqlplus  21.321905 RET   linux_rt_sigreturn -1 errno 2 (ENOENT) No such fil
1428 sqlplus  21.321913 CALL  read(0,0x28067000,0x1000)
1428 sqlplus  23.893183 GIO   fd 0 read 1 byte

at least, EPERM is not EINTR :)
I will check up it on i386 later. thnx Jose :)
     
-- 
Have fun!
chd
From rdivacky at freebsd.org  Sun Sep 14 09:08:55 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Sep 14 09:09:02 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080913205515.GA6158@sanabria>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
Message-ID: <20080914090856.GA51307@freebsd.org>

On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> > On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > > 
> > > Thank you for your response.
> > > 
> > > The output is:
> > > 
> > > # uname -vp
> > > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > > 
> > > [ .... ]
> > >
> > 
> > thnx, I believe you problem already fixed at 07.09.08,
> > please cvsup and try yet...
> 
> I have done that now, but sadly, there is no difference with 7.0:
> 
> $ uname -r
> 7.1-PRERELEASE
> 
> $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> 
> SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> 
> Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> 
> SQL> [hit CTRL+C]
> Segmentation fault
> 
> Best regards

please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
in this release so there must be something else
From dchagin at freebsd.org  Sun Sep 14 09:25:28 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Sep 14 09:25:35 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914090856.GA51307@freebsd.org>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914090856.GA51307@freebsd.org>
Message-ID: <20080914092519.GA3121@dchagin.dialup.corbina.ru>

On Sun, Sep 14, 2008 at 11:08:56AM +0200, Roman Divacky wrote:
> On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> > El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> > > On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > > > 
> > > > Thank you for your response.
> > > > 
> > > > The output is:
> > > > 
> > > > # uname -vp
> > > > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > > > 
> > > > [ .... ]
> > > >
> > > 
> > > thnx, I believe you problem already fixed at 07.09.08,
> > > please cvsup and try yet...
> > 
> > I have done that now, but sadly, there is no difference with 7.0:
> > 
> > $ uname -r
> > 7.1-PRERELEASE
> > 
> > $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> > 
> > SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> > 
> > Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> > 
> > SQL> [hit CTRL+C]
> > Segmentation fault
> > 
> > Best regards
> 
> please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
> in this release so there must be something else

  1428 sqlplus  0.874520 CALL  munmap(0x28066000,0xc41d)
  1428 sqlplus  0.874543 RET   munmap 0
  1428 sqlplus  0.874553 CALL  linux_set_tid_address(0x292cf708)
  1428 sqlplus  0.874563 RET   linux_set_tid_address 1428/0x594
  1428 sqlplus  0.874572 CALL  linux_set_robust_list(0x292cf710,0xc)
  1428 sqlplus  0.874580 RET   linux_set_robust_list -1 errno 22 (EINVAL) Invali
d argument
  1428 sqlplus  0.874596 CALL  linux_sys_futex(0xffffdbc4,FUTEX_WAKE|FUTEX_PRIVA
TE_FLAG,0x1,0x292cf6c0,0x29154ff4,0xffffdbd8)
  1428 sqlplus  0.874608 RET   linux_sys_futex 1
  1428 sqlplus  0.874641 CALL  linux_rt_sigaction(SIG 32,0xffffd87c,0,0x8)
  1428 sqlplus  0.874651 RET   linux_rt_sigaction 0


-- 
Have fun!
chd
From jjuanino at gmail.com  Sun Sep 14 11:49:52 2008
From: jjuanino at gmail.com (Jose Garcia Juanino)
Date: Sun Sep 14 11:49:59 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914090856.GA51307@freebsd.org>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914090856.GA51307@freebsd.org>
Message-ID: <20080914114945.GB3411@sanabria>

El domingo 14 de septiembre a las 11:08:56 CEST, Roman Divacky escribi?:
> On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> >
> > [ ... 
> >
> > I have done that now, but sadly, there is no difference with 7.0:
> > 
> > $ uname -r
> > 7.1-PRERELEASE
> > 
> > $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> > 
> > SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> > 
> > Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> > 
> > SQL> [hit CTRL+C]
> > Segmentation fault
> > 
> > Best regards
> 
> please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
> in this release so there must be something else

Thanks for your response

The output is:

# uname -rm
7.1-PRERELEASE i386

# ktrace -d -t+ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Sun Sep 14 11:39:20 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

SQL> ^C [hit enter here]
Segmentation fault

# linux_kdump -t+

The output of linux_kdump is here:

http://perso.orange.es/jogaju5001/ktrace.out

(I have built the kernel with makeoptions     DEBUG=-g, and I have
suppressed INSTALL_NODEBUG="yes" from /etc/make.conf  )

Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080914/e7359609/attachment.pgp
From kostikbel at gmail.com  Sun Sep 14 13:19:19 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep 14 13:19:27 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914082025.GA2792@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914082025.GA2792@dchagin.dialup.corbina.ru>
Message-ID: <20080914131904.GY39652@deviant.kiev.zoral.com.ua>

On Sun, Sep 14, 2008 at 12:20:25PM +0400, Chagin Dmitry wrote:
> On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> > El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> > > On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > > > 
> > > > Thank you for your response.
> > > > 
> > > > The output is:
> > > > 
> > > > # uname -vp
> > > > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > > > 
> > > > [ .... ]
> > > >
> > > 
> > > thnx, I believe you problem already fixed at 07.09.08,
> > > please cvsup and try yet...
> > 
> > I have done that now, but sadly, there is no difference with 7.0:
> > 
> > $ uname -r
> > 7.1-PRERELEASE
> > 
> > $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> > 
> > SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> > 
> > Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> > 
> > SQL> [hit CTRL+C]
> > Segmentation fault
> > 
> 
> thnx! on amd64 I can't repeat this:
> 
> dchagin# chroot /compat/linux /bin/bash
> bash-3.2#
> bash-3.2# uname -a
> Linux dchagin.dialup.corbina.ru 2.6.16 FreeBSD 8.0-CURRENT #2: Fri Sep 12 10:36:
> 07 MSD 2008 i686 i686 i386 GNU/Linux
> bash-3.2#
> bash-3.2# sqlplus /nolog
> 
> SQL*Plus: Release 10.2.0.3.0 - Production on Sun Sep 14 08:10:40 2008
> 
> Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> 
> SQL> ^C
> 
> SQL>

It appears that I did not make MFC of the relevant commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080914/65ef7f0c/attachment.pgp
From dchagin at freebsd.org  Sun Sep 14 15:01:31 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Sep 14 15:01:37 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914131904.GY39652@deviant.kiev.zoral.com.ua>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914082025.GA2792@dchagin.dialup.corbina.ru>
	<20080914131904.GY39652@deviant.kiev.zoral.com.ua>
Message-ID: <20080914150050.GA4644@dchagin.dialup.corbina.ru>

On Sun, Sep 14, 2008 at 04:19:04PM +0300, Kostik Belousov wrote:
> On Sun, Sep 14, 2008 at 12:20:25PM +0400, Chagin Dmitry wrote:
> > On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> > > El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> > > > On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > > > > 
> > > > > Thank you for your response.
> > > > > 
> > > > > The output is:
> > > > > 
> > > > > # uname -vp
> > > > > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > > > > 
> > > > > [ .... ]
> > > > >
> > > > 
> > > > thnx, I believe you problem already fixed at 07.09.08,
> > > > please cvsup and try yet...
> > > 
> > > I have done that now, but sadly, there is no difference with 7.0:
> > > 
> > > $ uname -r
> > > 7.1-PRERELEASE
> > > 
> > > $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> > > 
> > > SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> > > 
> > > Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> > > 
> > > SQL> [hit CTRL+C]
> > > Segmentation fault
> > > 
> > 
> > thnx! on amd64 I can't repeat this:
> > 
> > dchagin# chroot /compat/linux /bin/bash
> > bash-3.2#
> > bash-3.2# uname -a
> > Linux dchagin.dialup.corbina.ru 2.6.16 FreeBSD 8.0-CURRENT #2: Fri Sep 12 10:36:
> > 07 MSD 2008 i686 i686 i386 GNU/Linux
> > bash-3.2#
> > bash-3.2# sqlplus /nolog
> > 
> > SQL*Plus: Release 10.2.0.3.0 - Production on Sun Sep 14 08:10:40 2008
> > 
> > Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> > 
> > SQL> ^C
> > 
> > SQL>
> 
> It appears that I did not make MFC of the relevant commit.

ah, I'm sorry... I have thought that week has passed
and has not checked up it ((

-- 
Have fun!
chd
From jjuanino at gmail.com  Sun Sep 14 15:17:57 2008
From: jjuanino at gmail.com (Jose Garcia Juanino)
Date: Sun Sep 14 15:18:04 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914150050.GA4644@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914082025.GA2792@dchagin.dialup.corbina.ru>
	<20080914131904.GY39652@deviant.kiev.zoral.com.ua>
	<20080914150050.GA4644@dchagin.dialup.corbina.ru>
Message-ID: <20080914151748.GA5370@sanabria>

El domingo 14 de septiembre a las 17:00:50 CEST, Chagin Dmitry escribi?:
> On Sun, Sep 14, 2008 at 04:19:04PM +0300, Kostik Belousov wrote:
> > 
> > It appears that I did not make MFC of the relevant commit.
> 
> ah, I'm sorry... I have thought that week has passed
> and has not checked up it ((

Therefore, this issue holds for RELENG_7, but not for CURRENT. Is
there any prevision to make the MFC, despite of freeze of RELENG_7
branch? Or it is needed wait until 7.2-RELEASE?

Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080914/58d83ff9/attachment.pgp
From ed at 80386.nl  Sun Sep 14 15:49:31 2008
From: ed at 80386.nl (Ed Schouten)
Date: Sun Sep 14 15:49:37 2008
Subject: [Patch] Compiling COMPAT_SVR4 without COMPAT_43
Message-ID: <20080914153840.GO1191@hoeg.nl>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080914/3097b024/attachment.pgp
From kostikbel at gmail.com  Sun Sep 14 16:38:47 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep 14 16:38:54 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914151748.GA5370@sanabria>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914082025.GA2792@dchagin.dialup.corbina.ru>
	<20080914131904.GY39652@deviant.kiev.zoral.com.ua>
	<20080914150050.GA4644@dchagin.dialup.corbina.ru>
	<20080914151748.GA5370@sanabria>
Message-ID: <20080914163841.GB39652@deviant.kiev.zoral.com.ua>

On Sun, Sep 14, 2008 at 05:17:49PM +0200, Jose Garcia Juanino wrote:
> El domingo 14 de septiembre a las 17:00:50 CEST, Chagin Dmitry escribi?:
> > On Sun, Sep 14, 2008 at 04:19:04PM +0300, Kostik Belousov wrote:
> > > 
> > > It appears that I did not make MFC of the relevant commit.
> > 
> > ah, I'm sorry... I have thought that week has passed
> > and has not checked up it ((
> 
> Therefore, this issue holds for RELENG_7, but not for CURRENT. Is
> there any prevision to make the MFC, despite of freeze of RELENG_7
> branch? Or it is needed wait until 7.2-RELEASE?

I asked re@ for MFC permit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080914/3e5d46d5/attachment.pgp
From rdivacky at freebsd.org  Sun Sep 14 18:48:21 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Sep 14 18:48:27 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914163841.GB39652@deviant.kiev.zoral.com.ua>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914082025.GA2792@dchagin.dialup.corbina.ru>
	<20080914131904.GY39652@deviant.kiev.zoral.com.ua>
	<20080914150050.GA4644@dchagin.dialup.corbina.ru>
	<20080914151748.GA5370@sanabria>
	<20080914163841.GB39652@deviant.kiev.zoral.com.ua>
Message-ID: <20080914184817.GA86425@freebsd.org>

On Sun, Sep 14, 2008 at 07:38:41PM +0300, Kostik Belousov wrote:
> On Sun, Sep 14, 2008 at 05:17:49PM +0200, Jose Garcia Juanino wrote:
> > El domingo 14 de septiembre a las 17:00:50 CEST, Chagin Dmitry escribi?:
> > > On Sun, Sep 14, 2008 at 04:19:04PM +0300, Kostik Belousov wrote:
> > > > 
> > > > It appears that I did not make MFC of the relevant commit.
> > > 
> > > ah, I'm sorry... I have thought that week has passed
> > > and has not checked up it ((
> > 
> > Therefore, this issue holds for RELENG_7, but not for CURRENT. Is
> > there any prevision to make the MFC, despite of freeze of RELENG_7
> > branch? Or it is needed wait until 7.2-RELEASE?
> 
> I asked re@ for MFC permit.

heh... doesnt it feel a little schizophrenic to ask yourself for
the permit? :)
From rdivacky at freebsd.org  Sun Sep 14 18:49:26 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Sep 14 18:49:32 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914092519.GA3121@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914090856.GA51307@freebsd.org>
	<20080914092519.GA3121@dchagin.dialup.corbina.ru>
Message-ID: <20080914184933.GB86425@freebsd.org>

On Sun, Sep 14, 2008 at 01:25:19PM +0400, Chagin Dmitry wrote:
> On Sun, Sep 14, 2008 at 11:08:56AM +0200, Roman Divacky wrote:
> > On Sat, Sep 13, 2008 at 10:55:17PM +0200, Jose Garcia Juanino wrote:
> > > El s?bado 13 de septiembre a las 10:51:08 CEST, Chagin Dmitry escribi?:
> > > > On Sat, Sep 13, 2008 at 10:44:13AM +0200, Jose Garcia Juanino wrote:
> > > > > 
> > > > > Thank you for your response.
> > > > > 
> > > > > The output is:
> > > > > 
> > > > > # uname -vp
> > > > > FreeBSD 7.0-RELEASE-p4 #3: Thu Sep  4 08:54:56 CEST 2008 root@<snipped>:/usr/obj/src/sys/MK2008Jun06 i386
> > > > > 
> > > > > [ .... ]
> > > > >
> > > > 
> > > > thnx, I believe you problem already fixed at 07.09.08,
> > > > please cvsup and try yet...
> > > 
> > > I have done that now, but sadly, there is no difference with 7.0:
> > > 
> > > $ uname -r
> > > 7.1-PRERELEASE
> > > 
> > > $ /compat/linux/usr/lib/oracle/10.2.0.3/client/bin/sqlplus /nolog
> > > 
> > > SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 13 20:47:47 2008
> > > 
> > > Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
> > > 
> > > SQL> [hit CTRL+C]
> > > Segmentation fault
> > > 
> > > Best regards
> > 
> > please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
> > in this release so there must be something else
> 
>   1428 sqlplus  0.874520 CALL  munmap(0x28066000,0xc41d)
>   1428 sqlplus  0.874543 RET   munmap 0
>   1428 sqlplus  0.874553 CALL  linux_set_tid_address(0x292cf708)
>   1428 sqlplus  0.874563 RET   linux_set_tid_address 1428/0x594
>   1428 sqlplus  0.874572 CALL  linux_set_robust_list(0x292cf710,0xc)
>   1428 sqlplus  0.874580 RET   linux_set_robust_list -1 errno 22 (EINVAL) Invali
> d argument
>   1428 sqlplus  0.874596 CALL  linux_sys_futex(0xffffdbc4,FUTEX_WAKE|FUTEX_PRIVA
> TE_FLAG,0x1,0x292cf6c0,0x29154ff4,0xffffdbd8)
>   1428 sqlplus  0.874608 RET   linux_sys_futex 1
>   1428 sqlplus  0.874641 CALL  linux_rt_sigaction(SIG 32,0xffffd87c,0,0x8)
>   1428 sqlplus  0.874651 RET   linux_rt_sigaction 0

the robust futexes are also implemented in -CURRENT but I dont feel like
MFcing them.... the error is also harmless

do you want me guys to MFC the robust futexes?
From rdivacky at freebsd.org  Sun Sep 14 18:51:37 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Sep 14 18:51:44 2008
Subject: [Patch] Compiling COMPAT_SVR4 without COMPAT_43
In-Reply-To: <20080914153840.GO1191@hoeg.nl>
References: <20080914153840.GO1191@hoeg.nl>
Message-ID: <20080914185144.GC86425@freebsd.org>

On Sun, Sep 14, 2008 at 05:38:40PM +0200, Ed Schouten wrote:
> Hello everyone,
> 
> I just build this patch on my system at home. Fortunately I'm not a user
> of COMPAT_SVR4, but I thought some of its users may actually find it
> useful.
> 
> The attached patch should allow COMPAT_SVR4 users to use it without
> having COMPAT_43 in their kernel configuration. Any comments? I'll
> commit it when (if) I've received any feedback. Thanks!

looks good to me. I believe you might want to ask jhb@ as he seems
to know of some users of SVR4 (at yahoo! ?)...

just out of curiousity... why did you do this?

thnx!

roman
From ed at 80386.nl  Sun Sep 14 19:00:32 2008
From: ed at 80386.nl (Ed Schouten)
Date: Sun Sep 14 19:00:39 2008
Subject: [Patch] Compiling COMPAT_SVR4 without COMPAT_43
In-Reply-To: <20080914185144.GC86425@freebsd.org>
References: <20080914153840.GO1191@hoeg.nl>
	<20080914185144.GC86425@freebsd.org>
Message-ID: <20080914190031.GA81522@hoeg.nl>

* Roman Divacky <rdivacky@freebsd.org> wrote:
> On Sun, Sep 14, 2008 at 05:38:40PM +0200, Ed Schouten wrote:
> > Hello everyone,
> > 
> > I just build this patch on my system at home. Fortunately I'm not a user
> > of COMPAT_SVR4, but I thought some of its users may actually find it
> > useful.
> > 
> > The attached patch should allow COMPAT_SVR4 users to use it without
> > having COMPAT_43 in their kernel configuration. Any comments? I'll
> > commit it when (if) I've received any feedback. Thanks!
> 
> looks good to me. I believe you might want to ask jhb@ as he seems
> to know of some users of SVR4 (at yahoo! ?)...
> 
> just out of curiousity... why did you do this?

I was running a random grep on our source tree on COMPAT_43 and I
noticed svr4 had this #error in it, so I thought: I wonder what would
happen if I'd remove the #error. It turns out only two socket functions
used actual COMPAT_43 bits, so that's why I wrote the patch.

Thanks for pointing me to jhb. I'll contact him.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080914/b6a6a014/attachment.pgp
From bugmaster at FreeBSD.org  Mon Sep 15 15:18:46 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep 15 15:19:31 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200809151518.m8FFIkKx018845@freefall.freebsd.org>

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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
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/29698   emulation  [linux] [patch] linux ipcs doesn'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

12 problems total.

From dchagin at freebsd.org  Mon Sep 15 15:48:25 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Mon Sep 15 15:48:32 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080914184933.GB86425@freebsd.org>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914090856.GA51307@freebsd.org>
	<20080914092519.GA3121@dchagin.dialup.corbina.ru>
	<20080914184933.GB86425@freebsd.org>
Message-ID: <20080915154811.GA3696@dchagin.dialup.corbina.ru>

On Sun, Sep 14, 2008 at 08:49:33PM +0200, Roman Divacky wrote:
> On Sun, Sep 14, 2008 at 01:25:19PM +0400, Chagin Dmitry wrote:
> > > 
> > > please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
> > > in this release so there must be something else
> > 
> >   1428 sqlplus  0.874520 CALL  munmap(0x28066000,0xc41d)
> >   1428 sqlplus  0.874543 RET   munmap 0
> >   1428 sqlplus  0.874553 CALL  linux_set_tid_address(0x292cf708)
> >   1428 sqlplus  0.874563 RET   linux_set_tid_address 1428/0x594
> >   1428 sqlplus  0.874572 CALL  linux_set_robust_list(0x292cf710,0xc)
> >   1428 sqlplus  0.874580 RET   linux_set_robust_list -1 errno 22 (EINVAL) Invali
> > d argument
> >   1428 sqlplus  0.874596 CALL  linux_sys_futex(0xffffdbc4,FUTEX_WAKE|FUTEX_PRIVA
> > TE_FLAG,0x1,0x292cf6c0,0x29154ff4,0xffffdbd8)
> >   1428 sqlplus  0.874608 RET   linux_sys_futex 1
> >   1428 sqlplus  0.874641 CALL  linux_rt_sigaction(SIG 32,0xffffd87c,0,0x8)
> >   1428 sqlplus  0.874651 RET   linux_rt_sigaction 0
> 
> the robust futexes are also implemented in -CURRENT but I dont feel like
> MFcing them.... the error is also harmless

it amd64, so, set_robust_list() here does not work. look at a patch bellow,
I show it for example only because I don't understand how futexes work :)


diff --git a/src/sys/compat/linux/linux_futex.c b/src/sys/compat/linux/linux_futex.c
index 6588d23..73cf3a7 100644
--- a/src/sys/compat/linux/linux_futex.c
+++ b/src/sys/compat/linux/linux_futex.c
@@ -551,7 +551,7 @@ linux_set_robust_list(struct thread *td, struct linux_set_robust_list_args *args
 		return (EINVAL);
 
 	em = em_find(td->td_proc, EMUL_DOLOCK);
-	em->robust_futexes = args->head;
+	em->robust_futexes = PTRIN(args->head);
 	EMUL_UNLOCK(&emul_lock);
 
 	return (0);	
@@ -661,17 +661,17 @@ release_futexes(struct proc *p)
 	if (head == NULL)
 		return;
 
-	if (fetch_robust_entry(&entry, &head->list.next, &pi))
+	if (fetch_robust_entry(&entry, PTRIN(&head->list.next), &pi))
 		return;
 
 	if (copyin(&head->futex_offset, &futex_offset, sizeof(l_ulong)))
 		return;
 
-	if (fetch_robust_entry(&pending, &head->pending_list, &pip))
+	if (fetch_robust_entry(&pending, PTRIN(&head->pending_list), &pip))
 		return;
 
 	while (entry != &head->list) {
-		rc = fetch_robust_entry(&next_entry, &entry->next, &next_pi);
+		rc = fetch_robust_entry(&next_entry, PTRIN(&entry->next), &next_pi);
 
 		if (entry != pending)
 			if (handle_futex_death((char *)entry + futex_offset,
diff --git a/src/sys/compat/linux/linux_futex.h b/src/sys/compat/linux/linux_futex.h
index f6a2d4b..67b5115 100644
--- a/src/sys/compat/linux/linux_futex.h
+++ b/src/sys/compat/linux/linux_futex.h
@@ -66,14 +66,22 @@
 /* This is defined by Linux user-space */
 
 struct linux_robust_list {
-	struct linux_robust_list	*next;
-};
+	l_uintptr_t	next;
+}
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+__packed
+#endif
+;
 
 struct linux_robust_list_head {
 	struct linux_robust_list	list;
 	l_ulong				futex_offset;
-	struct linux_robust_list	*pending_list;
-};
+	l_uintptr_t			pending_list;
+}
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+__packed
+#endif
+;
 
 #define	FUTEX_WAITERS		0x80000000
 #define	FUTEX_OWNER_DIED	0x40000000

thnx!

-- 
Have fun!
chd
From rdivacky at freebsd.org  Mon Sep 15 20:44:05 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Mon Sep 15 20:44:13 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080915154811.GA3696@dchagin.dialup.corbina.ru>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914090856.GA51307@freebsd.org>
	<20080914092519.GA3121@dchagin.dialup.corbina.ru>
	<20080914184933.GB86425@freebsd.org>
	<20080915154811.GA3696@dchagin.dialup.corbina.ru>
Message-ID: <20080915204400.GA92022@freebsd.org>

On Mon, Sep 15, 2008 at 07:48:11PM +0400, Chagin Dmitry wrote:
> On Sun, Sep 14, 2008 at 08:49:33PM +0200, Roman Divacky wrote:
> > On Sun, Sep 14, 2008 at 01:25:19PM +0400, Chagin Dmitry wrote:
> > > > 
> > > > please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
> > > > in this release so there must be something else
> > > 
> > >   1428 sqlplus  0.874520 CALL  munmap(0x28066000,0xc41d)
> > >   1428 sqlplus  0.874543 RET   munmap 0
> > >   1428 sqlplus  0.874553 CALL  linux_set_tid_address(0x292cf708)
> > >   1428 sqlplus  0.874563 RET   linux_set_tid_address 1428/0x594
> > >   1428 sqlplus  0.874572 CALL  linux_set_robust_list(0x292cf710,0xc)
> > >   1428 sqlplus  0.874580 RET   linux_set_robust_list -1 errno 22 (EINVAL) Invali
> > > d argument
> > >   1428 sqlplus  0.874596 CALL  linux_sys_futex(0xffffdbc4,FUTEX_WAKE|FUTEX_PRIVA
> > > TE_FLAG,0x1,0x292cf6c0,0x29154ff4,0xffffdbd8)
> > >   1428 sqlplus  0.874608 RET   linux_sys_futex 1
> > >   1428 sqlplus  0.874641 CALL  linux_rt_sigaction(SIG 32,0xffffd87c,0,0x8)
> > >   1428 sqlplus  0.874651 RET   linux_rt_sigaction 0
> > 
> > the robust futexes are also implemented in -CURRENT but I dont feel like
> > MFcing them.... the error is also harmless
> 
> it amd64, so, set_robust_list() here does not work. look at a patch bellow,
> I show it for example only because I don't understand how futexes work :)
> 
> 
> diff --git a/src/sys/compat/linux/linux_futex.c b/src/sys/compat/linux/linux_futex.c
> index 6588d23..73cf3a7 100644
> --- a/src/sys/compat/linux/linux_futex.c
> +++ b/src/sys/compat/linux/linux_futex.c
> @@ -551,7 +551,7 @@ linux_set_robust_list(struct thread *td, struct linux_set_robust_list_args *args
>  		return (EINVAL);
>  
>  	em = em_find(td->td_proc, EMUL_DOLOCK);
> -	em->robust_futexes = args->head;
> +	em->robust_futexes = PTRIN(args->head);
>  	EMUL_UNLOCK(&emul_lock);
>  
>  	return (0);	
> @@ -661,17 +661,17 @@ release_futexes(struct proc *p)
>  	if (head == NULL)
>  		return;
>  
> -	if (fetch_robust_entry(&entry, &head->list.next, &pi))
> +	if (fetch_robust_entry(&entry, PTRIN(&head->list.next), &pi))
>  		return;
>  
>  	if (copyin(&head->futex_offset, &futex_offset, sizeof(l_ulong)))
>  		return;
>  
> -	if (fetch_robust_entry(&pending, &head->pending_list, &pip))
> +	if (fetch_robust_entry(&pending, PTRIN(&head->pending_list), &pip))
>  		return;
>  
>  	while (entry != &head->list) {
> -		rc = fetch_robust_entry(&next_entry, &entry->next, &next_pi);
> +		rc = fetch_robust_entry(&next_entry, PTRIN(&entry->next), &next_pi);
>  
>  		if (entry != pending)
>  			if (handle_futex_death((char *)entry + futex_offset,
> diff --git a/src/sys/compat/linux/linux_futex.h b/src/sys/compat/linux/linux_futex.h
> index f6a2d4b..67b5115 100644
> --- a/src/sys/compat/linux/linux_futex.h
> +++ b/src/sys/compat/linux/linux_futex.h
> @@ -66,14 +66,22 @@
>  /* This is defined by Linux user-space */
>  
>  struct linux_robust_list {
> -	struct linux_robust_list	*next;
> -};
> +	l_uintptr_t	next;
> +}
> +#if defined(__amd64__) && defined(COMPAT_LINUX32)
> +__packed
> +#endif
> +;
>  
>  struct linux_robust_list_head {
>  	struct linux_robust_list	list;
>  	l_ulong				futex_offset;
> -	struct linux_robust_list	*pending_list;
> -};
> +	l_uintptr_t			pending_list;
> +}
> +#if defined(__amd64__) && defined(COMPAT_LINUX32)
> +__packed
> +#endif
> +;
>  
>  #define	FUTEX_WAITERS		0x80000000
>  #define	FUTEX_OWNER_DIED	0x40000000

this looks about right... I'll ask kostik to commit this,

dmitry, you should have commit bit :)
From dchagin at freebsd.org  Wed Sep 17 05:17:01 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Wed Sep 17 05:17:08 2008
Subject: sqlplus segfaults when receiving INT signal
In-Reply-To: <20080915204400.GA92022@freebsd.org>
References: <20080912205202.GA83925@sanabria>
	<20080913070920.GA1440@dchagin.dialup.corbina.ru>
	<20080913084412.GA1263@sanabria>
	<20080913085108.GA2308@dchagin.dialup.corbina.ru>
	<20080913205515.GA6158@sanabria>
	<20080914090856.GA51307@freebsd.org>
	<20080914092519.GA3121@dchagin.dialup.corbina.ru>
	<20080914184933.GB86425@freebsd.org>
	<20080915154811.GA3696@dchagin.dialup.corbina.ru>
	<20080915204400.GA92022@freebsd.org>
Message-ID: <20080917051651.GA2390@dchagin.dialup.corbina.ru>

On Mon, Sep 15, 2008 at 10:44:00PM +0200, Roman Divacky wrote:
> On Mon, Sep 15, 2008 at 07:48:11PM +0400, Chagin Dmitry wrote:
> > On Sun, Sep 14, 2008 at 08:49:33PM +0200, Roman Divacky wrote:
> > > On Sun, Sep 14, 2008 at 01:25:19PM +0400, Chagin Dmitry wrote:
> > > > > 
> > > > > please provide ktrace/linux_kdump... the "unknown futex operation" problem is fixed
> > > > > in this release so there must be something else
> > > > 
> > > >   1428 sqlplus  0.874520 CALL  munmap(0x28066000,0xc41d)
> > > >   1428 sqlplus  0.874543 RET   munmap 0
> > > >   1428 sqlplus  0.874553 CALL  linux_set_tid_address(0x292cf708)
> > > >   1428 sqlplus  0.874563 RET   linux_set_tid_address 1428/0x594
> > > >   1428 sqlplus  0.874572 CALL  linux_set_robust_list(0x292cf710,0xc)
> > > >   1428 sqlplus  0.874580 RET   linux_set_robust_list -1 errno 22 (EINVAL) Invali
> > > > d argument
> > > >   1428 sqlplus  0.874596 CALL  linux_sys_futex(0xffffdbc4,FUTEX_WAKE|FUTEX_PRIVA
> > > > TE_FLAG,0x1,0x292cf6c0,0x29154ff4,0xffffdbd8)
> > > >   1428 sqlplus  0.874608 RET   linux_sys_futex 1
> > > >   1428 sqlplus  0.874641 CALL  linux_rt_sigaction(SIG 32,0xffffd87c,0,0x8)
> > > >   1428 sqlplus  0.874651 RET   linux_rt_sigaction 0
> > > 
> > > the robust futexes are also implemented in -CURRENT but I dont feel like
> > > MFcing them.... the error is also harmless
> > 
> > it amd64, so, set_robust_list() here does not work. look at a patch bellow,
> > I show it for example only because I don't understand how futexes work :)
> > 
> > 
> > diff --git a/src/sys/compat/linux/linux_futex.c b/src/sys/compat/linux/linux_futex.c
> > index 6588d23..73cf3a7 100644
> > --- a/src/sys/compat/linux/linux_futex.c
> > +++ b/src/sys/compat/linux/linux_futex.c
> > @@ -551,7 +551,7 @@ linux_set_robust_list(struct thread *td, struct linux_set_robust_list_args *args
> >  		return (EINVAL);
> >  
> >  	em = em_find(td->td_proc, EMUL_DOLOCK);
> > -	em->robust_futexes = args->head;
> > +	em->robust_futexes = PTRIN(args->head);
> >  	EMUL_UNLOCK(&emul_lock);
> >  
> >  	return (0);	
> > @@ -661,17 +661,17 @@ release_futexes(struct proc *p)
> >  	if (head == NULL)
> >  		return;
> >  
> > -	if (fetch_robust_entry(&entry, &head->list.next, &pi))
> > +	if (fetch_robust_entry(&entry, PTRIN(&head->list.next), &pi))
> >  		return;
> >  
> >  	if (copyin(&head->futex_offset, &futex_offset, sizeof(l_ulong)))
> >  		return;
> >  
> > -	if (fetch_robust_entry(&pending, &head->pending_list, &pip))
> > +	if (fetch_robust_entry(&pending, PTRIN(&head->pending_list), &pip))
> >  		return;
> >  
> >  	while (entry != &head->list) {
> > -		rc = fetch_robust_entry(&next_entry, &entry->next, &next_pi);
> > +		rc = fetch_robust_entry(&next_entry, PTRIN(&entry->next), &next_pi);
> >  
> >  		if (entry != pending)
> >  			if (handle_futex_death((char *)entry + futex_offset,
> > diff --git a/src/sys/compat/linux/linux_futex.h b/src/sys/compat/linux/linux_futex.h
> > index f6a2d4b..67b5115 100644
> > --- a/src/sys/compat/linux/linux_futex.h
> > +++ b/src/sys/compat/linux/linux_futex.h
> > @@ -66,14 +66,22 @@
> >  /* This is defined by Linux user-space */
> >  
> >  struct linux_robust_list {
> > -	struct linux_robust_list	*next;
> > -};
> > +	l_uintptr_t	next;
> > +}
> > +#if defined(__amd64__) && defined(COMPAT_LINUX32)
> > +__packed
> > +#endif
> > +;
> >  
> >  struct linux_robust_list_head {
> >  	struct linux_robust_list	list;
> >  	l_ulong				futex_offset;
> > -	struct linux_robust_list	*pending_list;
> > -};
> > +	l_uintptr_t			pending_list;
> > +}
> > +#if defined(__amd64__) && defined(COMPAT_LINUX32)
> > +__packed
> > +#endif
> > +;
> >  
> >  #define	FUTEX_WAITERS		0x80000000
> >  #define	FUTEX_OWNER_DIED	0x40000000
> 
> this looks about right... I'll ask kostik to commit this,
> 

I think that better if to move definitions of structures to linux.h

> dmitry, you should have commit bit :)

i'm ready :)
thnx!
-- 
Have fun!
chd
From dchagin at freebsd.org  Wed Sep 17 18:38:15 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Wed Sep 17 18:38:22 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080902085623.GA12395@freebsd.org>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
Message-ID: <20080917183801.GA2714@dchagin.dialup.corbina.ru>

On Tue, Sep 02, 2008 at 10:56:23AM +0200, Roman Divacky wrote:
> On Sun, Aug 31, 2008 at 03:06:10PM +0400, Chagin Dmitry wrote:
> > On Fri, Aug 22, 2008 at 01:29:46PM +0200, Roman Divacky wrote:
> > > On Fri, Aug 22, 2008 at 01:29:27PM +0200, Ed Schouten wrote:
> > > > Hello Emulation folks,
> > > > 
> > > > I just wanted to send you all a message to say one of the things I tried
> > > > to improve in the MPSAFE TTY branch was support for PTY's for Linux
> > > > binaries.
> > > > 
> > > > At home I've got a FreeBSD Jail running Debian Etch. Unfortunately,
> > > > Linux sendmsg() is a little broken on FreeBSD/amd64, but so far I've
> > > > been able to at least get OpenSSH (as root) and GNU Screen working.
> > > 
> > > I believe dmitry has a patch for this..
> > 
> > the patch is bellow, I tested a patch only on LTP tests (with little changes),
> > it's necessary to test on real apps, it will be good if Ed will test..
> 
> this should be reviewed by someone with a knowledge of how networking works in 
> FreeBSD. Any volunteer? Dmitry, can you send a mail to net@ describing the changes
> in the patch and ask for a review there?
> 

Hi,

So, a patch bellow. The patch corrects sendmsg() recvmsg() in our linuxulator,
also adds SO_PASSCRED option to linuxulator setsockopt() getsockopt()
it's necessary for implementing Linux analogue of FreeBSD SCM_CREDS control
message. I have tested it on i386 && ia32@amd64 linuxulators,
it works for me now.

Please review, any comment will be helpful.
thnx!

diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h
index 8940289..9439900 100644
--- a/src/sys/amd64/linux32/linux.h
+++ b/src/sys/amd64/linux32/linux.h
@@ -685,6 +685,7 @@ union l_semun {
 #define	LINUX_SO_NO_CHECK	11
 #define	LINUX_SO_PRIORITY	12
 #define	LINUX_SO_LINGER		13
+#define	LINUX_SO_PASSCRED	16
 #define	LINUX_SO_PEERCRED	17
 #define	LINUX_SO_RCVLOWAT	18
 #define	LINUX_SO_SNDLOWAT	19
@@ -709,6 +710,28 @@ struct l_sockaddr {
 	char		sa_data[14];
 } __packed;
 
+struct l_msghdr {
+	l_uintptr_t	msg_name;
+	l_int		msg_namelen;
+	l_uintptr_t	msg_iov;
+	l_size_t	msg_iovlen;
+	l_uintptr_t	msg_control;
+	l_size_t	msg_controllen;
+	l_uint		msg_flags;
+} __packed;
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+} __packed;
+
+struct l_ucred {
+	uint32_t	pid;
+	uint32_t	uid;
+	uint32_t	gid;
+} __packed;
+
 struct l_ifmap {
 	l_ulong		mem_start;
 	l_ulong		mem_end;
diff --git a/src/sys/amd64/linux32/linux32_machdep.c b/src/sys/amd64/linux32/linux32_machdep.c
index 32cbe0b..26459c9 100644
--- a/src/sys/amd64/linux32/linux32_machdep.c
+++ b/src/sys/amd64/linux32/linux32_machdep.c
@@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v 1.49 2008/09/08 09
 #include <vm/vm_map.h>
 
 #include <amd64/linux32/linux.h>
+#include <amd64/linux32/linux32_io.h>
 #include <amd64/linux32/linux32_proto.h>
 #include <compat/linux/linux_ipc.h>
 #include <compat/linux/linux_signal.h>
@@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args *args)
 	return (error);
 }
 
-struct iovec32 {
-	u_int32_t iov_base;
-	int	iov_len;
-};
-
-CTASSERT(sizeof(struct iovec32) == 8);
-
 static int
 linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop)
 {
@@ -281,6 +275,34 @@ linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop)
 }
 
 int
+linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp,
+    int error)
+{
+	struct iovec32 iov32;
+	struct iovec *iov;
+	u_int iovlen;
+	int i;
+
+	*iovp = NULL;
+	if (iovcnt > UIO_MAXIOV)
+		return (error);
+	iovlen = iovcnt * sizeof(struct iovec);
+	iov = malloc(iovlen, M_IOV, M_WAITOK);
+	for (i = 0; i < iovcnt; i++) {
+		error = copyin(&iovp32[i], &iov32, sizeof(struct iovec32));
+		if (error) {
+			free(iov, M_IOV);
+			return (error);
+		}
+		iov[i].iov_base = PTRIN(iov32.iov_base);
+		iov[i].iov_len = iov32.iov_len;
+	}
+	*iovp = iov;
+	return(0);
+
+}
+
+int
 linux_readv(struct thread *td, struct linux_readv_args *uap)
 {
 	struct uio *auio;
diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c
index f97aa23..34e25dc 100644
--- a/src/sys/compat/linux/linux_socket.c
+++ b/src/sys/compat/linux/linux_socket.c
@@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: src/sys/compat/linux/linux_socket.c,v 1.76 2008/09/09 13:01:
 
 #ifdef COMPAT_LINUX32
 #include <machine/../linux32/linux.h>
+#include <machine/../linux32/linux32_io.h>
 #include <machine/../linux32/linux32_proto.h>
 #else
 #include <machine/../linux/linux.h>
@@ -294,6 +295,8 @@ linux_to_bsd_so_sockopt(int opt)
 		return (SO_OOBINLINE);
 	case LINUX_SO_LINGER:
 		return (SO_LINGER);
+	case LINUX_SO_PASSCRED:
+		return (LOCAL_CREDS);
 	case LINUX_SO_PEERCRED:
 		return (LOCAL_PEERCRED);
 	case LINUX_SO_RCVLOWAT:
@@ -421,6 +424,63 @@ linux_sa_put(struct osockaddr *osa)
 }
 
 static int
+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 (cmsg_type);
+}
+
+static int
+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 (cmsg_type);
+}
+
+
+
+static int
+linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr)
+{
+	if (lhdr->msg_controllen > INT_MAX)
+		return (ENOBUFS);
+
+	bhdr->msg_name		= PTRIN(lhdr->msg_name);
+	bhdr->msg_namelen	= lhdr->msg_namelen;
+	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;
+	bhdr->msg_flags		= linux_to_bsd_msg_flags(lhdr->msg_flags);
+	return (0);
+}
+
+static int
+bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr)
+{
+	lhdr->msg_name		= PTROUT(bhdr->msg_name);
+	lhdr->msg_namelen	= bhdr->msg_namelen;
+	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_flags skipped */
+	return (0);
+}
+
+static int
 linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
     enum uio_seg segflg)
 {
@@ -437,25 +497,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
 		to = NULL;
 
 	if (mp->msg_control != NULL) {
+		struct l_cmsghdr *ptr_cmsg;
+		struct l_cmsghdr linux_cmsg;
 		struct cmsghdr *cmsg;
-
-		if (mp->msg_controllen < sizeof(struct cmsghdr)) {
-			error = EINVAL;
-			goto bad;
-		}
-		error = sockargs(&control, mp->msg_control,
-		    mp->msg_controllen, MT_CONTROL);
-		if (error)
-			goto bad;
-
-		cmsg = mtod(control, struct cmsghdr *);
-		cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level);
+		void *data;
+		socklen_t datalen;
+
+		cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO);
+		control = m_get(M_WAIT, MT_CONTROL);
+		ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp);
+
+		do {
+			error = copyin(ptr_cmsg, &linux_cmsg,
+			    sizeof(struct l_cmsghdr));
+			if (error)
+				goto bad;
+			if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) ||
+			    linux_cmsg.cmsg_len > INT_MAX) {
+				error = EINVAL;
+				goto bad;
+			}
+
+			switch (linux_cmsg.cmsg_type) {
+			case LINUX_SCM_RIGHTS:
+				cmsg->cmsg_type =
+				    linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type);
+				break;
+			default:
+				error = EINVAL;
+				goto bad;
+			}
+			cmsg->cmsg_level =
+			    linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level);
+
+			datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ;
+			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(mp, ptr_cmsg)));
+
+		free(cmsg, M_TEMP);
 	} else
 		control = NULL;
 
 	error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control,
 	    segflg);
-
 bad:
 	if (to)
 		FREE(to, M_SONAME);
@@ -960,12 +1052,14 @@ static int
 linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 {
 	struct msghdr msg;
+	struct l_msghdr linux_msg;
 	struct iovec *iov;
 	int error;
 
-	/* XXXTJR sendmsg is broken on amd64 */
-
-	error = copyin(PTRIN(args->msg), &msg, sizeof(msg));
+	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);
 
@@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 	 */
 	if (msg.msg_control != NULL && msg.msg_controllen == 0)
 		msg.msg_control = NULL;
+
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
+	    &iov, EMSGSIZE);
+#else
 	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
-	if (error)
-		return (error);
+#endif
 	msg.msg_iov = iov;
 	msg.msg_flags = 0;
 	error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE);
@@ -997,44 +1095,168 @@ struct linux_recvmsg_args {
 static int
 linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args)
 {
-	struct recvmsg_args /* {
-		int	s;
-		struct	msghdr *msg;
-		int	flags;
-	} */ bsd_args;
 	struct msghdr msg;
-	struct cmsghdr *cmsg;
+	struct l_msghdr linux_msg;
+	struct l_cmsghdr *linux_cmsg = NULL;
+	struct iovec *iov, *uiov;
+	struct mbuf *control = NULL;
+	struct mbuf **controlp;
 	int error;
 
-	/* XXXTJR recvmsg is broken on amd64 */
+	error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg));
+	if (error)
+		return (error);
 
-	if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg))))
+	error = linux_to_bsd_msghdr(&msg, &linux_msg);
+	if (error)
 		return (error);
 
-	bsd_args.s = args->s;
-	bsd_args.msg = PTRIN(args->msg);
-	bsd_args.flags = linux_to_bsd_msg_flags(args->flags);
-	if (msg.msg_name) {
-	   	linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
-		      msg.msg_namelen);
-		error = recvmsg(td, &bsd_args);
-		bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name);
-	} else
-	   	error = recvmsg(td, &bsd_args);
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
+	    &iov, EMSGSIZE);
+#else
+	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
+#endif
 	if (error)
 		return (error);
 
-	if (bsd_args.msg->msg_control != NULL &&
-	    bsd_args.msg->msg_controllen > 0) {
-		cmsg = (struct cmsghdr*)bsd_args.msg->msg_control;
-		cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level);
+	if (msg.msg_name) {
+		error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
+		    msg.msg_namelen);
+		if (error)
+			goto bad;
 	}
 
-	error = copyin(PTRIN(args->msg), &msg, sizeof(msg));
+	uiov = msg.msg_iov;
+	msg.msg_iov = iov;
+	controlp = (msg.msg_control != NULL) ? &control : NULL;
+	error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp);
+	msg.msg_iov = uiov;
 	if (error)
-		return (error);
-	if (msg.msg_name && msg.msg_namelen > 2)
-		error = linux_sa_put(msg.msg_name);
+		goto bad;
+
+	error = bsd_to_linux_msghdr(&msg, &linux_msg);
+	if (error)
+		goto bad;
+
+	if (linux_msg.msg_name) {
+		error = bsd_to_linux_sockaddr((struct sockaddr *)
+		    PTRIN(linux_msg.msg_name));
+		if (error)
+			goto bad;
+	}
+	if (linux_msg.msg_name && linux_msg.msg_namelen > 2) {
+		error = linux_sa_put(PTRIN(linux_msg.msg_name));
+		if (error)
+			goto bad;
+	}
+
+	if (control) {
+		caddr_t outbuf;
+		struct cmsghdr *cm;
+		socklen_t datalen, outlen;
+		socklen_t clen;
+		void *data;
+		struct sockcred *scred;
+		struct l_ucred lcred;
+
+		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) {
+
+			switch (cm->cmsg_type) {
+			case SCM_CREDS:
+
+				scred = (struct sockcred *)CMSG_DATA(cm);
+				datalen = (caddr_t)cm + cm->cmsg_len -
+				    (caddr_t)scred;
+
+				if (outlen + LINUX_CMSG_LEN(sizeof(lcred)) >
+				    linux_msg.msg_controllen) {
+					linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+					goto out;
+				}
+
+				lcred.pid = -1;
+				lcred.uid = scred->sc_uid;
+				lcred.gid = scred->sc_gid;
+
+				linux_cmsg->cmsg_len =
+				    LINUX_CMSG_LEN(sizeof(lcred));
+				linux_cmsg->cmsg_type =
+				    bsd_to_linux_cmsg_type(cm->cmsg_type);
+				linux_cmsg->cmsg_level =
+				    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+				error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ);
+				if (error)
+					goto bad;
+				outbuf += L_CMSG_HDRSZ;
+
+				error = copyout(&lcred, outbuf, sizeof(lcred));
+				if (error)
+					goto bad;
+
+				outbuf += LINUX_CMSG_ALIGN(sizeof(lcred));
+				outlen += LINUX_CMSG_LEN(sizeof(lcred));
+				linux_msg.msg_controllen = outlen;
+				break;
+
+			default:
+
+				data = CMSG_DATA(cm);
+				datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data;
+
+				if (outlen + LINUX_CMSG_LEN(datalen) >
+				    linux_msg.msg_controllen) {
+					linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+					goto out;
+				}
+
+				linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen);
+				linux_cmsg->cmsg_type =
+				    bsd_to_linux_cmsg_type(cm->cmsg_type);
+				linux_cmsg->cmsg_level =
+				    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+				error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ);
+				if (error)
+					goto bad;
+				outbuf += L_CMSG_HDRSZ;
+
+				error = copyout(data, outbuf, datalen);
+				if (error)
+					goto bad;
+
+				outbuf += LINUX_CMSG_ALIGN(datalen);
+				outlen += LINUX_CMSG_LEN(datalen);
+				linux_msg.msg_controllen = outlen;
+				break;
+			}
+
+			if (CMSG_SPACE(datalen) < clen) {
+				clen -= CMSG_SPACE(datalen);
+				cm = (struct cmsghdr *)
+				    ((caddr_t)cm + CMSG_SPACE(datalen));
+			} else
+				cm = NULL;
+		}
+	}
+
+out:
+	error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg));
+
+bad:
+	free(iov, M_IOV);
+	if (control != NULL)
+		m_freem(control);
+	if (linux_cmsg != NULL)
+		free(linux_cmsg, M_TEMP);
+
 	return (error);
 }
 
@@ -1081,6 +1303,12 @@ linux_setsockopt(struct thread *td, struct linux_setsockopt_args *args)
 	switch (bsd_args.level) {
 	case SOL_SOCKET:
 		name = linux_to_bsd_so_sockopt(args->optname);
+		switch (args->optname) {
+		case LINUX_SO_PASSCRED:
+			/* FreeBSD bug? socket level opts at non socket level */
+			bsd_args.level = 0;
+			break;
+		}
 		break;
 	case IPPROTO_IP:
 		name = linux_to_bsd_ip_sockopt(args->optname);
@@ -1136,6 +1364,11 @@ linux_getsockopt(struct thread *td, struct linux_getsockopt_args *args)
 	switch (bsd_args.level) {
 	case SOL_SOCKET:
 		name = linux_to_bsd_so_sockopt(args->optname);
+		switch (args->optname) {
+		case LINUX_SO_PASSCRED:
+			bsd_args.level = 0;
+			break;
+		}
 		break;
 	case IPPROTO_IP:
 		name = linux_to_bsd_ip_sockopt(args->optname);
diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h
index 074e8e0..e8c2ec8 100644
--- a/src/sys/compat/linux/linux_socket.h
+++ b/src/sys/compat/linux/linux_socket.h
@@ -49,4 +49,36 @@
 #define LINUX_MSG_ERRQUEUE	0x2000
 #define LINUX_MSG_NOSIGNAL	0x4000
 
+/* Socket-level control message types */
+
+#define LINUX_SCM_RIGHTS	0x01
+#define LINUX_SCM_CREDENTIALS	0x02
+
+/* Ancilliary data object information macros */
+
+#define LINUX_CMSG_ALIGN(len)   (((len) + sizeof(l_long)-1) & ~(sizeof(l_long)-1))
+#define LINUX_CMSG_DATA(cmsg)   ((void *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr))))
+#define LINUX_CMSG_SPACE(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    LINUX_CMSG_ALIGN(len))
+#define LINUX_CMSG_LEN(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    (len))
+#define LINUX_CMSG_FIRSTHDR(msg) \
+				((msg)->msg_controllen >= \
+				    sizeof(struct l_cmsghdr) ? \
+				    (struct l_cmsghdr *)((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) + \
+				    (msg)->msg_controllen)) ? \
+				    (struct l_cmsghdr *) NULL : \
+				    (struct l_cmsghdr *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN((cmsg)->cmsg_len)))
+
+#define CMSG_HDRSZ		CMSG_LEN(0)
+#define L_CMSG_HDRSZ		LINUX_CMSG_LEN(0)
+
 #endif /* _LINUX_SOCKET_H_ */
diff --git a/src/sys/i386/linux/linux.h b/src/sys/i386/linux/linux.h
index 1c3627d..28655fe 100644
--- a/src/sys/i386/linux/linux.h
+++ b/src/sys/i386/linux/linux.h
@@ -656,6 +656,7 @@ union l_semun {
 #define	LINUX_SO_NO_CHECK	11
 #define	LINUX_SO_PRIORITY	12
 #define	LINUX_SO_LINGER		13
+#define	LINUX_SO_PASSCRED	16
 #define	LINUX_SO_PEERCRED	17
 #define	LINUX_SO_RCVLOWAT	18
 #define	LINUX_SO_SNDLOWAT	19
@@ -680,6 +681,28 @@ struct l_sockaddr {
 	char		sa_data[14];
 };
 
+struct l_msghdr {
+	l_uintptr_t	msg_name;
+	l_int		msg_namelen;
+	l_uintptr_t	msg_iov;
+	l_size_t	msg_iovlen;
+	l_uintptr_t	msg_control;
+	l_size_t	msg_controllen;
+	l_uint		msg_flags;
+};
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+};
+
+struct l_ucred {
+	uint32_t	pid;
+	uint32_t	uid;
+	uint32_t	gid;
+};
+
 struct l_ifmap {
 	l_ulong		mem_start;
 	l_ulong		mem_end;


-- 
Have fun!
chd
From dchagin at freebsd.org  Wed Sep 17 19:02:49 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Wed Sep 17 19:03:02 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080917183801.GA2714@dchagin.dialup.corbina.ru>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
Message-ID: <20080917190230.GA2947@dchagin.dialup.corbina.ru>

On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote:
> 
> Please review, any comment will be helpful.
> thnx!
> 

ups... I have lost a new file, the previous patch is incorrect. sorry.

diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h
index 8940289..9439900 100644
--- a/src/sys/amd64/linux32/linux.h
+++ b/src/sys/amd64/linux32/linux.h
@@ -685,6 +685,7 @@ union l_semun {
 #define	LINUX_SO_NO_CHECK	11
 #define	LINUX_SO_PRIORITY	12
 #define	LINUX_SO_LINGER		13
+#define	LINUX_SO_PASSCRED	16
 #define	LINUX_SO_PEERCRED	17
 #define	LINUX_SO_RCVLOWAT	18
 #define	LINUX_SO_SNDLOWAT	19
@@ -709,6 +710,28 @@ struct l_sockaddr {
 	char		sa_data[14];
 } __packed;
 
+struct l_msghdr {
+	l_uintptr_t	msg_name;
+	l_int		msg_namelen;
+	l_uintptr_t	msg_iov;
+	l_size_t	msg_iovlen;
+	l_uintptr_t	msg_control;
+	l_size_t	msg_controllen;
+	l_uint		msg_flags;
+} __packed;
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+} __packed;
+
+struct l_ucred {
+	uint32_t	pid;
+	uint32_t	uid;
+	uint32_t	gid;
+} __packed;
+
 struct l_ifmap {
 	l_ulong		mem_start;
 	l_ulong		mem_end;
diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h
new file mode 100644
index 0000000..c1a9f1c
--- /dev/null
+++ b/src/sys/amd64/linux32/linux32_io.h
@@ -0,0 +1,47 @@
+/*-
+ * Copyright (c) 2004 Tim J. Robbins
+ * Copyright (c) 2001 Doug Rabson
+ * Copyright (c) 1994-1996 S?ren Schmidt
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer
+ *    in this position and unchanged.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef _AMD64_LINUX32_IO_H_
+#define	_AMD64_LINUX32_IO_H_
+
+
+struct iovec32 {
+	u_int32_t	iov_base;
+	int		iov_len;
+};
+
+CTASSERT(sizeof(struct iovec32) == 8);
+
+int linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp,
+    int error);
+
+#endif /* !_AMD64_LINUX32_IO_H_ */
diff --git a/src/sys/amd64/linux32/linux32_machdep.c b/src/sys/amd64/linux32/linux32_machdep.c
index 32cbe0b..26459c9 100644
--- a/src/sys/amd64/linux32/linux32_machdep.c
+++ b/src/sys/amd64/linux32/linux32_machdep.c
@@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v 1.49 2008/09/08 09
 #include <vm/vm_map.h>
 
 #include <amd64/linux32/linux.h>
+#include <amd64/linux32/linux32_io.h>
 #include <amd64/linux32/linux32_proto.h>
 #include <compat/linux/linux_ipc.h>
 #include <compat/linux/linux_signal.h>
@@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args *args)
 	return (error);
 }
 
-struct iovec32 {
-	u_int32_t iov_base;
-	int	iov_len;
-};
-
-CTASSERT(sizeof(struct iovec32) == 8);
-
 static int
 linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop)
 {
@@ -281,6 +275,34 @@ linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop)
 }
 
 int
+linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp,
+    int error)
+{
+	struct iovec32 iov32;
+	struct iovec *iov;
+	u_int iovlen;
+	int i;
+
+	*iovp = NULL;
+	if (iovcnt > UIO_MAXIOV)
+		return (error);
+	iovlen = iovcnt * sizeof(struct iovec);
+	iov = malloc(iovlen, M_IOV, M_WAITOK);
+	for (i = 0; i < iovcnt; i++) {
+		error = copyin(&iovp32[i], &iov32, sizeof(struct iovec32));
+		if (error) {
+			free(iov, M_IOV);
+			return (error);
+		}
+		iov[i].iov_base = PTRIN(iov32.iov_base);
+		iov[i].iov_len = iov32.iov_len;
+	}
+	*iovp = iov;
+	return(0);
+
+}
+
+int
 linux_readv(struct thread *td, struct linux_readv_args *uap)
 {
 	struct uio *auio;
diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c
index f97aa23..34e25dc 100644
--- a/src/sys/compat/linux/linux_socket.c
+++ b/src/sys/compat/linux/linux_socket.c
@@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: src/sys/compat/linux/linux_socket.c,v 1.76 2008/09/09 13:01:
 
 #ifdef COMPAT_LINUX32
 #include <machine/../linux32/linux.h>
+#include <machine/../linux32/linux32_io.h>
 #include <machine/../linux32/linux32_proto.h>
 #else
 #include <machine/../linux/linux.h>
@@ -294,6 +295,8 @@ linux_to_bsd_so_sockopt(int opt)
 		return (SO_OOBINLINE);
 	case LINUX_SO_LINGER:
 		return (SO_LINGER);
+	case LINUX_SO_PASSCRED:
+		return (LOCAL_CREDS);
 	case LINUX_SO_PEERCRED:
 		return (LOCAL_PEERCRED);
 	case LINUX_SO_RCVLOWAT:
@@ -421,6 +424,63 @@ linux_sa_put(struct osockaddr *osa)
 }
 
 static int
+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 (cmsg_type);
+}
+
+static int
+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 (cmsg_type);
+}
+
+
+
+static int
+linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr)
+{
+	if (lhdr->msg_controllen > INT_MAX)
+		return (ENOBUFS);
+
+	bhdr->msg_name		= PTRIN(lhdr->msg_name);
+	bhdr->msg_namelen	= lhdr->msg_namelen;
+	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;
+	bhdr->msg_flags		= linux_to_bsd_msg_flags(lhdr->msg_flags);
+	return (0);
+}
+
+static int
+bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr)
+{
+	lhdr->msg_name		= PTROUT(bhdr->msg_name);
+	lhdr->msg_namelen	= bhdr->msg_namelen;
+	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_flags skipped */
+	return (0);
+}
+
+static int
 linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
     enum uio_seg segflg)
 {
@@ -437,25 +497,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
 		to = NULL;
 
 	if (mp->msg_control != NULL) {
+		struct l_cmsghdr *ptr_cmsg;
+		struct l_cmsghdr linux_cmsg;
 		struct cmsghdr *cmsg;
-
-		if (mp->msg_controllen < sizeof(struct cmsghdr)) {
-			error = EINVAL;
-			goto bad;
-		}
-		error = sockargs(&control, mp->msg_control,
-		    mp->msg_controllen, MT_CONTROL);
-		if (error)
-			goto bad;
-
-		cmsg = mtod(control, struct cmsghdr *);
-		cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level);
+		void *data;
+		socklen_t datalen;
+
+		cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO);
+		control = m_get(M_WAIT, MT_CONTROL);
+		ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp);
+
+		do {
+			error = copyin(ptr_cmsg, &linux_cmsg,
+			    sizeof(struct l_cmsghdr));
+			if (error)
+				goto bad;
+			if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) ||
+			    linux_cmsg.cmsg_len > INT_MAX) {
+				error = EINVAL;
+				goto bad;
+			}
+
+			switch (linux_cmsg.cmsg_type) {
+			case LINUX_SCM_RIGHTS:
+				cmsg->cmsg_type =
+				    linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type);
+				break;
+			default:
+				error = EINVAL;
+				goto bad;
+			}
+			cmsg->cmsg_level =
+			    linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level);
+
+			datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ;
+			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(mp, ptr_cmsg)));
+
+		free(cmsg, M_TEMP);
 	} else
 		control = NULL;
 
 	error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control,
 	    segflg);
-
 bad:
 	if (to)
 		FREE(to, M_SONAME);
@@ -960,12 +1052,14 @@ static int
 linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 {
 	struct msghdr msg;
+	struct l_msghdr linux_msg;
 	struct iovec *iov;
 	int error;
 
-	/* XXXTJR sendmsg is broken on amd64 */
-
-	error = copyin(PTRIN(args->msg), &msg, sizeof(msg));
+	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);
 
@@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 	 */
 	if (msg.msg_control != NULL && msg.msg_controllen == 0)
 		msg.msg_control = NULL;
+
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
+	    &iov, EMSGSIZE);
+#else
 	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
-	if (error)
-		return (error);
+#endif
 	msg.msg_iov = iov;
 	msg.msg_flags = 0;
 	error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE);
@@ -997,44 +1095,168 @@ struct linux_recvmsg_args {
 static int
 linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args)
 {
-	struct recvmsg_args /* {
-		int	s;
-		struct	msghdr *msg;
-		int	flags;
-	} */ bsd_args;
 	struct msghdr msg;
-	struct cmsghdr *cmsg;
+	struct l_msghdr linux_msg;
+	struct l_cmsghdr *linux_cmsg = NULL;
+	struct iovec *iov, *uiov;
+	struct mbuf *control = NULL;
+	struct mbuf **controlp;
 	int error;
 
-	/* XXXTJR recvmsg is broken on amd64 */
+	error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg));
+	if (error)
+		return (error);
 
-	if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg))))
+	error = linux_to_bsd_msghdr(&msg, &linux_msg);
+	if (error)
 		return (error);
 
-	bsd_args.s = args->s;
-	bsd_args.msg = PTRIN(args->msg);
-	bsd_args.flags = linux_to_bsd_msg_flags(args->flags);
-	if (msg.msg_name) {
-	   	linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
-		      msg.msg_namelen);
-		error = recvmsg(td, &bsd_args);
-		bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name);
-	} else
-	   	error = recvmsg(td, &bsd_args);
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
+	    &iov, EMSGSIZE);
+#else
+	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
+#endif
 	if (error)
 		return (error);
 
-	if (bsd_args.msg->msg_control != NULL &&
-	    bsd_args.msg->msg_controllen > 0) {
-		cmsg = (struct cmsghdr*)bsd_args.msg->msg_control;
-		cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level);
+	if (msg.msg_name) {
+		error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
+		    msg.msg_namelen);
+		if (error)
+			goto bad;
 	}
 
-	error = copyin(PTRIN(args->msg), &msg, sizeof(msg));
+	uiov = msg.msg_iov;
+	msg.msg_iov = iov;
+	controlp = (msg.msg_control != NULL) ? &control : NULL;
+	error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp);
+	msg.msg_iov = uiov;
 	if (error)
-		return (error);
-	if (msg.msg_name && msg.msg_namelen > 2)
-		error = linux_sa_put(msg.msg_name);
+		goto bad;
+
+	error = bsd_to_linux_msghdr(&msg, &linux_msg);
+	if (error)
+		goto bad;
+
+	if (linux_msg.msg_name) {
+		error = bsd_to_linux_sockaddr((struct sockaddr *)
+		    PTRIN(linux_msg.msg_name));
+		if (error)
+			goto bad;
+	}
+	if (linux_msg.msg_name && linux_msg.msg_namelen > 2) {
+		error = linux_sa_put(PTRIN(linux_msg.msg_name));
+		if (error)
+			goto bad;
+	}
+
+	if (control) {
+		caddr_t outbuf;
+		struct cmsghdr *cm;
+		socklen_t datalen, outlen;
+		socklen_t clen;
+		void *data;
+		struct sockcred *scred;
+		struct l_ucred lcred;
+
+		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) {
+
+			switch (cm->cmsg_type) {
+			case SCM_CREDS:
+
+				scred = (struct sockcred *)CMSG_DATA(cm);
+				datalen = (caddr_t)cm + cm->cmsg_len -
+				    (caddr_t)scred;
+
+				if (outlen + LINUX_CMSG_LEN(sizeof(lcred)) >
+				    linux_msg.msg_controllen) {
+					linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+					goto out;
+				}
+
+				lcred.pid = -1;
+				lcred.uid = scred->sc_uid;
+				lcred.gid = scred->sc_gid;
+
+				linux_cmsg->cmsg_len =
+				    LINUX_CMSG_LEN(sizeof(lcred));
+				linux_cmsg->cmsg_type =
+				    bsd_to_linux_cmsg_type(cm->cmsg_type);
+				linux_cmsg->cmsg_level =
+				    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+				error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ);
+				if (error)
+					goto bad;
+				outbuf += L_CMSG_HDRSZ;
+
+				error = copyout(&lcred, outbuf, sizeof(lcred));
+				if (error)
+					goto bad;
+
+				outbuf += LINUX_CMSG_ALIGN(sizeof(lcred));
+				outlen += LINUX_CMSG_LEN(sizeof(lcred));
+				linux_msg.msg_controllen = outlen;
+				break;
+
+			default:
+
+				data = CMSG_DATA(cm);
+				datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data;
+
+				if (outlen + LINUX_CMSG_LEN(datalen) >
+				    linux_msg.msg_controllen) {
+					linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+					goto out;
+				}
+
+				linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen);
+				linux_cmsg->cmsg_type =
+				    bsd_to_linux_cmsg_type(cm->cmsg_type);
+				linux_cmsg->cmsg_level =
+				    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+				error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ);
+				if (error)
+					goto bad;
+				outbuf += L_CMSG_HDRSZ;
+
+				error = copyout(data, outbuf, datalen);
+				if (error)
+					goto bad;
+
+				outbuf += LINUX_CMSG_ALIGN(datalen);
+				outlen += LINUX_CMSG_LEN(datalen);
+				linux_msg.msg_controllen = outlen;
+				break;
+			}
+
+			if (CMSG_SPACE(datalen) < clen) {
+				clen -= CMSG_SPACE(datalen);
+				cm = (struct cmsghdr *)
+				    ((caddr_t)cm + CMSG_SPACE(datalen));
+			} else
+				cm = NULL;
+		}
+	}
+
+out:
+	error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg));
+
+bad:
+	free(iov, M_IOV);
+	if (control != NULL)
+		m_freem(control);
+	if (linux_cmsg != NULL)
+		free(linux_cmsg, M_TEMP);
+
 	return (error);
 }
 
@@ -1081,6 +1303,12 @@ linux_setsockopt(struct thread *td, struct linux_setsockopt_args *args)
 	switch (bsd_args.level) {
 	case SOL_SOCKET:
 		name = linux_to_bsd_so_sockopt(args->optname);
+		switch (args->optname) {
+		case LINUX_SO_PASSCRED:
+			/* FreeBSD bug? socket level opts at non socket level */
+			bsd_args.level = 0;
+			break;
+		}
 		break;
 	case IPPROTO_IP:
 		name = linux_to_bsd_ip_sockopt(args->optname);
@@ -1136,6 +1364,11 @@ linux_getsockopt(struct thread *td, struct linux_getsockopt_args *args)
 	switch (bsd_args.level) {
 	case SOL_SOCKET:
 		name = linux_to_bsd_so_sockopt(args->optname);
+		switch (args->optname) {
+		case LINUX_SO_PASSCRED:
+			bsd_args.level = 0;
+			break;
+		}
 		break;
 	case IPPROTO_IP:
 		name = linux_to_bsd_ip_sockopt(args->optname);
diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h
index 074e8e0..e8c2ec8 100644
--- a/src/sys/compat/linux/linux_socket.h
+++ b/src/sys/compat/linux/linux_socket.h
@@ -49,4 +49,36 @@
 #define LINUX_MSG_ERRQUEUE	0x2000
 #define LINUX_MSG_NOSIGNAL	0x4000
 
+/* Socket-level control message types */
+
+#define LINUX_SCM_RIGHTS	0x01
+#define LINUX_SCM_CREDENTIALS	0x02
+
+/* Ancilliary data object information macros */
+
+#define LINUX_CMSG_ALIGN(len)   (((len) + sizeof(l_long)-1) & ~(sizeof(l_long)-1))
+#define LINUX_CMSG_DATA(cmsg)   ((void *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr))))
+#define LINUX_CMSG_SPACE(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    LINUX_CMSG_ALIGN(len))
+#define LINUX_CMSG_LEN(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    (len))
+#define LINUX_CMSG_FIRSTHDR(msg) \
+				((msg)->msg_controllen >= \
+				    sizeof(struct l_cmsghdr) ? \
+				    (struct l_cmsghdr *)((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) + \
+				    (msg)->msg_controllen)) ? \
+				    (struct l_cmsghdr *) NULL : \
+				    (struct l_cmsghdr *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN((cmsg)->cmsg_len)))
+
+#define CMSG_HDRSZ		CMSG_LEN(0)
+#define L_CMSG_HDRSZ		LINUX_CMSG_LEN(0)
+
 #endif /* _LINUX_SOCKET_H_ */
diff --git a/src/sys/i386/linux/linux.h b/src/sys/i386/linux/linux.h
index 1c3627d..28655fe 100644
--- a/src/sys/i386/linux/linux.h
+++ b/src/sys/i386/linux/linux.h
@@ -656,6 +656,7 @@ union l_semun {
 #define	LINUX_SO_NO_CHECK	11
 #define	LINUX_SO_PRIORITY	12
 #define	LINUX_SO_LINGER		13
+#define	LINUX_SO_PASSCRED	16
 #define	LINUX_SO_PEERCRED	17
 #define	LINUX_SO_RCVLOWAT	18
 #define	LINUX_SO_SNDLOWAT	19
@@ -680,6 +681,28 @@ struct l_sockaddr {
 	char		sa_data[14];
 };
 
+struct l_msghdr {
+	l_uintptr_t	msg_name;
+	l_int		msg_namelen;
+	l_uintptr_t	msg_iov;
+	l_size_t	msg_iovlen;
+	l_uintptr_t	msg_control;
+	l_size_t	msg_controllen;
+	l_uint		msg_flags;
+};
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+};
+
+struct l_ucred {
+	uint32_t	pid;
+	uint32_t	uid;
+	uint32_t	gid;
+};
+
 struct l_ifmap {
 	l_ulong		mem_start;
 	l_ulong		mem_end;

-- 
Have fun!
chd
From Alexander at Leidinger.net  Thu Sep 18 07:38:40 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Thu Sep 18 07:38:48 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080917190230.GA2947@dchagin.dialup.corbina.ru>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
	<20080917190230.GA2947@dchagin.dialup.corbina.ru>
Message-ID: <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>

Quoting "Chagin Dmitry" <dchagin@freebsd.org> (from Wed, 17 Sep 2008  
23:02:30 +0400):

> On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote:
>>
>> Please review, any comment will be helpful.

I did just a very quick look...

> @@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct  
> linux_sendmsg_args *args)
>  	 */
>  	if (msg.msg_control != NULL && msg.msg_controllen == 0)
>  		msg.msg_control = NULL;
> +
> +#if defined(__amd64__) && defined(COMPAT_LINUX32)
> +	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
> +	    &iov, EMSGSIZE);
> +#else
>  	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
> -	if (error)
> -		return (error);
> +#endif
>  	msg.msg_iov = iov;
>  	msg.msg_flags = 0;
>  	error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE);

You've lost the error handling in the conditional.

Bye,
Alexander.

-- 
BOFH excuse #266:

All of the packets are empty

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From dchagin at freebsd.org  Thu Sep 18 13:57:45 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Thu Sep 18 13:57:58 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
	<20080917190230.GA2947@dchagin.dialup.corbina.ru>
	<20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>
Message-ID: <20080918135736.GA2218@dchagin.dialup.corbina.ru>

On Thu, Sep 18, 2008 at 09:38:31AM +0200, Alexander Leidinger wrote:
> Quoting "Chagin Dmitry" <dchagin@freebsd.org> (from Wed, 17 Sep 2008  
> 23:02:30 +0400):
> 
> >On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote:
> >>
> >>Please review, any comment will be helpful.
> 
> I did just a very quick look...
> 
> >@@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct  
> >linux_sendmsg_args *args)
> > 	 */
> > 	if (msg.msg_control != NULL && msg.msg_controllen == 0)
> > 		msg.msg_control = NULL;
> >+
> >+#if defined(__amd64__) && defined(COMPAT_LINUX32)
> >+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
> >+	    &iov, EMSGSIZE);
> >+#else
> > 	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
> >-	if (error)
> >-		return (error);
> >+#endif
> > 	msg.msg_iov = iov;
> > 	msg.msg_flags = 0;
> > 	error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE);
> 
> You've lost the error handling in the conditional.
> 

It's accepted, thnx!


diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h
index 8940289..9439900 100644
--- a/src/sys/amd64/linux32/linux.h
+++ b/src/sys/amd64/linux32/linux.h
@@ -685,6 +685,7 @@ union l_semun {
 #define	LINUX_SO_NO_CHECK	11
 #define	LINUX_SO_PRIORITY	12
 #define	LINUX_SO_LINGER		13
+#define	LINUX_SO_PASSCRED	16
 #define	LINUX_SO_PEERCRED	17
 #define	LINUX_SO_RCVLOWAT	18
 #define	LINUX_SO_SNDLOWAT	19
@@ -709,6 +710,28 @@ struct l_sockaddr {
 	char		sa_data[14];
 } __packed;
 
+struct l_msghdr {
+	l_uintptr_t	msg_name;
+	l_int		msg_namelen;
+	l_uintptr_t	msg_iov;
+	l_size_t	msg_iovlen;
+	l_uintptr_t	msg_control;
+	l_size_t	msg_controllen;
+	l_uint		msg_flags;
+} __packed;
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+} __packed;
+
+struct l_ucred {
+	uint32_t	pid;
+	uint32_t	uid;
+	uint32_t	gid;
+} __packed;
+
 struct l_ifmap {
 	l_ulong		mem_start;
 	l_ulong		mem_end;
diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h
new file mode 100644
index 0000000..c1a9f1c
--- /dev/null
+++ b/src/sys/amd64/linux32/linux32_io.h
@@ -0,0 +1,47 @@
+/*-
+ * Copyright (c) 2004 Tim J. Robbins
+ * Copyright (c) 2001 Doug Rabson
+ * Copyright (c) 1994-1996 S?ren Schmidt
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer
+ *    in this position and unchanged.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef _AMD64_LINUX32_IO_H_
+#define	_AMD64_LINUX32_IO_H_
+
+
+struct iovec32 {
+	u_int32_t	iov_base;
+	int		iov_len;
+};
+
+CTASSERT(sizeof(struct iovec32) == 8);
+
+int linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp,
+    int error);
+
+#endif /* !_AMD64_LINUX32_IO_H_ */
diff --git a/src/sys/amd64/linux32/linux32_machdep.c b/src/sys/amd64/linux32/linux32_machdep.c
index 32cbe0b..26459c9 100644
--- a/src/sys/amd64/linux32/linux32_machdep.c
+++ b/src/sys/amd64/linux32/linux32_machdep.c
@@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v 1.49 2008/09/08 09
 #include <vm/vm_map.h>
 
 #include <amd64/linux32/linux.h>
+#include <amd64/linux32/linux32_io.h>
 #include <amd64/linux32/linux32_proto.h>
 #include <compat/linux/linux_ipc.h>
 #include <compat/linux/linux_signal.h>
@@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args *args)
 	return (error);
 }
 
-struct iovec32 {
-	u_int32_t iov_base;
-	int	iov_len;
-};
-
-CTASSERT(sizeof(struct iovec32) == 8);
-
 static int
 linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop)
 {
@@ -281,6 +275,34 @@ linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop)
 }
 
 int
+linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp,
+    int error)
+{
+	struct iovec32 iov32;
+	struct iovec *iov;
+	u_int iovlen;
+	int i;
+
+	*iovp = NULL;
+	if (iovcnt > UIO_MAXIOV)
+		return (error);
+	iovlen = iovcnt * sizeof(struct iovec);
+	iov = malloc(iovlen, M_IOV, M_WAITOK);
+	for (i = 0; i < iovcnt; i++) {
+		error = copyin(&iovp32[i], &iov32, sizeof(struct iovec32));
+		if (error) {
+			free(iov, M_IOV);
+			return (error);
+		}
+		iov[i].iov_base = PTRIN(iov32.iov_base);
+		iov[i].iov_len = iov32.iov_len;
+	}
+	*iovp = iov;
+	return(0);
+
+}
+
+int
 linux_readv(struct thread *td, struct linux_readv_args *uap)
 {
 	struct uio *auio;
diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c
index f97aa23..634389d 100644
--- a/src/sys/compat/linux/linux_socket.c
+++ b/src/sys/compat/linux/linux_socket.c
@@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: src/sys/compat/linux/linux_socket.c,v 1.76 2008/09/09 13:01:
 
 #ifdef COMPAT_LINUX32
 #include <machine/../linux32/linux.h>
+#include <machine/../linux32/linux32_io.h>
 #include <machine/../linux32/linux32_proto.h>
 #else
 #include <machine/../linux/linux.h>
@@ -294,6 +295,8 @@ linux_to_bsd_so_sockopt(int opt)
 		return (SO_OOBINLINE);
 	case LINUX_SO_LINGER:
 		return (SO_LINGER);
+	case LINUX_SO_PASSCRED:
+		return (LOCAL_CREDS);
 	case LINUX_SO_PEERCRED:
 		return (LOCAL_PEERCRED);
 	case LINUX_SO_RCVLOWAT:
@@ -414,9 +417,64 @@ linux_sa_put(struct osockaddr *osa)
 
 	sa.sa_family = bdom;
 	error = copyout(&sa, osa, sizeof(sa.sa_family));
-	if (error)
-		return (error);
 
+	return (error);
+}
+
+static int
+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 (cmsg_type);
+}
+
+static int
+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 (cmsg_type);
+}
+
+
+
+static int
+linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr)
+{
+	if (lhdr->msg_controllen > INT_MAX)
+		return (ENOBUFS);
+
+	bhdr->msg_name		= PTRIN(lhdr->msg_name);
+	bhdr->msg_namelen	= lhdr->msg_namelen;
+	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;
+	bhdr->msg_flags		= linux_to_bsd_msg_flags(lhdr->msg_flags);
+	return (0);
+}
+
+static int
+bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr)
+{
+	lhdr->msg_name		= PTROUT(bhdr->msg_name);
+	lhdr->msg_namelen	= bhdr->msg_namelen;
+	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_flags skipped */
 	return (0);
 }
 
@@ -437,25 +495,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
 		to = NULL;
 
 	if (mp->msg_control != NULL) {
+		struct l_cmsghdr *ptr_cmsg;
+		struct l_cmsghdr linux_cmsg;
 		struct cmsghdr *cmsg;
-
-		if (mp->msg_controllen < sizeof(struct cmsghdr)) {
-			error = EINVAL;
-			goto bad;
-		}
-		error = sockargs(&control, mp->msg_control,
-		    mp->msg_controllen, MT_CONTROL);
-		if (error)
-			goto bad;
-
-		cmsg = mtod(control, struct cmsghdr *);
-		cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level);
+		void *data;
+		socklen_t datalen;
+
+		cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO);
+		control = m_get(M_WAIT, MT_CONTROL);
+		ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp);
+
+		do {
+			error = copyin(ptr_cmsg, &linux_cmsg,
+			    sizeof(struct l_cmsghdr));
+			if (error)
+				goto bad;
+			if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) ||
+			    linux_cmsg.cmsg_len > INT_MAX) {
+				error = EINVAL;
+				goto bad;
+			}
+
+			switch (linux_cmsg.cmsg_type) {
+			case LINUX_SCM_RIGHTS:
+				cmsg->cmsg_type =
+				    linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type);
+				break;
+			default:
+				error = EINVAL;
+				goto bad;
+			}
+			cmsg->cmsg_level =
+			    linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level);
+
+			datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ;
+			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(mp, ptr_cmsg)));
+
+		free(cmsg, M_TEMP);
 	} else
 		control = NULL;
 
 	error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control,
 	    segflg);
-
 bad:
 	if (to)
 		FREE(to, M_SONAME);
@@ -960,12 +1050,14 @@ static int
 linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 {
 	struct msghdr msg;
+	struct l_msghdr linux_msg;
 	struct iovec *iov;
 	int error;
 
-	/* XXXTJR sendmsg is broken on amd64 */
-
-	error = copyin(PTRIN(args->msg), &msg, sizeof(msg));
+	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);
 
@@ -978,7 +1070,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 	 */
 	if (msg.msg_control != NULL && msg.msg_controllen == 0)
 		msg.msg_control = NULL;
+
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
+	    &iov, EMSGSIZE);
+#else
 	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
+#endif
 	if (error)
 		return (error);
 	msg.msg_iov = iov;
@@ -997,44 +1095,168 @@ struct linux_recvmsg_args {
 static int
 linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args)
 {
-	struct recvmsg_args /* {
-		int	s;
-		struct	msghdr *msg;
-		int	flags;
-	} */ bsd_args;
 	struct msghdr msg;
-	struct cmsghdr *cmsg;
+	struct l_msghdr linux_msg;
+	struct l_cmsghdr *linux_cmsg = NULL;
+	struct iovec *iov, *uiov;
+	struct mbuf *control = NULL;
+	struct mbuf **controlp;
 	int error;
 
-	/* XXXTJR recvmsg is broken on amd64 */
+	error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg));
+	if (error)
+		return (error);
 
-	if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg))))
+	error = linux_to_bsd_msghdr(&msg, &linux_msg);
+	if (error)
 		return (error);
 
-	bsd_args.s = args->s;
-	bsd_args.msg = PTRIN(args->msg);
-	bsd_args.flags = linux_to_bsd_msg_flags(args->flags);
-	if (msg.msg_name) {
-	   	linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
-		      msg.msg_namelen);
-		error = recvmsg(td, &bsd_args);
-		bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name);
-	} else
-	   	error = recvmsg(td, &bsd_args);
+#if defined(__amd64__) && defined(COMPAT_LINUX32)
+	error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
+	    &iov, EMSGSIZE);
+#else
+	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
+#endif
 	if (error)
 		return (error);
 
-	if (bsd_args.msg->msg_control != NULL &&
-	    bsd_args.msg->msg_controllen > 0) {
-		cmsg = (struct cmsghdr*)bsd_args.msg->msg_control;
-		cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level);
+	if (msg.msg_name) {
+		error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
+		    msg.msg_namelen);
+		if (error)
+			goto bad;
 	}
 
-	error = copyin(PTRIN(args->msg), &msg, sizeof(msg));
+	uiov = msg.msg_iov;
+	msg.msg_iov = iov;
+	controlp = (msg.msg_control != NULL) ? &control : NULL;
+	error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp);
+	msg.msg_iov = uiov;
 	if (error)
-		return (error);
-	if (msg.msg_name && msg.msg_namelen > 2)
-		error = linux_sa_put(msg.msg_name);
+		goto bad;
+
+	error = bsd_to_linux_msghdr(&msg, &linux_msg);
+	if (error)
+		goto bad;
+
+	if (linux_msg.msg_name) {
+		error = bsd_to_linux_sockaddr((struct sockaddr *)
+		    PTRIN(linux_msg.msg_name));
+		if (error)
+			goto bad;
+	}
+	if (linux_msg.msg_name && linux_msg.msg_namelen > 2) {
+		error = linux_sa_put(PTRIN(linux_msg.msg_name));
+		if (error)
+			goto bad;
+	}
+
+	if (control) {
+		caddr_t outbuf;
+		struct cmsghdr *cm;
+		socklen_t datalen, outlen;
+		socklen_t clen;
+		void *data;
+		struct sockcred *scred;
+		struct l_ucred lcred;
+
+		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) {
+
+			switch (cm->cmsg_type) {
+			case SCM_CREDS:
+
+				scred = (struct sockcred *)CMSG_DATA(cm);
+				datalen = (caddr_t)cm + cm->cmsg_len -
+				    (caddr_t)scred;
+
+				if (outlen + LINUX_CMSG_LEN(sizeof(lcred)) >
+				    linux_msg.msg_controllen) {
+					linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+					goto out;
+				}
+
+				lcred.pid = -1;
+				lcred.uid = scred->sc_uid;
+				lcred.gid = scred->sc_gid;
+
+				linux_cmsg->cmsg_len =
+				    LINUX_CMSG_LEN(sizeof(lcred));
+				linux_cmsg->cmsg_type =
+				    bsd_to_linux_cmsg_type(cm->cmsg_type);
+				linux_cmsg->cmsg_level =
+				    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+				error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ);
+				if (error)
+					goto bad;
+				outbuf += L_CMSG_HDRSZ;
+
+				error = copyout(&lcred, outbuf, sizeof(lcred));
+				if (error)
+					goto bad;
+
+				outbuf += LINUX_CMSG_ALIGN(sizeof(lcred));
+				outlen += LINUX_CMSG_LEN(sizeof(lcred));
+				linux_msg.msg_controllen = outlen;
+				break;
+
+			default:
+
+				data = CMSG_DATA(cm);
+				datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data;
+
+				if (outlen + LINUX_CMSG_LEN(datalen) >
+				    linux_msg.msg_controllen) {
+					linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+					goto out;
+				}
+
+				linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen);
+				linux_cmsg->cmsg_type =
+				    bsd_to_linux_cmsg_type(cm->cmsg_type);
+				linux_cmsg->cmsg_level =
+				    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+				error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ);
+				if (error)
+					goto bad;
+				outbuf += L_CMSG_HDRSZ;
+
+				error = copyout(data, outbuf, datalen);
+				if (error)
+					goto bad;
+
+				outbuf += LINUX_CMSG_ALIGN(datalen);
+				outlen += LINUX_CMSG_LEN(datalen);
+				linux_msg.msg_controllen = outlen;
+				break;
+			}
+
+			if (CMSG_SPACE(datalen) < clen) {
+				clen -= CMSG_SPACE(datalen);
+				cm = (struct cmsghdr *)
+				    ((caddr_t)cm + CMSG_SPACE(datalen));
+			} else
+				cm = NULL;
+		}
+	}
+
+out:
+	error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg));
+
+bad:
+	free(iov, M_IOV);
+	if (control != NULL)
+		m_freem(control);
+	if (linux_cmsg != NULL)
+		free(linux_cmsg, M_TEMP);
+
 	return (error);
 }
 
@@ -1081,6 +1303,12 @@ linux_setsockopt(struct thread *td, struct linux_setsockopt_args *args)
 	switch (bsd_args.level) {
 	case SOL_SOCKET:
 		name = linux_to_bsd_so_sockopt(args->optname);
+		switch (args->optname) {
+		case LINUX_SO_PASSCRED:
+			/* FreeBSD bug? socket level opts at non socket level */
+			bsd_args.level = 0;
+			break;
+		}
 		break;
 	case IPPROTO_IP:
 		name = linux_to_bsd_ip_sockopt(args->optname);
@@ -1136,6 +1364,11 @@ linux_getsockopt(struct thread *td, struct linux_getsockopt_args *args)
 	switch (bsd_args.level) {
 	case SOL_SOCKET:
 		name = linux_to_bsd_so_sockopt(args->optname);
+		switch (args->optname) {
+		case LINUX_SO_PASSCRED:
+			bsd_args.level = 0;
+			break;
+		}
 		break;
 	case IPPROTO_IP:
 		name = linux_to_bsd_ip_sockopt(args->optname);
diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h
index 074e8e0..e8c2ec8 100644
--- a/src/sys/compat/linux/linux_socket.h
+++ b/src/sys/compat/linux/linux_socket.h
@@ -49,4 +49,36 @@
 #define LINUX_MSG_ERRQUEUE	0x2000
 #define LINUX_MSG_NOSIGNAL	0x4000
 
+/* Socket-level control message types */
+
+#define LINUX_SCM_RIGHTS	0x01
+#define LINUX_SCM_CREDENTIALS	0x02
+
+/* Ancilliary data object information macros */
+
+#define LINUX_CMSG_ALIGN(len)   (((len) + sizeof(l_long)-1) & ~(sizeof(l_long)-1))
+#define LINUX_CMSG_DATA(cmsg)   ((void *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr))))
+#define LINUX_CMSG_SPACE(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    LINUX_CMSG_ALIGN(len))
+#define LINUX_CMSG_LEN(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    (len))
+#define LINUX_CMSG_FIRSTHDR(msg) \
+				((msg)->msg_controllen >= \
+				    sizeof(struct l_cmsghdr) ? \
+				    (struct l_cmsghdr *)((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) + \
+				    (msg)->msg_controllen)) ? \
+				    (struct l_cmsghdr *) NULL : \
+				    (struct l_cmsghdr *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN((cmsg)->cmsg_len)))
+
+#define CMSG_HDRSZ		CMSG_LEN(0)
+#define L_CMSG_HDRSZ		LINUX_CMSG_LEN(0)
+
 #endif /* _LINUX_SOCKET_H_ */
diff --git a/src/sys/i386/linux/linux.h b/src/sys/i386/linux/linux.h
index 1c3627d..28655fe 100644
--- a/src/sys/i386/linux/linux.h
+++ b/src/sys/i386/linux/linux.h
@@ -656,6 +656,7 @@ union l_semun {
 #define	LINUX_SO_NO_CHECK	11
 #define	LINUX_SO_PRIORITY	12
 #define	LINUX_SO_LINGER		13
+#define	LINUX_SO_PASSCRED	16
 #define	LINUX_SO_PEERCRED	17
 #define	LINUX_SO_RCVLOWAT	18
 #define	LINUX_SO_SNDLOWAT	19
@@ -680,6 +681,28 @@ struct l_sockaddr {
 	char		sa_data[14];
 };
 
+struct l_msghdr {
+	l_uintptr_t	msg_name;
+	l_int		msg_namelen;
+	l_uintptr_t	msg_iov;
+	l_size_t	msg_iovlen;
+	l_uintptr_t	msg_control;
+	l_size_t	msg_controllen;
+	l_uint		msg_flags;
+};
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+};
+
+struct l_ucred {
+	uint32_t	pid;
+	uint32_t	uid;
+	uint32_t	gid;
+};
+
 struct l_ifmap {
 	l_ulong		mem_start;
 	l_ulong		mem_end;


-- 
Have fun!
chd
From kostikbel at gmail.com  Thu Sep 18 14:25:08 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Thu Sep 18 14:25:14 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080918135736.GA2218@dchagin.dialup.corbina.ru>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
	<20080917190230.GA2947@dchagin.dialup.corbina.ru>
	<20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>
	<20080918135736.GA2218@dchagin.dialup.corbina.ru>
Message-ID: <20080918142454.GK39652@deviant.kiev.zoral.com.ua>

On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote:
> diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h
> new file mode 100644
> index 0000000..c1a9f1c
> --- /dev/null
> +++ b/src/sys/amd64/linux32/linux32_io.h
> @@ -0,0 +1,47 @@
> +/*-
> + * Copyright (c) 2004 Tim J. Robbins
> + * Copyright (c) 2001 Doug Rabson
> + * Copyright (c) 1994-1996 S?ren Schmidt
> + * All rights reserved.
^^^^^^^^^^ Is this true ?

Coloring this further, do we need a new include file for one structure
and one function ?

P.S. Your MUA sets Mail-Followup-To: to the full list of the recipients
_except_ you. Is this intentional ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080918/8d58bc8e/attachment.pgp
From dchagin at freebsd.org  Thu Sep 18 15:08:07 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Thu Sep 18 15:08:13 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080918142454.GK39652@deviant.kiev.zoral.com.ua>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
	<20080917190230.GA2947@dchagin.dialup.corbina.ru>
	<20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>
	<20080918135736.GA2218@dchagin.dialup.corbina.ru>
	<20080918142454.GK39652@deviant.kiev.zoral.com.ua>
Message-ID: <20080918150759.GA2898@dchagin.dialup.corbina.ru>

On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote:
> On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote:
> > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h
> > new file mode 100644
> > index 0000000..c1a9f1c
> > --- /dev/null
> > +++ b/src/sys/amd64/linux32/linux32_io.h
> > @@ -0,0 +1,47 @@
> > +/*-
> > + * Copyright (c) 2004 Tim J. Robbins
> > + * Copyright (c) 2001 Doug Rabson
> > + * Copyright (c) 1994-1996 S?ren Schmidt
> > + * All rights reserved.
> ^^^^^^^^^^ Is this true ?
> 

I have copied it from linux.h, can I remove it?

> Coloring this further, do we need a new include file for one structure
> and one function ?
> 

You suggest to transfer it to linux.h?
I can do it, but then it is necessary to insert #include <sys/uio.h>
into all files which include linux.h

thnx!
-- 
Have fun!
chd
From kostikbel at gmail.com  Thu Sep 18 15:31:17 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Thu Sep 18 15:31:23 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080918150759.GA2898@dchagin.dialup.corbina.ru>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
	<20080917190230.GA2947@dchagin.dialup.corbina.ru>
	<20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>
	<20080918135736.GA2218@dchagin.dialup.corbina.ru>
	<20080918142454.GK39652@deviant.kiev.zoral.com.ua>
	<20080918150759.GA2898@dchagin.dialup.corbina.ru>
Message-ID: <20080918153111.GL39652@deviant.kiev.zoral.com.ua>

On Thu, Sep 18, 2008 at 07:07:59PM +0400, Chagin Dmitry wrote:

I still cannot answer to you, so be it.

> On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote:
> > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote:
> > > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h
> > > new file mode 100644
> > > index 0000000..c1a9f1c
> > > --- /dev/null
> > > +++ b/src/sys/amd64/linux32/linux32_io.h
> > > @@ -0,0 +1,47 @@
> > > +/*-
> > > + * Copyright (c) 2004 Tim J. Robbins
> > > + * Copyright (c) 2001 Doug Rabson
> > > + * Copyright (c) 1994-1996 S?ren Schmidt
> > > + * All rights reserved.
> > ^^^^^^^^^^ Is this true ?
> > 
> 
> I have copied it from linux.h, can I remove it?

No, you should specify yourself as the copyright holder.

> 
> > Coloring this further, do we need a new include file for one structure
> > and one function ?
> > 
> 
> You suggest to transfer it to linux.h?
> I can do it, but then it is necessary to insert #include <sys/uio.h>
> into all files which include linux.h

This may be a trouble. Is there any other compat/linux include that
requires uio ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080918/eaea9f0d/attachment.pgp
From dchagin at freebsd.org  Thu Sep 18 15:56:34 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Thu Sep 18 15:56:45 2008
Subject: [PATCH] recvmsg() sendmsg() linux emulation
In-Reply-To: <20080918153111.GL39652@deviant.kiev.zoral.com.ua>
References: <20080822112946.GA97526@freebsd.org>
	<20080831110610.GA2380@dchagin.dialup.corbina.ru>
	<20080902085623.GA12395@freebsd.org>
	<20080917183801.GA2714@dchagin.dialup.corbina.ru>
	<20080917190230.GA2947@dchagin.dialup.corbina.ru>
	<20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net>
	<20080918135736.GA2218@dchagin.dialup.corbina.ru>
	<20080918142454.GK39652@deviant.kiev.zoral.com.ua>
	<20080918150759.GA2898@dchagin.dialup.corbina.ru>
	<20080918153111.GL39652@deviant.kiev.zoral.com.ua>
Message-ID: <20080918155626.GA3299@dchagin.dialup.corbina.ru>

On Thu, Sep 18, 2008 at 06:31:11PM +0300, Kostik Belousov wrote:
> On Thu, Sep 18, 2008 at 07:07:59PM +0400, Chagin Dmitry wrote:
> 
> I still cannot answer to you, so be it.
> 
> > On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote:
> > > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote:
> > > > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h
> > > > new file mode 100644
> > > > index 0000000..c1a9f1c
> > > > --- /dev/null
> > > > +++ b/src/sys/amd64/linux32/linux32_io.h
> > > > @@ -0,0 +1,47 @@
> > > > +/*-
> > > > + * Copyright (c) 2004 Tim J. Robbins
> > > > + * Copyright (c) 2001 Doug Rabson
> > > > + * Copyright (c) 1994-1996 S?ren Schmidt
> > > > + * All rights reserved.
> > > ^^^^^^^^^^ Is this true ?
> > > 
> > 
> > I have copied it from linux.h, can I remove it?
> 
> No, you should specify yourself as the copyright holder.
> 

ok

> > 
> > > Coloring this further, do we need a new include file for one structure
> > > and one function ?
> > > 
> > 
> > You suggest to transfer it to linux.h?
> > I can do it, but then it is necessary to insert #include <sys/uio.h>
> > into all files which include linux.h
> 
> This may be a trouble. Is there any other compat/linux include that
> requires uio ?

yes, linux_util.h include uio now, but iovec32 stuff specific only
for ia32@amd64 emulation.

-- 
Have fun!
chd
From itetcu at FreeBSD.org  Fri Sep 19 07:39:59 2008
From: itetcu at FreeBSD.org (Ion-Mihai Tetcu)
Date: Fri Sep 19 07:40:05 2008
Subject: x11-themes/linux-hicolor-icon-theme fails to install if
 sysutils/linux-nero
Message-ID: <20080919102216.389c930f@it.buh.tecnik93.com>

Hi,


While trying to portupgrade acroreader I run into the following problem:

[...]
===>   acroread8-8.1.2_2 depends on file: /usr/local/lib/linux-nvu/libgtkembedmoz.so - not found
===>    Verifying reinstall for /usr/local/lib/linux-nvu/libgtkembedmoz.so in /usr/ports/www/linux-nvu
[...]
===>  Installing for linux-nvu-1.0
[...]
===>   linux-nvu-1.0 depends on file: /compat/linux/usr/share/icons/hicolor/index.theme - not found
===>    Verifying reinstall for /compat/linux/usr/share/icons/hicolor/index.theme in /usr/ports/x11-themes/linux-hicolor-icon-theme
[...]

===>  Installing for linux-hicolor-icon-theme-0.5_1
===>   linux-hicolor-icon-theme-0.5_1 depends on file: /usr/local/share/icons/hicolor/index.theme - found
===>   linux-hicolor-icon-theme-0.5_1 depends on file: /compat/linux/bin/sh - found
===>   Generating temporary packing list
install -d /compat/linux/usr/share/icons
/bin/ln -fs /usr/local/share/icons/hicolor /compat/linux/usr/share/icons
ln: /compat/linux/usr/share/icons/hicolor: Operation not permitted
*** Error code 1


This happens because I already have
/compat/linux/usr/share/icons/hicolor with sysutils/linux-nero's icons.

Installing x11-themes/linux-hicolor-icon-theme first then
sysutils/linux-nero's "fixes" the problem.

While I'm not sure this is the right fix, making sysutils/linux-nero's
RUN_DEPEND on x11-themes/linux-hicolor-icon-theme will fix this.


-- 
IOnut - Un^d^dregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"
FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080919/a58a16f2/signature.pgp
From jhein at timing.com  Fri Sep 19 15:38:52 2008
From: jhein at timing.com (John Hein)
Date: Fri Sep 19 15:38:58 2008
Subject: x11-themes/linux-hicolor-icon-theme fails to install if
 sysutils/linux-nero
In-Reply-To: <20080919102216.389c930f@it.buh.tecnik93.com>
References: <20080919102216.389c930f@it.buh.tecnik93.com>
Message-ID: <18643.47349.732101.661496@gromit.timing.com>

Ion-Mihai Tetcu wrote at 10:22 +0300 on Sep 19, 2008:
 > While trying to portupgrade acroreader I run into the following problem:
 > 
 > [...]
 > ===>   acroread8-8.1.2_2 depends on file: /usr/local/lib/linux-nvu/libgtkembedmoz.so - not found
 > ===>    Verifying reinstall for /usr/local/lib/linux-nvu/libgtkembedmoz.so in /usr/ports/www/linux-nvu
 > [...]
 > ===>  Installing for linux-nvu-1.0
 > [...]
 > ===>   linux-nvu-1.0 depends on file: /compat/linux/usr/share/icons/hicolor/index.theme - not found
 > ===>    Verifying reinstall for /compat/linux/usr/share/icons/hicolor/index.theme in /usr/ports/x11-themes/linux-hicolor-icon-theme
 > [...]
 > 
 > ===>  Installing for linux-hicolor-icon-theme-0.5_1
 > ===>   linux-hicolor-icon-theme-0.5_1 depends on file: /usr/local/share/icons/hicolor/index.theme - found
 > ===>   linux-hicolor-icon-theme-0.5_1 depends on file: /compat/linux/bin/sh - found
 > ===>   Generating temporary packing list
 > install -d /compat/linux/usr/share/icons
 > /bin/ln -fs /usr/local/share/icons/hicolor /compat/linux/usr/share/icons
 > ln: /compat/linux/usr/share/icons/hicolor: Operation not permitted
 > *** Error code 1
 > 
 > 
 > This happens because I already have
 > /compat/linux/usr/share/icons/hicolor with sysutils/linux-nero's icons.
 > 
 > Installing x11-themes/linux-hicolor-icon-theme first then
 > sysutils/linux-nero's "fixes" the problem.
 > 
 > While I'm not sure this is the right fix, making sysutils/linux-nero's
 > RUN_DEPEND on x11-themes/linux-hicolor-icon-theme will fix this.

Won't that cause the linux-nero port to install it's icon files into
/usr/local/share/icons (through the sym link), but leave the plist
relative to LINUXBASE?

The problem is that linux-hicolor-icon-theme assumes it owns
everything under share/icons/hicolor.

Has anyone ever considered using unionfs for /compat/linux/usr/share?

One problem I can see is that 'share' is not the only directory
that should be shared.  etc?

I'm not sure unionfs is up to the job, but I'm wondering if any has
considered it or even tried it.
From trebestie at gmail.com  Sat Sep 20 17:02:05 2008
From: trebestie at gmail.com (Diego Depaoli)
Date: Sat Sep 20 17:02:07 2008
Subject: Enemy territory does not run
Message-ID: <83e5fb980809200930v5e9c4a33j5fddb72f6d9304ca@mail.gmail.com>

Launching enemy-territory on my CURRENT I get a segmentation fault and
that system message:
linux_sys_futex: unknown op 798242337

I have  linux_base-f8-8_4 installed and a Nvidia card.

I don't remember the last time I played that game, so I don't know
since it is broken.

Regards
-- 
Diego Depaoli
From nox at jelal.kn-bremen.de  Sun Sep 21 20:43:20 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sun Sep 21 20:43:23 2008
Subject: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates...
Message-ID: <20080921204025.GA81055@saturn.kn-bremen.de>

Hi!

 I've been playing with qemu svn on FreeBSD again (new experimental
emulators/qemu-devel port update here:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
), and want to note a few things:

 1. usb is still absymally slow, especially emulated disks (disk:imagefile)
and nics, both read/receive at about 30 KBytes/s here.  Is anyone working
on this?  I also got a report that its slow on Linux hosts too, so this
problem doesn't appear to be FreeBSD specific...

 2. -vmwarevga _seems_ to be less broken when run with 16 bpp, only 24
bpp seems to get the fifo errors that I posted about last time:
	http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00893.html
(maybe also the patch I posted there is only needed when running the guest
with 24 bpp.)  vmmouse seems to be broken too tho, the guest acts as if
the mouse is stuck in the bottom right corner.  (maybe I didn't actually
test this the last time, or it has something to do with the newer guest
that I used this time which also has a newer xorg version among other
things,
	sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso
announcement including mirror list is here:
	http://sidux.com/Article450.html
)  The guest xorg crashes with -kernel-kqemu also still happen.

 Oh and that guest tries to use vmmouse by default if run with
-vmwarevga, to disable it you can boot to runlevel 3 (add a 3 to the
grub line), su, change vmmouse to mouse in /etc/X11/xorg.conf, then do
init 5 to start X.

 3. The screen update problem I mentioned seems to be intermittent,
sometimes I see it, sometimes not, and its also possible it only affects
the emulated vga console (vga=0 with linux guests.)  Sometimes when I see
it there are also partwise screen updates, like I see only some of the
lines scrolling.  Whenever it happens, moving the mouse over another
window fixes it for a few seconds, until it happens again.  Oh and the
guest keeps running all the time, only the screen doesn't update correctly
when it happens...

 4. There's one good news: completion in the monitor is back to working
order! :)  (I suspect because of the qemu_strdup fix.)

 Thanx,
	Juergen
From bugmaster at FreeBSD.org  Mon Sep 22 11:06:51 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep 22 11:07:07 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200809221106.m8MB6pFU015333@freefall.freebsd.org>

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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
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/29698   emulation  [linux] [patch] linux ipcs doesn'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

12 problems total.

From anthony at codemonkey.ws  Mon Sep 22 15:59:55 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Mon Sep 22 16:00:00 2008
Subject: [Qemu-devel] qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
 screen updates...
In-Reply-To: <20080921204025.GA81055@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
Message-ID: <48D7BA2F.0@codemonkey.ws>

Juergen Lock wrote:
> Hi!
>
>  I've been playing with qemu svn on FreeBSD again (new experimental
> emulators/qemu-devel port update here:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
> ), and want to note a few things:
>   

Are all of these things regressions and if so, have you bisected?

Regards,

Anthony Liguori

>  1. usb is still absymally slow, especially emulated disks (disk:imagefile)
> and nics, both read/receive at about 30 KBytes/s here.  Is anyone working
> on this?  I also got a report that its slow on Linux hosts too, so this
> problem doesn't appear to be FreeBSD specific...
>
>  2. -vmwarevga _seems_ to be less broken when run with 16 bpp, only 24
> bpp seems to get the fifo errors that I posted about last time:
> 	http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00893.html
> (maybe also the patch I posted there is only needed when running the guest
> with 24 bpp.)  vmmouse seems to be broken too tho, the guest acts as if
> the mouse is stuck in the bottom right corner.  (maybe I didn't actually
> test this the last time, or it has something to do with the newer guest
> that I used this time which also has a newer xorg version among other
> things,
> 	sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso
> announcement including mirror list is here:
> 	http://sidux.com/Article450.html
> )  The guest xorg crashes with -kernel-kqemu also still happen.
>
>  Oh and that guest tries to use vmmouse by default if run with
> -vmwarevga, to disable it you can boot to runlevel 3 (add a 3 to the
> grub line), su, change vmmouse to mouse in /etc/X11/xorg.conf, then do
> init 5 to start X.
>
>  3. The screen update problem I mentioned seems to be intermittent,
> sometimes I see it, sometimes not, and its also possible it only affects
> the emulated vga console (vga=0 with linux guests.)  Sometimes when I see
> it there are also partwise screen updates, like I see only some of the
> lines scrolling.  Whenever it happens, moving the mouse over another
> window fixes it for a few seconds, until it happens again.  Oh and the
> guest keeps running all the time, only the screen doesn't update correctly
> when it happens...
>
>  4. There's one good news: completion in the monitor is back to working
> order! :)  (I suspect because of the qemu_strdup fix.)
>
>  Thanx,
> 	Juergen
>
>
>   

From dfilter at FreeBSD.ORG  Mon Sep 22 20:30:04 2008
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Mon Sep 22 20:30:05 2008
Subject: kern/117010: commit references a PR
Message-ID: <200809222030.m8MKU3ot013049@freefall.freebsd.org>

The following reply was made to PR kern/117010; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/117010: commit references a PR
Date: Mon, 22 Sep 2008 20:20:10 +0000 (UTC)

 rdivacky    2008-09-22 20:19:54 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_7)
     sys/compat/linux     linux_file.c 
   Log:
   SVN rev 183278 on 2008-09-22 20:19:54Z by rdivacky
   
   Merge r182892 from head to stable/7, I had to manually
   change the code to include "thread" argument to the vn_lock()
   which got removed in HEAD:
   
           Getdents requires padding with 2 bytes instead of 1 byte
           as with getdents64. The last byte is used for storing
           the d_type, add this to plain getdents case where it was
           missing before. Also change the code to use strlcpy instead
           of plain strcpy. This changes fix the getdents crash we
           had reports about (hl2 server etc.)
   
           PR:             kern/117010
           MFC after:      1 week
           Submitted by:   Dmitry Chagin (dchagin@)
           Tested by:      MITA Yoshio <mita ee.t.u-tokyo.ac jp>
           Approved by:    kib (mentor)
           Approved by:    re (kensmith)
   
   Revision   Changes    Path
   1.105.2.3  +54 -33    src/sys/compat/linux/linux_file.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
From datahead4 at gmail.com  Tue Sep 23 14:05:44 2008
From: datahead4 at gmail.com (Matt)
Date: Tue Sep 23 14:05:47 2008
Subject: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates...
In-Reply-To: <20080921204025.GA81055@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
Message-ID: <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>

On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> Hi!
>
>  I've been playing with qemu svn on FreeBSD again (new experimental
> emulators/qemu-devel port update here:
>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
> ), and want to note a few things:

Hi.  I've built an updated port with your patch and it compiles fine
and runs my WinXP guests well.  But, the qemu process consumes 100% of
one CPU core on the host the whole time it is running, regardless of
what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
guests run with bridged networking and full kernel kqemu accel
enabled.

Thank you for the continued work on this port!

Matt
From eitanadlerlist at gmail.com  Wed Sep 24 02:32:32 2008
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Wed Sep 24 02:32:35 2008
Subject: Linux GTK+ 2.10+
Message-ID: <48D9A3CC.50905@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does anyone know when the linux-gtk2 port will support version 2.10 or
above?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkjZo8wACgkQtl8kq+nCzNEvDACdHy/9PM7TDh34q7zjNomenwEI
pvgAnAg6OsS9flRcU806ScdFdbLVZa46
=YDhd
-----END PGP SIGNATURE-----

From Alexander at Leidinger.net  Wed Sep 24 05:58:34 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Wed Sep 24 05:58:39 2008
Subject: Linux GTK+ 2.10+
In-Reply-To: <48D9A3CC.50905@gmail.com>
References: <48D9A3CC.50905@gmail.com>
Message-ID: <20080924075822.19786d2gvegqgxcs@webmail.leidinger.net>

Quoting "Eitan Adler" <eitanadlerlist@gmail.com> (from Tue, 23 Sep  
2008 22:19:56 -0400):

> Does anyone know when the linux-gtk2 port will support version 2.10 or
> above?

Find a good linux gtk2 RPM which works on Fedora 4, and we can update  
it. If you don't find one, you have to wait until we have the new  
linux infrastructure (Fedora 6, 7 or 8) fully integrated into the  
ports (this requires that you run a FreeBSD release which supports  
enough of the linux 2.6 kernel).

Bye,
Alexander.

-- 
A psychiatrist is a fellow who asks you a lot of expensive questions
your wife asks you for nothing.
		-- Joey Adams

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From nox at jelal.kn-bremen.de  Wed Sep 24 21:55:07 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Wed Sep 24 21:55:14 2008
Subject: [Qemu-devel] qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
 screen updates...
In-Reply-To: <48D7BA2F.0@codemonkey.ws>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
Message-ID: <200809242152.m8OLqkWs020541@saturn.kn-bremen.de>

In article <48D7BA2F.0@codemonkey.ws> you write:
>Juergen Lock wrote:
>> Hi!
>>
>>  I've been playing with qemu svn on FreeBSD again (new experimental
>> emulators/qemu-devel port update here:
>> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
>> ), and want to note a few things:
>>   
>
>Are all of these things regressions and if so, have you bisected?

The screen update thing probably is (at least I don't remember seeing it
before), slow usb certainly, -vmwarevga I'm not so sure.  The slow usb
I've now found starts with r5050, before (r5049 and earlier) I get ~500 KB/s
with emulated disk: and net: and ~1 MB/s host: (a cardreader) in this guest,
and with r5050 and after 30-40 KB/s with disk: and net: and ~230 KB/s from
the cardreader (actually with r5050 I only got disk: working, this was
fixed in r5070.)  I also since found out that not all guests are affected,
a FreeBSD 7.1-BETA-i386-livefs.iso gets normal throughput with the current
code, actually even more that the Linux guests before r5050 (about 2 MB/s
from disk: and 1.4 MB/s from the cardreader, net: didnt get packets thru
at least with the default settings, looks like it doesn't get detected
properly:

..
cdce0: <QEMU RNDIS/QEMU USB Network Device, class 2/0, rev 2.00/0.00, addr 2> on uhub0
cdce0: could not find data bulk in
device_attach: cdce0 attach returned 6
cdce0: <QEMU RNDIS/QEMU USB Network Device, class 2/0, rev 2.00/0.00, addr 2> on uhub0
cdce0: faking MAC address
cdce0: WARNING: using obsoleted IFF_NEEDSGIANT flag
cdce0: bpf attached
cdce0: Ethernet address: 2a:00:00:00:00:00

 I also found another problem with usb: looks like when usb_add adds a
device as Device 0.0, Linux guests don't detect it, so sometimes while
testing I had to add devices multiple times.

 And, I found an issue with the new compatfd code on FreeBSD 6.3, looks
like the default threading libs on there (libkse) cause signals to be
delivered to the wrong thread at least when running with kqemu, forcing
libthr to be used instead (the new threading lib) seemed to fix that issue.

 More later...
	Juergen

>>  1. usb is still absymally slow, especially emulated disks (disk:imagefile)
>> and nics, both read/receive at about 30 KBytes/s here.  Is anyone working
>> on this?  I also got a report that its slow on Linux hosts too, so this
>> problem doesn't appear to be FreeBSD specific...
>>
>>  2. -vmwarevga _seems_ to be less broken when run with 16 bpp, only 24
>> bpp seems to get the fifo errors that I posted about last time:
>> 	http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00893.html
>> (maybe also the patch I posted there is only needed when running the guest
>> with 24 bpp.)  vmmouse seems to be broken too tho, the guest acts as if
>> the mouse is stuck in the bottom right corner.  (maybe I didn't actually
>> test this the last time, or it has something to do with the newer guest
>> that I used this time which also has a newer xorg version among other
>> things,
>> 	sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso
>> announcement including mirror list is here:
>> 	http://sidux.com/Article450.html
>> )  The guest xorg crashes with -kernel-kqemu also still happen.
>>
>>  Oh and that guest tries to use vmmouse by default if run with
>> -vmwarevga, to disable it you can boot to runlevel 3 (add a 3 to the
>> grub line), su, change vmmouse to mouse in /etc/X11/xorg.conf, then do
>> init 5 to start X.
>>
>>  3. The screen update problem I mentioned seems to be intermittent,
>> sometimes I see it, sometimes not, and its also possible it only affects
>> the emulated vga console (vga=0 with linux guests.)  Sometimes when I see
>> it there are also partwise screen updates, like I see only some of the
>> lines scrolling.  Whenever it happens, moving the mouse over another
>> window fixes it for a few seconds, until it happens again.  Oh and the
>> guest keeps running all the time, only the screen doesn't update correctly
>> when it happens...
>>
>>  4. There's one good news: completion in the monitor is back to working
>> order! :)  (I suspect because of the qemu_strdup fix.)
>>
>>  Thanx,
>> 	Juergen
From nox at jelal.kn-bremen.de  Wed Sep 24 22:13:17 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Wed Sep 24 22:13:23 2008
Subject: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates... (now updated to r5313)
In-Reply-To: <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
Message-ID: <200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>

In article <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com> you write:
>On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>> Hi!
>>
>>  I've been playing with qemu svn on FreeBSD again (new experimental
>> emulators/qemu-devel port update here:
>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
>> ), and want to note a few things:
>
>Hi.  I've built an updated port with your patch and it compiles fine
>and runs my WinXP guests well.  But, the qemu process consumes 100% of
>one CPU core on the host the whole time it is running, regardless of
>what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
>guests run with bridged networking and full kernel kqemu accel
>enabled.
>
Hmm.  And you didn't see this with the version in ports?  Have you
checked if this is related to kqemu? (try without -kernel-kqemu and
also with -no-kqemu.)  Also, which threading libs and scheduler are you
using?  There seems to be an issue with kse, tho I doubt you are using
that on 7-stable...

 Here is another experimental update that forces -lthr on 6.x, and
also updates to qemu svn r5313:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch

>Thank you for the continued work on this port!

 You're welcome! :)
	Juergen
From datahead4 at gmail.com  Thu Sep 25 02:54:41 2008
From: datahead4 at gmail.com (Matt)
Date: Thu Sep 25 02:54:47 2008
Subject: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates... (now updated to r5313)
In-Reply-To: <200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
Message-ID: <cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>

On Wed, Sep 24, 2008 at 5:10 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>
> In article <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com> you write:
> >On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> >> Hi!
> >>
> >>  I've been playing with qemu svn on FreeBSD again (new experimental
> >> emulators/qemu-devel port update here:
> >>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
> >> ), and want to note a few things:
> >
> >Hi.  I've built an updated port with your patch and it compiles fine
> >and runs my WinXP guests well.  But, the qemu process consumes 100% of
> >one CPU core on the host the whole time it is running, regardless of
> >what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
> >guests run with bridged networking and full kernel kqemu accel
> >enabled.
> >
> Hmm.  And you didn't see this with the version in ports?  Have you
> checked if this is related to kqemu? (try without -kernel-kqemu and
> also with -no-kqemu.)  Also, which threading libs and scheduler are you
> using?  There seems to be an issue with kse, tho I doubt you are using
> that on 7-stable...

It does appear that this continual CPU-usage was kqemu-related.  When
booting the guest with the "-no-kqemu" option, the CPU usage on the
host was as expected and tracked with the usage in the guest.  Any
level (user or user + kernel) of kqemu accel seemed to trigger the
host to consume 100% CPU regardless of guest activity.

I use the ULE scheduler and libthr threading library.  See console output below.

]$ sysctl kern.sched.name
kern.sched.name: ULE

$ ldd /usr/local/bin/qemu
/usr/local/bin/qemu:
        libm.so.5 => /lib/libm.so.5 (0x101ad000)
        libz.so.4 => /lib/libz.so.4 (0x101c2000)
        libgnutls.so.26 => /usr/local/lib/libgnutls.so.26 (0x101d4000)
        libpcap.so.5 => /lib/libpcap.so.5 (0x1027b000)
        libutil.so.7 => /lib/libutil.so.7 (0x102a2000)
        libSDL-1.2.so.11 => /usr/local/lib/libSDL-1.2.so.11 (0x102b0000)
        libncurses.so.7 => /lib/libncurses.so.7 (0x10319000)
        libthr.so.3 => /lib/libthr.so.3 (0x10361000)
        libc.so.7 => /lib/libc.so.7 (0x10374000)
        libgcrypt.so.15 => /usr/local/lib/libgcrypt.so.15 (0x10473000)
        libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x104db000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x104df000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x104e8000)
        libvgl.so.5 => /usr/lib/libvgl.so.5 (0x105de000)
        libaa.so.1 => /usr/local/lib/libaa.so.1 (0x105e6000)
        libusbhid.so.3 => /usr/lib/libusbhid.so.3 (0x105fd000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x10601000)
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x106ed000)
        libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x106f0000)
        librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x106f5000)
>
>  Here is another experimental update that forces -lthr on 6.x, and
> also updates to qemu svn r5313:
>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch

I just built this update and it seems to have fixed the issue.  Host
CPU usage again tracks with guest CPU usage and all seems well.  I'll
continue to use this build to see if anything else crops up.

Please let me know if there is anything other information I can provide.

Thanks again,
Matt
>
> >Thank you for the continued work on this port!
>
>  You're welcome! :)
>        Juergen
From Alexander at Leidinger.net  Thu Sep 25 14:05:54 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Thu Sep 25 14:06:09 2008
Subject: x11-themes/linux-hicolor-icon-theme fails to install if
	sysutils/linux-nero
In-Reply-To: <18643.47349.732101.661496@gromit.timing.com>
References: <20080919102216.389c930f@it.buh.tecnik93.com>
	<18643.47349.732101.661496@gromit.timing.com>
Message-ID: <20080925160542.20491qt1r1197pog@webmail.leidinger.net>

Quoting "John Hein" <jhein@timing.com> (from Fri, 19 Sep 2008 08:36:37 -0600):

>  > While I'm not sure this is the right fix, making sysutils/linux-nero's
>  > RUN_DEPEND on x11-themes/linux-hicolor-icon-theme will fix this.
>
> Won't that cause the linux-nero port to install it's icon files into
> /usr/local/share/icons (through the sym link), but leave the plist
> relative to LINUXBASE?
>
> The problem is that linux-hicolor-icon-theme assumes it owns
> everything under share/icons/hicolor.

I would expect this behavior. The question is if this is bad or not. I  
don't doubt that it is not clean from the style point of view, but I  
would expect that the files are correctly removed on deinstall of nero.

> Has anyone ever considered using unionfs for /compat/linux/usr/share?
>
> One problem I can see is that 'share' is not the only directory
> that should be shared.  etc?

It is not shared via the symlink directly, it's shared by the nature  
of the linuxulator to fall through to the FreeBSD path if the  
/compat/linux/ one is not there. So there's already some sort of  
unionfs there, just not with the complete unionfs semantics.

> I'm not sure unionfs is up to the job, but I'm wondering if any has
> considered it or even tried it.

I haven't. I'm not aware of anyone who has.

Bye,
Alexander.

-- 
No woman can call herself free until she can choose consciously whether
she will or will not be a mother.
		-- Margaret H. Sanger

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From Jahanshah_Rashidian at gmx.de  Thu Sep 25 17:25:14 2008
From: Jahanshah_Rashidian at gmx.de (Jahanshah Rashidian)
Date: Thu Sep 25 17:25:49 2008
Subject: The Walls of Auschwitz
Message-ID: <20080925171012.JQIM17328.hrndva-omta05.mail.rr.com@2ao1z>

The Walls of Auschwitz
A Review of the Chemical Studies by Nicholas Kollerstrom, PhD

In his essay, Dr Nicholas Kollerstrom argues that the alleged massacre of Jewish people by gassing during World War II was scientifically impossible.

The distinguished academic was dismissed on April 22, 2008 without any explanation and a Holocaust conference held on 16-18 May in Berlin refused his article and warned that he would be arrested if he attended the conference and presented his essay.

The West punishes people for their scientific research on Holocaust but the same western countries allow insults to prophets and religious beliefs…


I. The Leuchter Report, 1988

In February 1988, Fred Leuchter came to the Auschwitz crematoria ruins, with his wife and a team, and took 32 samples chiseled out of the wall. His Report published in April of 1998 contained five maps as appendices which indicated where the samples had been taken from, and in addition a film was made of his sampling'. The locations are important, because some of the 'gas chamber' locations are postwar-reconstructed, and the obtaining of original brickwork was essential for his purpose.

Leuchter in effect tested the hypothesis, as to whether or not certain large rooms, designated in the Auschwitz design-plans as either morgues or washrooms, had in fact been used for large-scale human cyanide gassing on a daily and lethal basis. As America's only professional cyanide-gas execution expert, Leuchter was primarily concerned with whether it would have been feasible to perform such executions using the designated rooms; this however will not concern us here, our concern being solely with the wall samples he took. These were analyzed in March 1988 by Alpha Analytical Laboratories Ltd, in ignorance of their source.

He managed to take one one sample of a 'Disinfestation Chamber,' by breaking and entering a locked building: but prowling guards and snowy blizzards prevented further sampling from a second such chamber at camp Majdanek . His swiftly-published 'Report' in effect grouped his data into two, that of the sample 32 which he called perhaps unfortunately his 'control,' and all the others, as the graph shows. The latter came from five 'Crematoria' sites in the Auschwitz complex.

Duality of the 'Gas Chamber' concept in Leuchter's Report

The terms that will here be used, that are as far as possible non-judgmental, are AHGCs or alleged human gas chambers for what Leuchter called 'Crematoria' and DCs or disinfestation chambers for what in the German design-plans were called 'gas chambers' (gaskammers). The latter had been used in Germany since 1924, much as we would ?nowadays use DDT, for killing the flea that carried the typhus bacillus.

They were operated using 'Zyklon-B' granules, composed of liquid hydrogen cyanide (boiling-point 27° C) that would evaporate over a couple of hours from its clay substrate. In the German labor-camps, clothing and bedding were repeatedly fumigated in such chambers. Prior to Leuchter's work, pro - Holocaust books had not acknowledged such chambers, and had rather carried the message of the Nuremberg trials, whereby any use of Zyklon-B was merely presumed to have been for human extermination.

After Leuchter, Pressac's magnum opus reproducing design-plans of Auschwitz-Birkenau located and described the 'Gaskammer' or DCs . These were quite a lot smaller than the AHGCs, and designed by the industrial-chemistry firm 'Degesh.' Pressac also observed that their walls tended to be blue: they had gradually developed that hue after the War, owing to their saturation with iron-cyanide.

Fred Leuchter found one thousand -fold difference in residual cyanide levels between these two types of 'gas chamber' - that designated in German design-plans as gas chambers but whose existence was ignored at Nuremberg, and the much larger rooms alleged to have functioned as gas chambers. Together with Pressac's acknowledgement of the DCs, this meant that all future pro-Holocaust books had to work with a duality: that the very same cans of ' Zyklon-B' were used for two extremely different purposes on the same campsite: for taking lives via the extermination procedure, whereby millions died, in the extraordinary manner described at Nuremberg, and also for saving them by combating the typhus epidemic.
This did not make a great deal of sense and some noted that one could more readily have not bothered and just let the typhus epidemic do its work.

There was controversy over the extent to which all of Leuchter's samples had indeed been taken from walls of chambers allegedly exposed to the cyanide, given that much of the 'gas chambers' are now acknowledged to be postwar-reconstructed; as likewise there was disagreement over the extent to which exposed walls may have had any cyanide leeched out from them over six decades, a theme we return later on with the work of Mr Dan Desjardins.

The iron-cyanide bonding which takes place once the HCN has entered the brick and mortar of the walls, is permanent: the complex ferric ferrocyanide otherwise known as "Iron Berlinate" or "Prussian Blue" is, according to The Merck Index, " ... practically insoluble in water." It is used as a pigment in printing inks and artists' colors, and remains stable in water, air, ultraviolet radiation and with the elevated temperatures of summer.

Following Leuchter's discovery, some suggested that the DCs had been more heavily used than the AHGCs, after all did not beetles or fleas take longer to kill than humans? And, were not the DCs heated in order to promote the release of the HCN, and would that not give a higher degree of wall-absorption? Others replied that, if half a million people had allegedly been gassed in 'Krema I' over a two-year or so period then that would have been a rather intensive use, and not easily reconcilable with Alpha Analytical Laboratory's finding that all seven wall-samples taken therefrom had total cyanide too low to be measurable. Should not all the moisture from the body sweat have rather promoted HCN absorption?

Others had a different criticism, that the cyanide gas would have only been adsorbed onto the wall surface, and that the concentrations found would to a large extent merely reflect the extent to which surface material of the wall had been scraped off, while deeper samples would hardly contain any. We leave these questions for now and review the two further chemical investigations, performed in the wake of Leuchter.

II. The Rudolf Report, 1993

…fortunately it is precisely the one 'gas chamber' in which the largest number of people was allegedly killed by poison gas during the Third Reich which has remained almost entirely intact: morgue 1 of crematorium II' Germar Rudolf

Germar Rudolf found that the Leuchter Report 'embedded the thorn of doubt in my heart' while he was a PhD chemist at the prestigious Max Plank Institute. In 1991 he visited Auschwitz and took 24 samples, analyzed by the Fresenius Institute using a comparable procedure. He was later criticized for having used the Max Plank Institute notepaper for having asked them to do this, without explaining where they had been taken from. Both Leuchter and Rudolf used their professional position to request the chemical analysis, and both had their professional existence terminated by that act.

Although Rudolf's sample-taking was photographed, he was criticized for not having had enough by way of witnesses checking his sample-taking and how the containers were labeled for his thirty-odd samples. Both Leuchter and Rudolf took their samples without having obtained permission - which assuredly would not have been given, had they asked. The samples were boiled for an hour with hydrochloric acid to drive out the cyanide gas, collected by absorption with caustic potash, then assayed photometrically.

?The method gave cyanide levels down to 0.1 - 0.2 ppm in the mortar, obtaining measurable values for almost all of his samples, despite which Rudolf remained doubtful over the value and reproducibility of results below several parts per million
He sampled extensively both from the inside and outside of the blue-stained DCs at Birkenau, where his grouped results were:

Table 1: Mean Cyanide DC Birkenau wall-sample values, Germar Rudolf data, 1991
De-lousing room, inside: 5830 ± 3700 ppm (n=l0)
outside: 3010 ± 3600 ppm (n=5)

This indicates that the cyanide gas was able to penetrate right through the brick walls, and would not merely have been adsorbed onto the surface; and suggests that weathering over half a century has not greatly affected the cyanide concentrations. This data has a central importance, because Leuchter had only managed to take one single sample of de-lousing chamber wall.

The 'Control' samples of Germar Rudolf

Rudolf only took three samples from the AHGC walls (from what is called the Krema-II morgue), which was the weakness of his survey. Their wide divergences (7.2, 0.6 and 6.7 ppm) give little idea of this key parameter!". He took more samples from 'controls' - i.e., rooms where no-one had alleged that systematic cyanide gassing had taken place. His 'control' group is here subdivided into samples taken from the mortar between the bricks, and the rest.

Table 2: As before, sampling AHGC walls vs 'controls'
AHGC walls 4.8 ± 3 ppm (n=3) His samples 1-3 of Table 19.
Controls, plaster: 1.1± 1.3 ppm (n=6) His samples 4,5,7,8, 10,23.
Controls, mortar: 0.2± 0.1 (n=3) Samples 6,21,24

This indicates a significant elevation of residual cyanide in the AHGCs.

The Ball Report 1993

It is hard to obtain copies of this Report, or to gain details of where the chemical analysis was performed'". J.C. Ball has a degree in geology, and worked as a mineral exploration geologist. Given the intensity of criticism to which anyone publishing in this area is exposed, one should perhaps refrain from criticism on this matter. Its six samples were:

Table 3: Mean values of the cyanide measurements found by John Ball, 1993
>From a DC 3000 ppm (n=2)


11.The Rudolf Report, 8.3.3, Table 19; also Table 3 in 'Dissecting the Holocaust' Chapter by GR.
12. Dissecting the Holocaust 2003 http://vho.orglGB/Books/dth/fndgcger.html Table 3 ofRudolfCh.
13. For his difficulties here, see: www.ihr.orglleaflets/inside.shtml
14. Table 19, p254 of The Rudolf Report 2001.
15. John Clive Ball, The Ball Report, Ball Resource Services Ltd., Canada 1993; The Rudolf Report, p.268.
?
>From AHGC sites 0.5 ± 0.6 (n=4) ppm

III. The Markiewicz et. al. Polish Study of 1994

The manager of Auschwitz Mr Piper approached Dr Jan Markiewicz of the Jan Sehn Institute of Forensic Research at Cracow as to whether they would check over the residual cyanide levels, in the wake of the Leuchter Report. On 20 Feb 1990 Dr. Wojciech Gubala arrived and removed 22 samples, including two control samples. The team then decided that they would like to follow this up with a further study before publishing any results.

This survey, published in 1994, differed from those of Leuchter and Rudolf in that it only looked at soluble cyanide in the brickwork. Critics objected that it was precisely the soluble component of cyanide which one would not expect to provide a memory of the past, because it would clearly be affected by weathering. Their reason for using such a method, was apparently that they did not want to get involved in debates over Prussian Blue formation: their approach 'excludes the possibility of the decomposition of the relatively permanent Prussian blue, whose origin is unclear in many parts of the structures under investigation,' and therefore 'The real level of total cyanide compounds could therefore be higher than shown by our analysis.' The samples were put in 10% sulphuric acid for 24 hours, thereby driving off the cyanide as before, except that cyanide bonded to iron was not liberated by the Polish method - the point of which has not been clear to a lot of people.

The soluble or non-bonded cyanide thereby measured was only present in low concentrations measured in parts per billion rather than parts per million. How were they able to attain this accuracy in measurement unattainable either by Alpha Analytical laboratories or the Fesenius Institute? The method they referenced for this analysis had been published in 1947, and could one expect this to attain these much higher levels of accuracy? From three 'gas chambers' they found:

Table IV: Polish data, Mean levels of soluble cyanide in Crematoria walls. 1994 AHGC walls, Krema I: 0.07 ± 0.1 ppm (n=7)
KremaII: 0.16 ± 0.2 ppm (n=7)
Krema III: 0.03 ± 0.02 ppm (n=7)

These samples averaged 90 parts per billion. The Polish group claimed that their method could measure down to 2-3 parts per billion. For their 'control' they took eight samples from three different residential blocks, and thereby obtained (or at least published) consistently zero values - i.e., zero parts per billion! How impressive to have discovered this ultra-sensitive method. As 'holocaust' chemist Dr Richard Green explained, 'The IFFR used a much more sensitive method. Their sensitivity was 3-4/!g/kg, i.e., 300 times more sensitive.' If that method published in 1947 had such astounding accuracy, then why did subsequent chemists fail to use it?

This investigation gave DC wall-concentrations in its Table 4, finding a several-fold elevation in cyanide levels there. Eight values for 'concentrations of cyanide ions in samples collected in the facilities for the fumigation of prisoners clothes, (Birkenau BathHouse Camp BI-A)' gave a mean value of273 ppb, thrice that of the 'Kremas.' Their conclusion omitted comment upon this highly significant elevation.

This paper has been much cited by pro-Holocaust sources, as refuting the Leuchter Report, by demonstrating that the AHGCs ('Kremas') had raised cyanide as compared to 'controls.' The paper was entitled, 'A study of the cyanide compound contents in the walls of the gas chambers in the former Auschwitz and Birkenau concentration camps'.

It thus used a Nuremberg-type terminology, where 'gas chamber' simply meant a place for human extermination. They could hardly have done otherwise, because doubt over 'the Holocaust' is a crime in Poland. The DCs were alluded to as 'Facilities For the Fumigation of Prisoners' Clothes.'

The Polish team went to a lot of trouble, with some sixty measurements mostly measured thrice, and was the only study which obtained permission to take the samples. It omitted two things in its conclusions: any allusion to the Birkenau DC ('facilities for the fumigation of prisoners' clothes') where it had found greatly-elevated cyanide levels over the AHGCs; and, the insoluble cyanide that was bound to iron. In regard to both of these it cited the Prussian blue ferric ferrocyanide complex, leaving open the possibility that is had some quite extraneous source and was therefore to be avoided.

The 1947 method used by Markiewicz et. al. was given by Joseph Epstein and published in a US chemistry journal." It was a procedure whose limit of accuracy was given as 0.2 micrograms per ml. To expel the cyanide from brickwork and then dissolve it into a solution suitable for measuring it, involves an order-of-magnitude dilution at least, so that one would not expect to obtain an accuracy less then one ppm in the brickwork, using this method. Any claim that this decades-old titration and colorimetric method using thiocyanate can find parts per billion has to be spurious.

IV. Desjardin analyses Leuchter

Dan Desjardins, after carefully retracing the steps of Leuchter on a 1996 visit to Auschwitz'", and watching the film that had been made of Leuchter's sampling'", divided the samples 1-31 into two groups: those which had been exposed and open to the elements over the decades (n=20), and those which were more protected in sheltered, unexposed locations: 'Leuchter's samples, numbered 25 through 31, extracted from Crematorium I... taken from a facility which was not destroyed and has remained intact since the end of the war, were not exposed to the elements. The same might be said for samples 4, 5 and 6 taken from Crematorium II. Leuchter removed these samples from a pillar, wall and ceiling which, though accessible, were nevertheless well protected against wind, rain and sun.'

Less then half (14 out of 35) of Leuchter's samples had measurable levels of cyanide in them, where measurable means above one part per million. We have here assigned an arbitrary value of 0.5 ppm for those too low to measure, i.e below 1 ppm. This gave:

Table 5: Desjardins grouping of the Leuchter data as 'sheltered' or 'exposed' (2007) Sheltered (n=l0) 1.88 ± 2.2 ppm
Exposed (n=20) 1.31 ± 1.56 ppm

The 'exposed' group scored 30% lower than the sheltered group, a result which lacks statistical significance (t=0.8). This data could suggest that one-third of the cyanide had leeched out from the exposed walls, over sixty years; if indeed they had all at one historic period been exposed to hydrogen cyanide.

Mr Desjardins further subdivided the Leuchter samples into those taken from AHGC walls, and those which were 'controls' i.e taken from barracks, etc. The definition of the 'control' concept is critical here, and means brickwork where no one has been concerned to allege that is was part of a room where systematic cyanide gassing took place whether of humans or of mattresses.

Leuchter surmised that the 'control' sample had been exposed at some stage to a single fumigation by cyanide gas, by way of cleaning out any lice from cracks etc.

Table 6: Desjardins groups Leuchter's data by AHGC versus 'controls'
AHGCs (n=19) 1.63 ± 2.1 ppm
Controls (n=9) 1.45 ± 1.2 ppm


This result too lacks statistical significance, i.e. Leuchter's sample provides no evidence for human 'gas chambers' having raised residual cyanide levels above those of 'controls.' The data suggests that the AHGCs did not ever function as lethal gas chambers.

These two sets of data (using Desjardins' divisions) covary somewhat, in that if we increase the 'exposed' samples by say 25%, to allow for leeching out of their cyanide over the decades, then the difference between the AHGC and 'control' groups disappears altogether. (As Mr Desjardins put it, five times as many of these [AHGC] samples came from locations protected from 40-years' exposure to wind and rain.') Mr Desjardins concluded, 'Fred Leuchter's broad sample gathering, despite flaws, establishes a reasonable basis for inferring that the presence of cyanide residue is due to benign rather than homicidal purposes.

Conclusions

1. One might expect that the accuracy of cyanide-ion assay would have increased substantially over the last couple of decades, but this is not the case: any reanalysis of the brickwork would face the same frustrating situation, where differences between AHGCs and controls hover right next to the lowest detectable levels.

2. The essential questions here reviewed may be best evaluated without arguments over whether or not Prussian blue coloration has formed. The latter involves a slow and complex sequence of reactions. We have here been primarily concerned with total cyanide in the brickwork.

3. Plaster on the wall-surface may tend to have a higher cyanide level than brick or mortar underneath it, and the ferric-ferrocyanide does decrease as a function of depth. Samples should therefore aim to have a comparable breadth-to-depth ratio.

4. The notion of a 'control' sample has developed from Rudolf's sampling and also from Mr. Desjardins evaluation of the Leuchter sample locations. This permitted an evaluation of whether measurements of authentic AHGC wall were significantly elevated over such. While there was a hint of this from Rudolf's sampling, and while further investigation might confirm this, overall no statistically significant elevation was evident.

5. The careful and extensive Polish data was analyzed using a 1947 US titration procedure, which gave no indication of reaching the parts per billion accuracy claimed by that study. If Marciewicz et. al chose to use a method which only analyzed 1 % or less of the cyanide, viz. the soluble component, for whatever reason, they should first have shown that their method was capable of detecting it.

6. Both the Leuchter and Rudolf surveys obtained a three order-of-magnitude differential between the walls of DC and AHGC buildings; the simplest explanation of which is that the former was used on a regular basis for cyanide fumigation while the latter was not.

7. The Leuchter data showed that there was no great diminution of cyanide levels due to weathering over half a century, and this accords with what is known about the insolubility and permanence of the ferric-ferrocyanide complex. The residual cyanide within those walls may therefore offer the most reliable memory which the human race now has, concerning what happened historically in German 'gas chambers.'

Source:

 http://www.presstv.com/Detail.aspx?id=56287&sectionid=3510303

------------------------------------------------------------------------------

To unsubscribe from our mailing list, please send an email to Jahanshah_Rashidian@gmx.de

Jahanshah Rashidian
From nox at jelal.kn-bremen.de  Thu Sep 25 20:26:07 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Thu Sep 25 20:26:13 2008
Subject: [PATCH] preprocessor issue in qemu/patch-block-raw-posix.c (was:
	qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates...
	(now updated to r5313))
In-Reply-To: <200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
Message-ID: <20080925201703.GA12142@saturn.kn-bremen.de>

On Thu, Sep 25, 2008 at 12:10:39AM +0200, Juergen Lock wrote:
> In article <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com> you write:
> >On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> >> Hi!
> >>
> >>  I've been playing with qemu svn on FreeBSD again (new experimental
> >> emulators/qemu-devel port update here:
> >>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
> >> ), and want to note a few things:
> >
> >Hi.  I've built an updated port with your patch and it compiles fine
> >and runs my WinXP guests well.  But, the qemu process consumes 100% of
> >one CPU core on the host the whole time it is running, regardless of
> >what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
> >guests run with bridged networking and full kernel kqemu accel
> >enabled.
> >
> Hmm.  And you didn't see this with the version in ports?  Have you
> checked if this is related to kqemu? (try without -kernel-kqemu and
> also with -no-kqemu.)  Also, which threading libs and scheduler are you
> using?  There seems to be an issue with kse, tho I doubt you are using
> that on 7-stable...
> 
>  Here is another experimental update that forces -lthr on 6.x, and
> also updates to qemu svn r5313:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch

I forgot to note that this also needed the following patch:

Index: qemu/block-raw-posix.c
@@ -545,7 +545,8 @@
 
     qemu_aio_set_fd_handler(s->fd, posix_aio_read, NULL, posix_aio_flush, s);
 
-#if defined(__linux__) && defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 4)
+#if defined(__linux__) && defined(__GLIBC_PREREQ)
+#if !__GLIBC_PREREQ(2, 4)
     {
         /* XXX: aio thread exit seems to hang on RedHat 9 and this init
            seems to fix the problem. */
@@ -557,6 +558,7 @@
         aio_init(&ai);
     }
 #endif
+#endif
     posix_aio_state = s;
 
     return 0;

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
From anthony at codemonkey.ws  Thu Sep 25 20:40:59 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Thu Sep 25 20:41:06 2008
Subject: [Qemu-devel] [PATCH] preprocessor issue in
	qemu/patch-block-raw-posix.c
In-Reply-To: <20080925201703.GA12142@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<20080925201703.GA12142@saturn.kn-bremen.de>
Message-ID: <48DBF71E.1000405@codemonkey.ws>

Juergen Lock wrote:
> I forgot to note that this also needed the following patch:
>   

Why?  This #ifdef is working around a very specific bug.

Regards,

Anthony Liguori

> Index: qemu/block-raw-posix.c
> @@ -545,7 +545,8 @@
>  
>      qemu_aio_set_fd_handler(s->fd, posix_aio_read, NULL, posix_aio_flush, s);
>  
> -#if defined(__linux__) && defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 4)
> +#if defined(__linux__) && defined(__GLIBC_PREREQ)
> +#if !__GLIBC_PREREQ(2, 4)
>      {
>          /* XXX: aio thread exit seems to hang on RedHat 9 and this init
>             seems to fix the problem. */
> @@ -557,6 +558,7 @@
>          aio_init(&ai);
>      }
>  #endif
> +#endif
>      posix_aio_state = s;
>  
>      return 0;
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>
>
>   

From rdivacky at freebsd.org  Fri Sep 26 09:27:07 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Fri Sep 26 09:27:26 2008
Subject: Linux GTK+ 2.10+
In-Reply-To: <20080924075822.19786d2gvegqgxcs@webmail.leidinger.net>
References: <48D9A3CC.50905@gmail.com>
	<20080924075822.19786d2gvegqgxcs@webmail.leidinger.net>
Message-ID: <20080926090840.GA4260@freebsd.org>

On Wed, Sep 24, 2008 at 07:58:22AM +0200, Alexander Leidinger wrote:
> Quoting "Eitan Adler" <eitanadlerlist@gmail.com> (from Tue, 23 Sep  
> 2008 22:19:56 -0400):
> 
> >Does anyone know when the linux-gtk2 port will support version 2.10 or
> >above?
> 
> Find a good linux gtk2 RPM which works on Fedora 4, and we can update  
> it. If you don't find one, you have to wait until we have the new  
> linux infrastructure (Fedora 6, 7 or 8) fully integrated into the  
> ports (this requires that you run a FreeBSD release which supports  
> enough of the linux 2.6 kernel).

what is the plan in this area? are we going to switch to newer fedora
on 8.x ?

I'd like to know the official position here :)

roman
From rdivacky at freebsd.org  Fri Sep 26 09:27:07 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Fri Sep 26 09:27:26 2008
Subject: Enemy territory does not run
In-Reply-To: <83e5fb980809200930v5e9c4a33j5fddb72f6d9304ca@mail.gmail.com>
References: <83e5fb980809200930v5e9c4a33j5fddb72f6d9304ca@mail.gmail.com>
Message-ID: <20080926091053.GB4260@freebsd.org>

On Sat, Sep 20, 2008 at 06:30:35PM +0200, Diego Depaoli wrote:
> Launching enemy-territory on my CURRENT I get a segmentation fault and
> that system message:
> linux_sys_futex: unknown op 798242337

this looks really strange... can you provide full ktrace/linux_kdump
output surrounding this?
From anthony at codemonkey.ws  Fri Sep 26 15:05:31 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Fri Sep 26 15:05:37 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
 screen updates... (now updated to r5313)
In-Reply-To: <cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
References: <20080921204025.GA81055@saturn.kn-bremen.de>	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
Message-ID: <48DCF9FC.2070708@codemonkey.ws>

Matt wrote:
>>  Here is another experimental update that forces -lthr on 6.x, and
>> also updates to qemu svn r5313:
>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>     
>
> I just built this update and it seems to have fixed the issue.  Host
> CPU usage again tracks with guest CPU usage and all seems well.  I'll
> continue to use this build to see if anything else crops up.
>
> Please let me know if there is anything other information I can provide.
>   

If ya'll have patches to make QEMU work on FreeBSD, please submit them.  
I'm about to commit a patch that's what it took for me to get SVN 
working on FreeBSD.

The one thing that really tripped me up with the whole aio kld-module 
thing.  Perhaps we should detect the presence of the module at run time 
and disable aio?  I assume kldload can only be run as root?

Regards,

Anthony Liguori

> Thanks again,
> Matt
>   
>>> Thank you for the continued work on this port!
>>>       
>>  You're welcome! :)
>>        Juergen
>>     
>
>
>   

From nox at jelal.kn-bremen.de  Fri Sep 26 21:32:38 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Fri Sep 26 21:32:45 2008
Subject: [Qemu-devel] [PATCH] preprocessor issue in
	qemu/patch-block-raw-posix.c
In-Reply-To: <48DBF71E.1000405@codemonkey.ws>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<20080925201703.GA12142@saturn.kn-bremen.de>
	<48DBF71E.1000405@codemonkey.ws>
Message-ID: <20080926212925.GA10666@saturn.kn-bremen.de>

On Thu, Sep 25, 2008 at 03:39:58PM -0500, Anthony Liguori wrote:
> Juergen Lock wrote:
>> I forgot to note that this also needed the following patch:
>>   
> 
> Why?  This #ifdef is working around a very specific bug.
> 
Well, looks like the preprocessor tries to parse the entire expression
including the undefined `!__GLIBC_PREREQ(2, 4)' before evaluating it:

block-raw-posix.c:548:69: missing binary operator before token "("

so I just put it on an extra line.

> Regards,
> 
> Anthony Liguori
> 
>> Index: qemu/block-raw-posix.c
>> @@ -545,7 +545,8 @@
>>       qemu_aio_set_fd_handler(s->fd, posix_aio_read, NULL, 
>> posix_aio_flush, s);
>>  -#if defined(__linux__) && defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 
>> 4)
>> +#if defined(__linux__) && defined(__GLIBC_PREREQ)
>> +#if !__GLIBC_PREREQ(2, 4)
>>      {
>>          /* XXX: aio thread exit seems to hang on RedHat 9 and this init
>>             seems to fix the problem. */
>> @@ -557,6 +558,7 @@
>>          aio_init(&ai);
>>      }
>>  #endif
>> +#endif
>>      posix_aio_state = s;
>>       return 0;
>> 
>> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>> 
>> 
>>   
> 
From nox at jelal.kn-bremen.de  Fri Sep 26 22:07:20 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Fri Sep 26 22:07:27 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb,
	vmwarevga, screen updates... (now updated to r5313)
In-Reply-To: <48DCF9FC.2070708@codemonkey.ws>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
Message-ID: <20080926220445.GA13099@saturn.kn-bremen.de>

On Fri, Sep 26, 2008 at 10:04:28AM -0500, Anthony Liguori wrote:
> Matt wrote:
>>>  Here is another experimental update that forces -lthr on 6.x, and
>>> also updates to qemu svn r5313:
>>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>>     
>> 
>> I just built this update and it seems to have fixed the issue.  Host
>> CPU usage again tracks with guest CPU usage and all seems well.  I'll
>> continue to use this build to see if anything else crops up.
>> 
>> Please let me know if there is anything other information I can provide.
>>   
> 
> If ya'll have patches to make QEMU work on FreeBSD, please submit them.  
> I'm about to commit a patch that's what it took for me to get SVN working 
> on FreeBSD.
> 
> The one thing that really tripped me up with the whole aio kld-module 
> thing.  Perhaps we should detect the presence of the module at run time and 
> disable aio?  I assume kldload can only be run as root?

Yes.  Atm the ports print a warning when aio is not loaded:

Index: qemu/vl.c
@@ -8409,6 +8409,11 @@
 
     tb_size = 0;
     
+#ifdef __FreeBSD__
+    if (modfind("aio") == -1)
+        fprintf(stderr, "warning: aio not (kld)loaded, may cause `Invalid system call' traps on disk IO\n");
+#endif
+
     optind = 1;
     for(;;) {
         if (optind >= argc)

 And here is another patch thats needed on amd64 hosts for tcg (which
I had posted before:)

Index: qemu/exec.c
@@ -405,6 +405,28 @@
             exit(1);
         }
     }
+#elif defined(__FreeBSD__)
+    {
+        int flags;
+        void *addr = NULL;
+        flags = MAP_PRIVATE | MAP_ANONYMOUS;
+#if defined(__x86_64__)
+        /* FreeBSD doesn't have MAP_32BIT, use MAP_FIXED and assume
+         * 0x40000000 is free */
+        flags |= MAP_FIXED;
+        addr = (void *)0x40000000;
+        /* Cannot map more than that */
+        if (code_gen_buffer_size > (800 * 1024 * 1024))
+            code_gen_buffer_size = (800 * 1024 * 1024);
+#endif
+        code_gen_buffer = mmap(addr, code_gen_buffer_size,
+                               PROT_WRITE | PROT_READ | PROT_EXEC, 
+                               flags, -1, 0);
+        if (code_gen_buffer == MAP_FAILED) {
+            fprintf(stderr, "Could not allocate dynamic translator buffer\n");
+            exit(1);
+        }
+    }
 #else
     code_gen_buffer = qemu_malloc(code_gen_buffer_size);
     if (!code_gen_buffer) {

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

 I'll see if I can prepare another update over the weekend and then go
thru more of the patches that have accumulated in the port...

 Thanx,
	Juergen
From jonathan at kc8onw.net  Sat Sep 27 14:04:16 2008
From: jonathan at kc8onw.net (Jonathan)
Date: Sat Sep 27 14:04:47 2008
Subject: Virtualbox  2.0.2 and FreeBSD 7 x64 guest install crashes
Message-ID: <48DE3D43.8060606@kc8onw.net>

Has anyone had any success with Virtualbox  2.0.2 and a FreeBSD 7 x64
guest?  I've tried pretty much every available option combination but it
consistently crashes on boot right after the loader prompt.  The md5 for
the ISO is correct.

I'm definitely willing to put some time towards debugging it but I'm not
sure where to start.  The Virtualbox IRC dev channel told me to ask the
FreeBSD project but since Virtualbox itself crashes I would think I
would have to start on their side...  I'd like to start somewhere.  It
would be great to have a 32 bit and a 64 bit VM for testing purposes.

Thanks,
Jonathan Stewart

P.S. Any word on FreeBSD as a Virtualbox host?
From anthony at codemonkey.ws  Sat Sep 27 15:28:46 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Sat Sep 27 15:28:53 2008
Subject: [Qemu-devel] [PATCH] preprocessor issue in
	qemu/patch-block-raw-posix.c
In-Reply-To: <20080926212925.GA10666@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<20080925201703.GA12142@saturn.kn-bremen.de>
	<48DBF71E.1000405@codemonkey.ws>
	<20080926212925.GA10666@saturn.kn-bremen.de>
Message-ID: <48DE50EC.4090003@codemonkey.ws>

Juergen Lock wrote:
> On Thu, Sep 25, 2008 at 03:39:58PM -0500, Anthony Liguori wrote:
>   
>> Juergen Lock wrote:
>>     
>>> I forgot to note that this also needed the following patch:
>>>   
>>>       
>> Why?  This #ifdef is working around a very specific bug.
>>
>>     
> Well, looks like the preprocessor tries to parse the entire expression
> including the undefined `!__GLIBC_PREREQ(2, 4)' before evaluating it:
>
> block-raw-posix.c:548:69: missing binary operator before token "("
>
> so I just put it on an extra line.
>   

It's fixed in SVN now.

Regards,

Anthony Liguori

From anthony at codemonkey.ws  Sat Sep 27 15:34:44 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Sat Sep 27 15:34:51 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
 screen updates... (now updated to r5313)
In-Reply-To: <20080926220445.GA13099@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
Message-ID: <48DE5256.5000101@codemonkey.ws>

Juergen Lock wrote:
> On Fri, Sep 26, 2008 at 10:04:28AM -0500, Anthony Liguori wrote:
>   
>> Matt wrote:
>>     
>>>>  Here is another experimental update that forces -lthr on 6.x, and
>>>> also updates to qemu svn r5313:
>>>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>>>     
>>>>         
>>> I just built this update and it seems to have fixed the issue.  Host
>>> CPU usage again tracks with guest CPU usage and all seems well.  I'll
>>> continue to use this build to see if anything else crops up.
>>>
>>> Please let me know if there is anything other information I can provide.
>>>   
>>>       
>> If ya'll have patches to make QEMU work on FreeBSD, please submit them.  
>> I'm about to commit a patch that's what it took for me to get SVN working 
>> on FreeBSD.
>>
>> The one thing that really tripped me up with the whole aio kld-module 
>> thing.  Perhaps we should detect the presence of the module at run time and 
>> disable aio?  I assume kldload can only be run as root?
>>     
>
> Yes.  Atm the ports print a warning when aio is not loaded:
>   

Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
modfind("aio") is not available (printing a warning along with that 
would be fine).  A non-privileged user cannot load the aio module so 
it's not very useful to tell them to load it.

>  And here is another patch thats needed on amd64 hosts for tcg (which
> I had posted before:)
>
> Index: qemu/exec.c
> @@ -405,6 +405,28 @@
>              exit(1);
>          }
>      }
> +#elif defined(__FreeBSD__)
> +    {
> +        int flags;
> +        void *addr = NULL;
> +        flags = MAP_PRIVATE | MAP_ANONYMOUS;
> +#if defined(__x86_64__)
> +        /* FreeBSD doesn't have MAP_32BIT, use MAP_FIXED and assume
> +         * 0x40000000 is free */
> +        flags |= MAP_FIXED;
> +        addr = (void *)0x40000000;
> +        /* Cannot map more than that */
> +        if (code_gen_buffer_size > (800 * 1024 * 1024))
> +            code_gen_buffer_size = (800 * 1024 * 1024);
> +#endif
> +        code_gen_buffer = mmap(addr, code_gen_buffer_size,
> +                               PROT_WRITE | PROT_READ | PROT_EXEC, 
> +                               flags, -1, 0);
> +        if (code_gen_buffer == MAP_FAILED) {
> +            fprintf(stderr, "Could not allocate dynamic translator buffer\n");
> +            exit(1);
> +        }
> +    }
>  #else
>      code_gen_buffer = qemu_malloc(code_gen_buffer_size);
>      if (!code_gen_buffer) {
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>   

Applied.  Thanks.

>  I'll see if I can prepare another update over the weekend and then go
> thru more of the patches that have accumulated in the port...
>   

That would be great!

Regards,

Anthony Liguori

>  Thanx,
> 	Juergen
>   

From Alexander at Leidinger.net  Sat Sep 27 19:14:10 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Sat Sep 27 19:14:24 2008
Subject: Linux GTK+ 2.10+
In-Reply-To: <20080926090840.GA4260@freebsd.org>
References: <48D9A3CC.50905@gmail.com>
	<20080924075822.19786d2gvegqgxcs@webmail.leidinger.net>
	<20080926090840.GA4260@freebsd.org>
Message-ID: <20080927211401.604884ea@deskjail>

Quoting Roman Divacky <rdivacky@freebsd.org> (Fri, 26 Sep 2008 11:08:40 +0200):

> On Wed, Sep 24, 2008 at 07:58:22AM +0200, Alexander Leidinger wrote:
> > Quoting "Eitan Adler" <eitanadlerlist@gmail.com> (from Tue, 23 Sep  
> > 2008 22:19:56 -0400):
> > 
> > >Does anyone know when the linux-gtk2 port will support version 2.10 or
> > >above?
> > 
> > Find a good linux gtk2 RPM which works on Fedora 4, and we can update  
> > it. If you don't find one, you have to wait until we have the new  
> > linux infrastructure (Fedora 6, 7 or 8) fully integrated into the  
> > ports (this requires that you run a FreeBSD release which supports  
> > enough of the linux 2.6 kernel).
> 
> what is the plan in this area? are we going to switch to newer fedora
> on 8.x ?
> 
> I'd like to know the official position here :)

The official position is: I'm in the middle of moving, and Boris (who
has all patches for this) was on a business trip the last time we
discussed this.

The plan is: wait for the ports unfreeze and send it to portmgr for an
experimental run on the ports build cluster (depends upon the free time
of Boris).

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
From nox at jelal.kn-bremen.de  Sat Sep 27 20:50:48 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sat Sep 27 20:50:56 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb,
	vmwarevga, screen updates... (now updated to r5331)
In-Reply-To: <20080926220445.GA13099@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
Message-ID: <20080927204729.GA52209@saturn.kn-bremen.de>

On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>[...]
>  I'll see if I can prepare another update over the weekend and then go
> thru more of the patches that have accumulated in the port...

OK, here we go :)  First the update: (at r5331 now)
	http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch

1. FreeBSD also has clock_gettime:

Index: qemu/vl.c
@@ -541,7 +541,7 @@
 static void init_get_clock(void)
 {
     use_rt_clock = 0;
-#if defined(__linux__)
+#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
     {
         struct timespec ts;
         if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
@@ -553,7 +553,7 @@
 
 static int64_t get_clock(void)
 {
-#if defined(__linux__)
+#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
     if (use_rt_clock) {
         struct timespec ts;
         clock_gettime(CLOCK_MONOTONIC, &ts);

2. open() can also return EPERM for O_RDWR on a readonly device (I think
the case where this happened was a cdrom:)

Index: qemu/block.c
@@ -381,7 +381,7 @@
     else
         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
     ret = drv->bdrv_open(bs, filename, open_flags);
-    if (ret == -EACCES && !(flags & BDRV_O_FILE)) {
+    if ((ret == -EACCES || ret == -EPERM) && !(flags & BDRV_O_FILE)) {
         ret = drv->bdrv_open(bs, filename, BDRV_O_RDONLY);
         bs->read_only = 1;
     }

3. the following bugfix is needed at least for FreeBSD/amd64 guests:
(original patch from
	http://www.nabble.com/-PATCH--i386-hard-interrupt-generation-bug-fix-p14921171.html
)

Index: qemu/cpu-exec.c
@@ -394,16 +394,18 @@
                                      (env->eflags & IF_MASK && 
                                       !(env->hflags & HF_INHIBIT_IRQ_MASK))))) {
                             int intno;
-                            svm_check_intercept(SVM_EXIT_INTR);
                             env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
                             intno = cpu_get_pic_interrupt(env);
-                            if (loglevel & CPU_LOG_TB_IN_ASM) {
-                                fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
+                            if (intno>=0) {
+                                svm_check_intercept(SVM_EXIT_INTR);
+                                if (loglevel & CPU_LOG_TB_IN_ASM) {
+                                    fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
+                                }
+                                do_interrupt(intno, 0, 0, 0, 1);
+                                /* ensure that no TB jump will be modified as
+                                   the program flow was changed */
+                                next_tb = 0;
                             }
-                            do_interrupt(intno, 0, 0, 0, 1);
-                            /* ensure that no TB jump will be modified as
-                               the program flow was changed */
-                            next_tb = 0;
 #if !defined(CONFIG_USER_ONLY)
                         } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
                                    (env->eflags & IF_MASK) && 

4. this is also needed for (some?) amd64 guests on i386 hosts:

Index: qemu/exec-all.h
@@ -30,7 +30,7 @@
 struct TranslationBlock;
 
 /* XXX: make safe guess about sizes */
-#define MAX_OP_PER_INSTR 64
+#define MAX_OP_PER_INSTR 128 /* 64 */
 /* A Call op needs up to 6 + 2N parameters (N = number of arguments).  */
 #define MAX_OPC_PARAM 10
 #define OPC_BUF_SIZE 512

5. no need (?) for a dummy file on FreeBSD too: (like on OpenBSD)

Index: qemu/osdep.c
@@ -75,8 +75,10 @@
 #include <sys/types.h>
 #include <sys/mount.h>
 #else
+#ifndef __FreeBSD__
 #include <sys/vfs.h>
 #endif
+#endif
 
 #include <sys/mman.h>
 #include <fcntl.h>
@@ -87,7 +87,7 @@
     static int phys_ram_size = 0;
     void *ptr;
 
-#ifdef __OpenBSD__ /* no need (?) for a dummy file on OpenBSD */
+#if defined(__OpenBSD__) || defined(__FreeBSD__) /* no need (?) for a dummy file on OpenBSD/FreeBSD */
     int map_anon = MAP_ANON;
 #else
     int map_anon = 0;
@@ -154,7 +154,7 @@
     }
     size = (size + 4095) & ~4095;
     ftruncate(phys_ram_fd, phys_ram_size + size);
-#endif /* !__OpenBSD__ */
+#endif /* !(__OpenBSD__ || __FreeBSD__) */
     ptr = mmap(NULL,
                size,
                PROT_WRITE | PROT_READ, map_anon | MAP_SHARED,

6. correct lib search path on FreeBSD/amd64 hosts (tho this needs to be
conditionally applied if its to go into qemu svn:)

Index: qemu/x86_64.ld
@@ -2,7 +2,7 @@
 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
 OUTPUT_ARCH(i386:x86-64)
 ENTRY(_start)
-SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib64");
+SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */

 I think thats it for now...  more maybe later.
	Juergen

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
From nox at jelal.kn-bremen.de  Sat Sep 27 22:53:36 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sat Sep 27 22:53:42 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates... (now updated to r5313)
In-Reply-To: <48DE5256.5000101@codemonkey.ws>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
Message-ID: <200809272252.m8RMq4fu057049@saturn.kn-bremen.de>

In article <48DE5256.5000101@codemonkey.ws> you write:
>[...]

>>> The one thing that really tripped me up with the whole aio kld-module 
>>> thing.  Perhaps we should detect the presence of the module at run time and 
>>> disable aio?  I assume kldload can only be run as root?
>>>     
>>
>> Yes.  Atm the ports print a warning when aio is not loaded:
>>   
>
>Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
>modfind("aio") is not available (printing a warning along with that 
>would be fine).  A non-privileged user cannot load the aio module so 
>it's not very useful to tell them to load it.

OK so how about the following?  (only tested with a raw image, but if
the way its disabled for OpenBSD works for all of them this should as well.)

 Oh and am I right qemu-img doesn't use aio?  If it actually does we may
want to add the same check there instead of just disabling it.  (I kept it
enabled for qemu-nbd since thats not built on FreeBSD anyway.)

Index: qemu/block.h
@@ -50,10 +50,9 @@
 #define BDRV_O_DIRECT      0x0020
 #define BDRV_O_AUTOGROW    0x0040 /* Allow backing file to extend when writing past end of file */
 
-void bdrv_info(void);
+void bdrv_init(int emulate_aio);
 void bdrv_info_stats(void);
 
-void bdrv_init(void);
 BlockDriver *bdrv_find_format(const char *format_name);
 int bdrv_create(BlockDriver *drv,
                 const char *filename, int64_t size_in_sectors,
Index: qemu/block.c
@@ -177,9 +177,9 @@
 }
 
 
-static void bdrv_register(BlockDriver *bdrv)
+static void bdrv_register(BlockDriver *bdrv, int emulate_aio)
 {
-    if (!bdrv->bdrv_aio_read) {
+    if (!bdrv->bdrv_aio_read || emulate_aio) {
         /* add AIO emulation layer */
         bdrv->bdrv_aio_read = bdrv_aio_read_em;
         bdrv->bdrv_aio_write = bdrv_aio_write_em;
@@ -1374,23 +1374,23 @@
     return async_ret;
 }
 
-void bdrv_init(void)
+void bdrv_init(int emulate_aio)
 {
-    bdrv_register(&bdrv_raw);
-    bdrv_register(&bdrv_host_device);
+    bdrv_register(&bdrv_raw, emulate_aio);
+    bdrv_register(&bdrv_host_device, 0);
 #ifndef _WIN32
-    bdrv_register(&bdrv_cow);
+    bdrv_register(&bdrv_cow, 0);
 #endif
-    bdrv_register(&bdrv_qcow);
-    bdrv_register(&bdrv_vmdk);
-    bdrv_register(&bdrv_cloop);
-    bdrv_register(&bdrv_dmg);
-    bdrv_register(&bdrv_bochs);
-    bdrv_register(&bdrv_vpc);
-    bdrv_register(&bdrv_vvfat);
-    bdrv_register(&bdrv_qcow2);
-    bdrv_register(&bdrv_parallels);
-    bdrv_register(&bdrv_nbd);
+    bdrv_register(&bdrv_qcow, 0);
+    bdrv_register(&bdrv_vmdk, 0);
+    bdrv_register(&bdrv_cloop, 0);
+    bdrv_register(&bdrv_dmg, 0);
+    bdrv_register(&bdrv_bochs, 0);
+    bdrv_register(&bdrv_vpc, 0);
+    bdrv_register(&bdrv_vvfat, 0);
+    bdrv_register(&bdrv_qcow2, 0);
+    bdrv_register(&bdrv_parallels, 0);
+    bdrv_register(&bdrv_nbd, 0);
 }
 
 void *qemu_aio_get(BlockDriverState *bs, BlockDriverCompletionFunc *cb,
Index: qemu/vl.c
@@ -8609,6 +8609,7 @@
     int tb_size;
     const char *pid_file = NULL;
     VLANState *vlan;
+    int emulate_aio = 0;
 
     LIST_INIT (&vm_change_state_head);
 #ifndef _WIN32
@@ -8681,6 +8682,13 @@
 
     tb_size = 0;
     
+#ifdef __FreeBSD__
+    if (modfind("aio") == -1) {
+        emulate_aio = 1;
+        fprintf(stderr, "warning: aio not (kld)loaded, disabling (may slow down on disk IO\n");
+    }
+#endif
+
     optind = 1;
     for(;;) {
         if (optind >= argc)
@@ -9415,7 +9423,7 @@
     /* init the dynamic translator */
     cpu_exec_init_all(tb_size * 1024 * 1024);
 
-    bdrv_init();
+    bdrv_init(emulate_aio);
 
     /* we always create the cdrom drive, even if no disk is there */
 
Index: qemu/qemu-img.c
@@ -733,7 +733,7 @@
 {
     const char *cmd;
 
-    bdrv_init();
+    bdrv_init(1);
     if (argc < 2)
         help();
     cmd = argv[1];
Index: qemu/qemu-nbd.c
@@ -326,7 +326,7 @@
 	return 0;
     }
 
-    bdrv_init();
+    bdrv_init(0);
 
     bs = bdrv_new("hda");
     if (bs == NULL)

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
From unixmania at gmail.com  Sun Sep 28 04:26:08 2008
From: unixmania at gmail.com (Carlos A. M. dos Santos)
Date: Sun Sep 28 04:26:16 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates... (now updated to r5331)
In-Reply-To: <20080927204729.GA52209@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
	<20080927204729.GA52209@saturn.kn-bremen.de>
Message-ID: <e71790db0809272104p1b3f383epb753fff72bb6f101@mail.gmail.com>

On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>>[...]
>>  I'll see if I can prepare another update over the weekend and then go
>> thru more of the patches that have accumulated in the port...
>
> OK, here we go :)  First the update: (at r5331 now)
>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>
> 1. FreeBSD also has clock_gettime:
>
> Index: qemu/vl.c
> @@ -541,7 +541,7 @@
>  static void init_get_clock(void)
>  {
>     use_rt_clock = 0;
> -#if defined(__linux__)
> +#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
>     {
>         struct timespec ts;
>         if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
> @@ -553,7 +553,7 @@
>
>  static int64_t get_clock(void)
>  {
> -#if defined(__linux__)
> +#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
>     if (use_rt_clock) {
>         struct timespec ts;
>         clock_gettime(CLOCK_MONOTONIC, &ts);
>
> 2. open() can also return EPERM for O_RDWR on a readonly device (I think
> the case where this happened was a cdrom:)
>
> Index: qemu/block.c
> @@ -381,7 +381,7 @@
>     else
>         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
>     ret = drv->bdrv_open(bs, filename, open_flags);
> -    if (ret == -EACCES && !(flags & BDRV_O_FILE)) {
> +    if ((ret == -EACCES || ret == -EPERM) && !(flags & BDRV_O_FILE)) {
>         ret = drv->bdrv_open(bs, filename, BDRV_O_RDONLY);
>         bs->read_only = 1;
>     }
>
> 3. the following bugfix is needed at least for FreeBSD/amd64 guests:
> (original patch from
>        http://www.nabble.com/-PATCH--i386-hard-interrupt-generation-bug-fix-p14921171.html
> )
>
> Index: qemu/cpu-exec.c
> @@ -394,16 +394,18 @@
>                                      (env->eflags & IF_MASK &&
>                                       !(env->hflags & HF_INHIBIT_IRQ_MASK))))) {
>                             int intno;
> -                            svm_check_intercept(SVM_EXIT_INTR);
>                             env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
>                             intno = cpu_get_pic_interrupt(env);
> -                            if (loglevel & CPU_LOG_TB_IN_ASM) {
> -                                fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
> +                            if (intno>=0) {
> +                                svm_check_intercept(SVM_EXIT_INTR);
> +                                if (loglevel & CPU_LOG_TB_IN_ASM) {
> +                                    fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
> +                                }
> +                                do_interrupt(intno, 0, 0, 0, 1);
> +                                /* ensure that no TB jump will be modified as
> +                                   the program flow was changed */
> +                                next_tb = 0;
>                             }
> -                            do_interrupt(intno, 0, 0, 0, 1);
> -                            /* ensure that no TB jump will be modified as
> -                               the program flow was changed */
> -                            next_tb = 0;
>  #if !defined(CONFIG_USER_ONLY)
>                         } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
>                                    (env->eflags & IF_MASK) &&
>
> 4. this is also needed for (some?) amd64 guests on i386 hosts:
>
> Index: qemu/exec-all.h
> @@ -30,7 +30,7 @@
>  struct TranslationBlock;
>
>  /* XXX: make safe guess about sizes */
> -#define MAX_OP_PER_INSTR 64
> +#define MAX_OP_PER_INSTR 128 /* 64 */
>  /* A Call op needs up to 6 + 2N parameters (N = number of arguments).  */
>  #define MAX_OPC_PARAM 10
>  #define OPC_BUF_SIZE 512
>
> 5. no need (?) for a dummy file on FreeBSD too: (like on OpenBSD)
>
> Index: qemu/osdep.c
> @@ -75,8 +75,10 @@
>  #include <sys/types.h>
>  #include <sys/mount.h>
>  #else
> +#ifndef __FreeBSD__
>  #include <sys/vfs.h>
>  #endif
> +#endif
>
>  #include <sys/mman.h>
>  #include <fcntl.h>
> @@ -87,7 +87,7 @@
>     static int phys_ram_size = 0;
>     void *ptr;
>
> -#ifdef __OpenBSD__ /* no need (?) for a dummy file on OpenBSD */
> +#if defined(__OpenBSD__) || defined(__FreeBSD__) /* no need (?) for a dummy file on OpenBSD/FreeBSD */
>     int map_anon = MAP_ANON;
>  #else
>     int map_anon = 0;
> @@ -154,7 +154,7 @@
>     }
>     size = (size + 4095) & ~4095;
>     ftruncate(phys_ram_fd, phys_ram_size + size);
> -#endif /* !__OpenBSD__ */
> +#endif /* !(__OpenBSD__ || __FreeBSD__) */
>     ptr = mmap(NULL,
>                size,
>                PROT_WRITE | PROT_READ, map_anon | MAP_SHARED,
>
> 6. correct lib search path on FreeBSD/amd64 hosts (tho this needs to be
> conditionally applied if its to go into qemu svn:)
>
> Index: qemu/x86_64.ld
> @@ -2,7 +2,7 @@
>  OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
>  OUTPUT_ARCH(i386:x86-64)
>  ENTRY(_start)
> -SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib64");
> +SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");
>  SECTIONS
>  {
>   /* Read-only sections, merged into text segment: */
>
>  I think thats it for now...  more maybe later.
>        Juergen
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

I suggest applying the following patch (on top of yours). It includes
options to build additional sound emulators.

--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
+++ Makefile	2008-09-28 00:53:03.000000000 -0300
@@ -38,6 +38,10 @@
 		GNUTLS "gnutls dependency (vnc encryption)" On \
 		PCAP "pcap dependency (networking with bpf)" On \
 		CDROM_DMA "IDE CDROM DMA" On \
+		AC97 "Intel 82801AA AC97 sound card" Off \
+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
+		GUS "Gravis Ultrasound GF1 sound card" Off \
 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On

 .include <bsd.port.pre.mk>
@@ -76,6 +80,35 @@
 CONFIGURE_ARGS+=	--enable-pcap
 .endif

+.if defined(WITH_AC97)
+AUDIO_CARD_LIST=	ac97
+.endif
+
+.if defined(WITH_ADLIB)
+.if defined(AUDIO_CARD_LIST)
+AUDIO_CARD_LIST+=	,
+.endif
+AUDIO_CARD_LIST+=	adlib
+.endif
+
+.if defined(WITH_CS4231A)
+.if defined(AUDIO_CARD_LIST)
+AUDIO_CARD_LIST+=	,
+.endif
+AUDIO_CARD_LIST+=	cs4231a
+.endif
+
+.if defined(WITH_GUS)
+.if defined(AUDIO_CARD_LIST)
+AUDIO_CARD_LIST+=	,
+.endif
+AUDIO_CARD_LIST+=	gus
+.endif
+
+.if defined(AUDIO_CARD_LIST)
+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
+.endif
+
 .if defined(WITH_SAMBA)
 RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
 .endif

Signed-off-by: Carlos Santos <unixmania@gmail.com>

-- 
cd /usr/ports/sysutils/life
make clean
From patfbsd at davenulle.org  Sun Sep 28 13:05:53 2008
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Sun Sep 28 13:06:00 2008
Subject: Virtualbox  2.0.2 and FreeBSD 7 x64 guest install crashes
In-Reply-To: <48DE3D43.8060606@kc8onw.net>
References: <48DE3D43.8060606@kc8onw.net>
Message-ID: <20080928144912.7566907a@baby-jane-lamaiziere-net.local>

Le Sat, 27 Sep 2008 17:03:47 +0300,
Jonathan <jonathan@kc8onw.net> a ?crit :

> Has anyone had any success with Virtualbox  2.0.2 and a FreeBSD 7 x64
> guest?  I've tried pretty much every available option combination but
> it consistently crashes on boot right after the loader prompt.  The
> md5 for the ISO is correct.
> 
> I'm definitely willing to put some time towards debugging it but I'm
> not sure where to start.  The Virtualbox IRC dev channel told me to
> ask the FreeBSD project but since Virtualbox itself crashes I would
> think I would have to start on their side...  I'd like to start
> somewhere.  It would be great to have a 32 bit and a 64 bit VM for
> testing purposes.

There is a know bug with FreeBSD as
guest, see http://www.virtualbox.org/ticket/458

I don't know if this is fixed.

I was able to test FreeBSD 7/i386 on MacOS X but it always crashes on
sigreturn at some point.

Regards.
From jonathan at kc8onw.net  Sun Sep 28 13:17:53 2008
From: jonathan at kc8onw.net (Jonathan)
Date: Sun Sep 28 13:18:01 2008
Subject: Virtualbox  2.0.2 and FreeBSD 7 x64 guest install crashes
In-Reply-To: <20080928144912.7566907a@baby-jane-lamaiziere-net.local>
References: <48DE3D43.8060606@kc8onw.net>
	<20080928144912.7566907a@baby-jane-lamaiziere-net.local>
Message-ID: <48DF83E7.10805@kc8onw.net>

Patrick Lamaizi?re wrote:
> Le Sat, 27 Sep 2008 17:03:47 +0300,
> Jonathan <jonathan@kc8onw.net> a ?crit :
>
>> Has anyone had any success with Virtualbox  2.0.2 and a FreeBSD 7 x64
>> guest?  I've tried pretty much every available option combination but
>> it consistently crashes on boot right after the loader prompt.  The
>> md5 for the ISO is correct.
>>
>> I'm definitely willing to put some time towards debugging it but I'm
>> not sure where to start.  The Virtualbox IRC dev channel told me to
>> ask the FreeBSD project but since Virtualbox itself crashes I would
>> think I would have to start on their side...  I'd like to start
>> somewhere.  It would be great to have a 32 bit and a 64 bit VM for
>> testing purposes.
>
> There is a know bug with FreeBSD as
> guest, see http://www.virtualbox.org/ticket/458
>
> I don't know if this is fixed.
>
> I was able to test FreeBSD 7/i386 on MacOS X but it always crashes on
> sigreturn at some point.

With 1.6.2 I was able to work around this by enabling hardware
virtualization support but with Virtualbox 2.0.2 it crashes on startup
now.  It seems Virtualbox doesn't like something about Freebsd's boot
loader on i386 or amd64.

Jonathan
From patfbsd at davenulle.org  Sun Sep 28 16:12:55 2008
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Sun Sep 28 16:13:02 2008
Subject: Virtualbox  2.0.2 and FreeBSD 7 x64 guest install crashes
In-Reply-To: <48DF83E7.10805@kc8onw.net>
References: <48DE3D43.8060606@kc8onw.net>
	<20080928144912.7566907a@baby-jane-lamaiziere-net.local>
	<48DF83E7.10805@kc8onw.net>
Message-ID: <20080928181251.5c0507b5@baby-jane-lamaiziere-net.local>

Le Sun, 28 Sep 2008 16:17:27 +0300,
Jonathan <jonathan@kc8onw.net> a ?crit :

> > There is a know bug with FreeBSD as
> > guest, see http://www.virtualbox.org/ticket/458
> >
> > I don't know if this is fixed.
> >
> > I was able to test FreeBSD 7/i386 on MacOS X but it always crashes
> > on sigreturn at some point.
> 
> With 1.6.2 I was able to work around this by enabling hardware
> virtualization support but with Virtualbox 2.0.2 it crashes on startup
> now.  It seems Virtualbox doesn't like something about Freebsd's boot
> loader on i386 or amd64.

I'm installing PC-BSD 7/i386 on VirtualBox 2.0.2, it seems to work (will
do one or two "make buildworld" to be sure). On Mac OS X the VT option
is not available.

I will try amd64 later.

Regards.
From bugmaster at FreeBSD.org  Mon Sep 29 11:06:49 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep 29 11:07:23 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200809291106.m8TB6mNp040762@freefall.freebsd.org>

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/126232  emulation  [linux] Linux ioctl TCGETS (0x5401) always fails
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
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/29698   emulation  [linux] [patch] linux ipcs doesn'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

12 problems total.

From dchagin at freebsd.org  Mon Sep 29 20:02:45 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Mon Sep 29 20:02:52 2008
Subject: firefox & flash9 patches
Message-ID: <20080929200237.GA68300@dchagin.dialup.corbina.ru>


Hi,

please, test following patches (just -current).
with them firefox && flash9 forks for me,
I tested only on ia32@amd64 with 2.6.16 enabled,
firefox 2.0.0.16 and flash9 plugin.

If all is good, I will ask des@ and kib@ to review&commit them. thnx!

diff --git a/src/sys/compat/linux/linux_misc.c b/src/sys/compat/linux/linux_misc.c
index 585c853..073bedb 100644
--- a/src/sys/compat/linux/linux_misc.c
+++ b/src/sys/compat/linux/linux_misc.c
@@ -1831,9 +1831,9 @@ linux_sched_getaffinity(struct thread *td,
 	cga.level = CPU_LEVEL_WHICH;
 	cga.which = CPU_WHICH_PID;
 	cga.id = args->pid;
-	cga.cpusetsize = sizeof(cpumask_t);
+	cga.cpusetsize = sizeof(cpuset_t);
 	cga.mask = (cpuset_t *) args->user_mask_ptr;
-	
+
 	if ((error = cpuset_getaffinity(td, &cga)) == 0)
 		td->td_retval[0] = sizeof(cpumask_t);
 


diff --git a/src/sys/compat/linprocfs/linprocfs.c b/src/sys/compat/linprocfs/linprocfs.c
index 646d6b2..bbb0556 100644
--- a/src/sys/compat/linprocfs/linprocfs.c
+++ b/src/sys/compat/linprocfs/linprocfs.c
@@ -873,14 +873,12 @@ linprocfs_doprocenviron(PFS_FILL_ARGS)
 static int
 linprocfs_doprocmaps(PFS_FILL_ARGS)
 {
-	char mebuffer[512];
 	vm_map_t map = &p->p_vmspace->vm_map;
 	vm_map_entry_t entry, tmp_entry;
 	vm_object_t obj, tobj, lobj;
 	vm_offset_t saved_end;
 	vm_ooffset_t off = 0;
 	char *name = "", *freename = NULL;
-	size_t len;
 	ino_t ino;
 	unsigned int last_timestamp;
 	int ref_count, shadow_count, flags;
@@ -898,13 +896,9 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
 	if (uio->uio_rw != UIO_READ)
 		return (EOPNOTSUPP);
 
-	if (uio->uio_offset != 0)
-		return (0);
-
 	error = 0;
 	vm_map_lock_read(map);
-	for (entry = map->header.next;
-	    ((uio->uio_resid > 0) && (entry != &map->header));
+	for (entry = map->header.next; entry != &map->header;
 	    entry = entry->next) {
 		name = "";
 		freename = NULL;
@@ -953,7 +947,7 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
 		 * format:
 		 *  start, end, access, offset, major, minor, inode, name.
 		 */
-		snprintf(mebuffer, sizeof mebuffer,
+		error = sbuf_printf(sb,
 		    "%08lx-%08lx %s%s%s%s %08lx %02x:%02x %lu%s%s\n",
 		    (u_long)entry->start, (u_long)entry->end,
 		    (entry->protection & VM_PROT_READ)?"r":"-",
@@ -969,18 +963,11 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
 		    );
 		if (freename)
 			free(freename, M_TEMP);
-		len = strlen(mebuffer);
-		if (len > uio->uio_resid)
-			len = uio->uio_resid; /*
-					       * XXX We should probably return
-					       * EFBIG here, as in procfs.
-					       */
 		last_timestamp = map->timestamp;
 		vm_map_unlock_read(map);
-		error = uiomove(mebuffer, len, uio);
+		if (error == -1)
+			return (0);
 		vm_map_lock_read(map);
-		if (error)
-			break;
 		if (last_timestamp + 1 != map->timestamp) {
 			/*
 			 * Look again for the entry because the map was



-- 
Have fun!
chd
From rdivacky at freebsd.org  Mon Sep 29 21:13:21 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Mon Sep 29 21:13:27 2008
Subject: firefox & flash9 patches
In-Reply-To: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
References: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
Message-ID: <20080929211303.GB7605@freebsd.org>

On Tue, Sep 30, 2008 at 12:02:37AM +0400, Chagin Dmitry wrote:
> 
> Hi,
> 
> please, test following patches (just -current).
> with them firefox && flash9 forks for me,
> I tested only on ia32@amd64 with 2.6.16 enabled,
> firefox 2.0.0.16 and flash9 plugin.
> 
> If all is good, I will ask des@ and kib@ to review&commit them. thnx!
> 
> diff --git a/src/sys/compat/linux/linux_misc.c b/src/sys/compat/linux/linux_misc.c
> index 585c853..073bedb 100644
> --- a/src/sys/compat/linux/linux_misc.c
> +++ b/src/sys/compat/linux/linux_misc.c
> @@ -1831,9 +1831,9 @@ linux_sched_getaffinity(struct thread *td,
>  	cga.level = CPU_LEVEL_WHICH;
>  	cga.which = CPU_WHICH_PID;
>  	cga.id = args->pid;
> -	cga.cpusetsize = sizeof(cpumask_t);
> +	cga.cpusetsize = sizeof(cpuset_t);

this makes sense... in linux this is called "cpumask_t" but it is
in fact our cpuset_t so I belive this change is correct

>  	cga.mask = (cpuset_t *) args->user_mask_ptr;
> -	
> +
>  	if ((error = cpuset_getaffinity(td, &cga)) == 0)
>  		td->td_retval[0] = sizeof(cpumask_t);
>  
> 
> 
> diff --git a/src/sys/compat/linprocfs/linprocfs.c b/src/sys/compat/linprocfs/linprocfs.c
> index 646d6b2..bbb0556 100644
> --- a/src/sys/compat/linprocfs/linprocfs.c
> +++ b/src/sys/compat/linprocfs/linprocfs.c
> @@ -873,14 +873,12 @@ linprocfs_doprocenviron(PFS_FILL_ARGS)
>  static int
>  linprocfs_doprocmaps(PFS_FILL_ARGS)
>  {
> -	char mebuffer[512];
>  	vm_map_t map = &p->p_vmspace->vm_map;
>  	vm_map_entry_t entry, tmp_entry;
>  	vm_object_t obj, tobj, lobj;
>  	vm_offset_t saved_end;
>  	vm_ooffset_t off = 0;
>  	char *name = "", *freename = NULL;
> -	size_t len;
>  	ino_t ino;
>  	unsigned int last_timestamp;
>  	int ref_count, shadow_count, flags;
> @@ -898,13 +896,9 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
>  	if (uio->uio_rw != UIO_READ)
>  		return (EOPNOTSUPP);
>  
> -	if (uio->uio_offset != 0)
> -		return (0);
> -
>  	error = 0;
>  	vm_map_lock_read(map);
> -	for (entry = map->header.next;
> -	    ((uio->uio_resid > 0) && (entry != &map->header));
> +	for (entry = map->header.next; entry != &map->header;
>  	    entry = entry->next) {
>  		name = "";
>  		freename = NULL;
> @@ -953,7 +947,7 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
>  		 * format:
>  		 *  start, end, access, offset, major, minor, inode, name.
>  		 */
> -		snprintf(mebuffer, sizeof mebuffer,
> +		error = sbuf_printf(sb,
>  		    "%08lx-%08lx %s%s%s%s %08lx %02x:%02x %lu%s%s\n",
>  		    (u_long)entry->start, (u_long)entry->end,
>  		    (entry->protection & VM_PROT_READ)?"r":"-",
> @@ -969,18 +963,11 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
>  		    );
>  		if (freename)
>  			free(freename, M_TEMP);
> -		len = strlen(mebuffer);
> -		if (len > uio->uio_resid)
> -			len = uio->uio_resid; /*
> -					       * XXX We should probably return
> -					       * EFBIG here, as in procfs.
> -					       */
>  		last_timestamp = map->timestamp;
>  		vm_map_unlock_read(map);
> -		error = uiomove(mebuffer, len, uio);
> +		if (error == -1)
> +			return (0);
>  		vm_map_lock_read(map);
> -		if (error)
> -			break;
>  		if (last_timestamp + 1 != map->timestamp) {
>  			/*
>  			 * Look again for the entry because the map was

I dont understand this change.... you just changed it from stack-based
to using sbufs? can you explain how/why this fixes the problem?

thnx! this is a great work!

roman

From dchagin at freebsd.org  Mon Sep 29 21:33:21 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Mon Sep 29 21:33:27 2008
Subject: firefox & flash9 patches
In-Reply-To: <20080929211303.GB7605@freebsd.org>
References: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
	<20080929211303.GB7605@freebsd.org>
Message-ID: <20080929213312.GA71793@dchagin.dialup.corbina.ru>

On Mon, Sep 29, 2008 at 11:13:03PM +0200, Roman Divacky wrote:
> On Tue, Sep 30, 2008 at 12:02:37AM +0400, Chagin Dmitry wrote:
> > 
> > Hi,
> > 
> > please, test following patches (just -current).
> > with them firefox && flash9 forks for me,
> > I tested only on ia32@amd64 with 2.6.16 enabled,
> > firefox 2.0.0.16 and flash9 plugin.
> > 
> > If all is good, I will ask des@ and kib@ to review&commit them. thnx!
> > 
> > diff --git a/src/sys/compat/linux/linux_misc.c b/src/sys/compat/linux/linux_misc.c
> > index 585c853..073bedb 100644
> > --- a/src/sys/compat/linux/linux_misc.c
> > +++ b/src/sys/compat/linux/linux_misc.c
> > @@ -1831,9 +1831,9 @@ linux_sched_getaffinity(struct thread *td,
> >  	cga.level = CPU_LEVEL_WHICH;
> >  	cga.which = CPU_WHICH_PID;
> >  	cga.id = args->pid;
> > -	cga.cpusetsize = sizeof(cpumask_t);
> > +	cga.cpusetsize = sizeof(cpuset_t);
> 
> this makes sense... in linux this is called "cpumask_t" but it is
> in fact our cpuset_t so I belive this change is correct
> 
> >  	cga.mask = (cpuset_t *) args->user_mask_ptr;
> > -	
> > +
> >  	if ((error = cpuset_getaffinity(td, &cga)) == 0)
> >  		td->td_retval[0] = sizeof(cpumask_t);
> >  
> > 
> > 
> > diff --git a/src/sys/compat/linprocfs/linprocfs.c b/src/sys/compat/linprocfs/linprocfs.c
> > index 646d6b2..bbb0556 100644
> > --- a/src/sys/compat/linprocfs/linprocfs.c
> > +++ b/src/sys/compat/linprocfs/linprocfs.c
> > @@ -873,14 +873,12 @@ linprocfs_doprocenviron(PFS_FILL_ARGS)
> >  static int
> >  linprocfs_doprocmaps(PFS_FILL_ARGS)
> >  {
> > -	char mebuffer[512];
> >  	vm_map_t map = &p->p_vmspace->vm_map;
> >  	vm_map_entry_t entry, tmp_entry;
> >  	vm_object_t obj, tobj, lobj;
> >  	vm_offset_t saved_end;
> >  	vm_ooffset_t off = 0;
> >  	char *name = "", *freename = NULL;
> > -	size_t len;
> >  	ino_t ino;
> >  	unsigned int last_timestamp;
> >  	int ref_count, shadow_count, flags;
> > @@ -898,13 +896,9 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
> >  	if (uio->uio_rw != UIO_READ)
> >  		return (EOPNOTSUPP);
> >  
> > -	if (uio->uio_offset != 0)
> > -		return (0);
> > -
> >  	error = 0;
> >  	vm_map_lock_read(map);
> > -	for (entry = map->header.next;
> > -	    ((uio->uio_resid > 0) && (entry != &map->header));
> > +	for (entry = map->header.next; entry != &map->header;
> >  	    entry = entry->next) {
> >  		name = "";
> >  		freename = NULL;
> > @@ -953,7 +947,7 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
> >  		 * format:
> >  		 *  start, end, access, offset, major, minor, inode, name.
> >  		 */
> > -		snprintf(mebuffer, sizeof mebuffer,
> > +		error = sbuf_printf(sb,
> >  		    "%08lx-%08lx %s%s%s%s %08lx %02x:%02x %lu%s%s\n",
> >  		    (u_long)entry->start, (u_long)entry->end,
> >  		    (entry->protection & VM_PROT_READ)?"r":"-",
> > @@ -969,18 +963,11 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
> >  		    );
> >  		if (freename)
> >  			free(freename, M_TEMP);
> > -		len = strlen(mebuffer);
> > -		if (len > uio->uio_resid)
> > -			len = uio->uio_resid; /*
> > -					       * XXX We should probably return
> > -					       * EFBIG here, as in procfs.
> > -					       */
> >  		last_timestamp = map->timestamp;
> >  		vm_map_unlock_read(map);
> > -		error = uiomove(mebuffer, len, uio);
> > +		if (error == -1)
> > +			return (0);
> >  		vm_map_lock_read(map);
> > -		if (error)
> > -			break;
> >  		if (last_timestamp + 1 != map->timestamp) {
> >  			/*
> >  			 * Look again for the entry because the map was
> 
> I dont understand this change.... you just changed it from stack-based
> to using sbufs? can you explain how/why this fixes the problem?
> 

pthread_getattr_np() uses /proc/<pid>/maps for some strange
thread stack size? calculation. it reads maps chunk by chunk, but current
version linprocfs_doprocmaps() disallow this:

> > -	if (uio->uio_offset != 0)
> > -		return (0);

also, please, see kern/101453 for explanation :)
thnx!

-- 
Have fun!
chd
From dchagin at freebsd.org  Tue Sep 30 05:10:20 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Sep 30 05:10:26 2008
Subject: firefox & flash9 patches
In-Reply-To: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
References: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
Message-ID: <20080930051011.GA2615@dchagin.dialup.corbina.ru>

On Tue, Sep 30, 2008 at 12:02:37AM +0400, Chagin Dmitry wrote:
> 
> Hi,
> 
> please, test following patches (just -current).
> with them firefox && flash9 forks for me,
> I tested only on ia32@amd64 with 2.6.16 enabled,
> firefox 2.0.0.16 and flash9 plugin.
> 

Has added args->len checkup, glibc waits EINVAL...
also has modified sched_setaffinity, as by default, glibc uses
128 bytes buffer for cpumask_t, so, we always fail here.
thnx!

diff --git a/src/sys/compat/linux/linux_misc.c b/src/sys/compat/linux/linux_misc.c
index 585c853..7f75713 100644
--- a/src/sys/compat/linux/linux_misc.c
+++ b/src/sys/compat/linux/linux_misc.c
@@ -1831,11 +1831,14 @@ linux_sched_getaffinity(struct thread *td,
 	cga.level = CPU_LEVEL_WHICH;
 	cga.which = CPU_WHICH_PID;
 	cga.id = args->pid;
-	cga.cpusetsize = sizeof(cpumask_t);
+	cga.cpusetsize = sizeof(cpuset_t);
 	cga.mask = (cpuset_t *) args->user_mask_ptr;
-	
+
+	if (cga.cpusetsize > args->len)
+		return (EINVAL);
+
 	if ((error = cpuset_getaffinity(td, &cga)) == 0)
-		td->td_retval[0] = sizeof(cpumask_t);
+		td->td_retval[0] = sizeof(cpuset_t);
 
 	return (error);
 }
@@ -1854,10 +1857,13 @@ linux_sched_setaffinity(struct thread *td,
 		printf(ARGS(sched_setaffinity, "%d, %d, *"), args->pid,
 		    args->len);
 #endif
+	if (args->len < sizeof(cpuset_t))
+		return (EINVAL);
+
 	csa.level = CPU_LEVEL_WHICH;
 	csa.which = CPU_WHICH_PID;
 	csa.id = args->pid;
-	csa.cpusetsize = args->len;
+	csa.cpusetsize = sizeof(cpuset_t);
 	csa.mask = (cpuset_t *) args->user_mask_ptr;
 
 	return (cpuset_setaffinity(td, &csa));
diff --git a/src/sys/compat/linprocfs/linprocfs.c b/src/sys/compat/linprocfs/linprocfs.c
index dd4bf77..715146a 100644
--- a/src/sys/compat/linprocfs/linprocfs.c
+++ b/src/sys/compat/linprocfs/linprocfs.c
@@ -872,14 +872,12 @@ linprocfs_doprocenviron(PFS_FILL_ARGS)
 static int
 linprocfs_doprocmaps(PFS_FILL_ARGS)
 {
-	char mebuffer[512];
 	vm_map_t map = &p->p_vmspace->vm_map;
 	vm_map_entry_t entry, tmp_entry;
 	vm_object_t obj, tobj, lobj;
 	vm_offset_t saved_end;
 	vm_ooffset_t off = 0;
 	char *name = "", *freename = NULL;
-	size_t len;
 	ino_t ino;
 	unsigned int last_timestamp;
 	int ref_count, shadow_count, flags;
@@ -897,13 +895,9 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
 	if (uio->uio_rw != UIO_READ)
 		return (EOPNOTSUPP);
 
-	if (uio->uio_offset != 0)
-		return (0);
-
 	error = 0;
 	vm_map_lock_read(map);
-	for (entry = map->header.next;
-	    ((uio->uio_resid > 0) && (entry != &map->header));
+	for (entry = map->header.next; entry != &map->header;
 	    entry = entry->next) {
 		name = "";
 		freename = NULL;
@@ -952,7 +946,7 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
 		 * format:
 		 *  start, end, access, offset, major, minor, inode, name.
 		 */
-		snprintf(mebuffer, sizeof mebuffer,
+		error = sbuf_printf(sb,
 		    "%08lx-%08lx %s%s%s%s %08lx %02x:%02x %lu%s%s\n",
 		    (u_long)entry->start, (u_long)entry->end,
 		    (entry->protection & VM_PROT_READ)?"r":"-",
@@ -968,18 +962,11 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
 		    );
 		if (freename)
 			free(freename, M_TEMP);
-		len = strlen(mebuffer);
-		if (len > uio->uio_resid)
-			len = uio->uio_resid; /*
-					       * XXX We should probably return
-					       * EFBIG here, as in procfs.
-					       */
 		last_timestamp = map->timestamp;
 		vm_map_unlock_read(map);
-		error = uiomove(mebuffer, len, uio);
+		if (error == -1)
+			return (0);
 		vm_map_lock_read(map);
-		if (error)
-			break;
 		if (last_timestamp + 1 != map->timestamp) {
 			/*
 			 * Look again for the entry because the map was


-- 
Have fun!
chd
From vova at fbsd.ru  Tue Sep 30 08:47:31 2008
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Tue Sep 30 08:47:38 2008
Subject: firefox & flash9 patches
In-Reply-To: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
References: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
Message-ID: <1222762139.1675.16.camel@localhost>

On Tue, 2008-09-30 at 00:02 +0400, Chagin Dmitry wrote:
> Hi,
> 
> please, test following patches (just -current).
> with them firefox && flash9 forks for me,
> I tested only on ia32@amd64 with 2.6.16 enabled,
> firefox 2.0.0.16 and flash9 plugin.

I've tried to check your patch - kernel builds ok, but nspluginwrapper
drops core
$  nspluginwrapper -l
Segmentation fault (core dumped)
$

and it kills gdb if I tried to run it under gdb
$ gdb nspluginwrapper 
GNU gdb 6.1.1 [FreeBSD]
...
(gdb) r -l
Starting program: /usr/local/bin/nspluginwrapper -l
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Assertion failed: ((mapbits & CHUNK_MAP_ALLOCATED) != 0), function arena_salloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3555.
Abort (core dumped)
$

I am puzzled, how to use it ?
Any help will be very appreciated.

> If all is good, I will ask des@ and kib@ to review&commit them. thnx!
> 
> diff --git a/src/sys/compat/linux/linux_misc.c b/src/sys/compat/linux/linux_misc.c
> index 585c853..073bedb 100644
> --- a/src/sys/compat/linux/linux_misc.c
> +++ b/src/sys/compat/linux/linux_misc.c
> @@ -1831,9 +1831,9 @@ linux_sched_getaffinity(struct thread *td,
>  	cga.level = CPU_LEVEL_WHICH;
>  	cga.which = CPU_WHICH_PID;
>  	cga.id = args->pid;
> -	cga.cpusetsize = sizeof(cpumask_t);
> +	cga.cpusetsize = sizeof(cpuset_t);
>  	cga.mask = (cpuset_t *) args->user_mask_ptr;
> -	
> +
>  	if ((error = cpuset_getaffinity(td, &cga)) == 0)
>  		td->td_retval[0] = sizeof(cpumask_t);
>  
> 
> 
> diff --git a/src/sys/compat/linprocfs/linprocfs.c b/src/sys/compat/linprocfs/linprocfs.c
> index 646d6b2..bbb0556 100644
> --- a/src/sys/compat/linprocfs/linprocfs.c
> +++ b/src/sys/compat/linprocfs/linprocfs.c
> @@ -873,14 +873,12 @@ linprocfs_doprocenviron(PFS_FILL_ARGS)
>  static int
>  linprocfs_doprocmaps(PFS_FILL_ARGS)
>  {
> -	char mebuffer[512];
>  	vm_map_t map = &p->p_vmspace->vm_map;
>  	vm_map_entry_t entry, tmp_entry;
>  	vm_object_t obj, tobj, lobj;
>  	vm_offset_t saved_end;
>  	vm_ooffset_t off = 0;
>  	char *name = "", *freename = NULL;
> -	size_t len;
>  	ino_t ino;
>  	unsigned int last_timestamp;
>  	int ref_count, shadow_count, flags;
> @@ -898,13 +896,9 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
>  	if (uio->uio_rw != UIO_READ)
>  		return (EOPNOTSUPP);
>  
> -	if (uio->uio_offset != 0)
> -		return (0);
> -
>  	error = 0;
>  	vm_map_lock_read(map);
> -	for (entry = map->header.next;
> -	    ((uio->uio_resid > 0) && (entry != &map->header));
> +	for (entry = map->header.next; entry != &map->header;
>  	    entry = entry->next) {
>  		name = "";
>  		freename = NULL;
> @@ -953,7 +947,7 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
>  		 * format:
>  		 *  start, end, access, offset, major, minor, inode, name.
>  		 */
> -		snprintf(mebuffer, sizeof mebuffer,
> +		error = sbuf_printf(sb,
>  		    "%08lx-%08lx %s%s%s%s %08lx %02x:%02x %lu%s%s\n",
>  		    (u_long)entry->start, (u_long)entry->end,
>  		    (entry->protection & VM_PROT_READ)?"r":"-",
> @@ -969,18 +963,11 @@ linprocfs_doprocmaps(PFS_FILL_ARGS)
>  		    );
>  		if (freename)
>  			free(freename, M_TEMP);
> -		len = strlen(mebuffer);
> -		if (len > uio->uio_resid)
> -			len = uio->uio_resid; /*
> -					       * XXX We should probably return
> -					       * EFBIG here, as in procfs.
> -					       */
>  		last_timestamp = map->timestamp;
>  		vm_map_unlock_read(map);
> -		error = uiomove(mebuffer, len, uio);
> +		if (error == -1)
> +			return (0);
>  		vm_map_lock_read(map);
> -		if (error)
> -			break;
>  		if (last_timestamp + 1 != map->timestamp) {
>  			/*
>  			 * Look again for the entry because the map was
> 
> 
> 
-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From dchagin at freebsd.org  Tue Sep 30 13:37:30 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Sep 30 13:37:39 2008
Subject: firefox & flash9 patches
In-Reply-To: <1222762139.1675.16.camel@localhost>
References: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
	<1222762139.1675.16.camel@localhost>
Message-ID: <20080930133719.GA4089@dchagin.dialup.corbina.ru>

On Tue, Sep 30, 2008 at 12:08:59PM +0400, Vladimir Grebenschikov wrote:
> On Tue, 2008-09-30 at 00:02 +0400, Chagin Dmitry wrote:
> > Hi,
> > 
> > please, test following patches (just -current).
> > with them firefox && flash9 forks for me,
> > I tested only on ia32@amd64 with 2.6.16 enabled,
> > firefox 2.0.0.16 and flash9 plugin.
> 
> I've tried to check your patch - kernel builds ok, but nspluginwrapper
> drops core
> $  nspluginwrapper -l
> Segmentation fault (core dumped)
> $
> 
> and it kills gdb if I tried to run it under gdb
> $ gdb nspluginwrapper 
> GNU gdb 6.1.1 [FreeBSD]
> ...
> (gdb) r -l
> Starting program: /usr/local/bin/nspluginwrapper -l
> (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Assertion failed: ((mapbits & CHUNK_MAP_ALLOCATED) != 0), function arena_salloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3555.
> Abort (core dumped)
> $
> 
> I am puzzled, how to use it ?
> Any help will be very appreciated.
> 

Hi,
Can you be more specific? Do you have any DEBUG options in kernel?
especially INVARIANTS - in this case it's necessary to build kernel.
also, please, show uname -v and installed plugins.

dchagin# uname -v
FreeBSD 8.0-CURRENT #0: Tue Sep 30 09:55:27 MSD 2008     root@dchagin.dialup.cor
bina.ru:/usr/obj/usr/local/root/pub/lxr/src/sys/ORA
dchagin#
dchagin# gdb nspluginwrapper
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb)
(gdb) r -l
Starting program: /usr/local/bin/nspluginwrapper -l

Program exited normally.
(gdb)

thnx!
-- 
Have fun!
chd
From vova at fbsd.ru  Tue Sep 30 13:58:39 2008
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Tue Sep 30 13:58:46 2008
Subject: firefox & flash9 patches
In-Reply-To: <20080930133719.GA4089@dchagin.dialup.corbina.ru>
References: <20080929200237.GA68300@dchagin.dialup.corbina.ru>
	<1222762139.1675.16.camel@localhost>
	<20080930133719.GA4089@dchagin.dialup.corbina.ru>
Message-ID: <1222783113.1675.67.camel@localhost>

On Tue, 2008-09-30 at 17:37 +0400, Chagin Dmitry wrote:
> On Tue, Sep 30, 2008 at 12:08:59PM +0400, Vladimir Grebenschikov wrote:
> > On Tue, 2008-09-30 at 00:02 +0400, Chagin Dmitry wrote:
> > > Hi,
> > > 
> > > please, test following patches (just -current).
> > > with them firefox && flash9 forks for me,
> > > I tested only on ia32@amd64 with 2.6.16 enabled,
> > > firefox 2.0.0.16 and flash9 plugin.
> > 
> > I've tried to check your patch - kernel builds ok, but nspluginwrapper
> > drops core
> > $  nspluginwrapper -l
> > Segmentation fault (core dumped)
> > $
> > 
> > and it kills gdb if I tried to run it under gdb
> > $ gdb nspluginwrapper 
> > GNU gdb 6.1.1 [FreeBSD]
> > ...
> > (gdb) r -l
> > Starting program: /usr/local/bin/nspluginwrapper -l
> > (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Assertion failed: ((mapbits & CHUNK_MAP_ALLOCATED) != 0), function arena_salloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3555.
> > Abort (core dumped)
> > $
> > 
> > I am puzzled, how to use it ?
> > Any help will be very appreciated.
> > 
> 
> Hi,
> Can you be more specific? Do you have any DEBUG options in kernel?
> especially INVARIANTS - in this case it's necessary to build kernel.

I have neither DEBUG nor INVARIANTS in kernel configuration. 
Should I rebuild kernel with these options to test patch ?

> also, please, show uname -v and installed plugins.

FreeBSD 8.0-CURRENT #3: Tue Sep 30 10:25:13 MSD 2008     root@vbook.fbsd.ru:/usr/obj/usr/src/sys/VBOOK 
I have yesterday's 8-CURRENT.

As for installed plug-ins, I guess I have only acrobat linux plugin, and
it works in ff3.
$ nspluginwrapper -v -a -i
Auto-install plugins from /usr/X11R6/lib/browser_plugins
Looking for plugins in /usr/X11R6/lib/browser_plugins
Auto-install plugins from /usr/X11R6/lib/firefox/plugins
Looking for plugins in /usr/X11R6/lib/firefox/plugins
Auto-install plugins from /usr/local/lib/npapi/linux-flashplugin
Looking for plugins in /usr/local/lib/npapi/linux-flashplugin
Install plugin /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so
 ... already installed system-wide, skipping
Auto-install plugins from /home/vova/.mozilla/plugins
Looking for plugins in /home/vova/.mozilla/plugins
Install plugin /home/vova/.mozilla/plugins/nppdf.so
  into /home/vova/.mozilla/plugins/npwrapper.nppdf.so
$ nspluginwrapper -l
Segmentation fault (core dumped)
$ 

But! core file decoded fine:

$ gdb /usr/local/bin/nspluginwrapper npconfig.core
GNU gdb 6.1.1 [FreeBSD]
... [cut lots of libraries]
#0  0x48359270 in gnome_vfs_xfer_delete_list ()
from /usr/local/lib/libgnomevfs-2.so.0
[New LWP 100181]
(gdb) bt
#0  0x48359270 in gnome_vfs_xfer_delete_list ()
from /usr/local/lib/libgnomevfs-2.so.0
#1  0x486f03f2 in std::bad_alloc::~bad_alloc () from /usr/lib/libstdc
++.so.6
#2  0x486f21d5 in __gnu_cxx::__atomic_add () from /usr/lib/libstdc
++.so.6
#3  0x48667969 in ?? () from /usr/lib/libstdc++.so.6
#4  0x48088140 in ?? ()
#5  0x480799b8 in ?? () from /libexec/ld-elf.so.1
#6  0xbfbfdd38 in ?? ()
#7  0x4805243c in dlsym () from /libexec/ld-elf.so.1
#8  0x48052dce in dlopen () from /libexec/ld-elf.so.1
#9  0x080490d4 in is_wrapper_plugin ()
#10 0x08049220 in is_wrapper_plugin_0 ()
#11 0x08048f34 in process_plugin_dir ()
#12 0x08048fd1 in process_list ()
#13 0x0804bb52 in main ()
(gdb) 

building port with DEBUG=yes and running binary from port directory (not
stripped) gives no  more details.

Sorry for not enough details in first attempt.

> thnx!
-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From anthony at codemonkey.ws  Tue Sep 30 14:52:38 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Tue Sep 30 14:52:44 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
 screen updates... (now updated to r5313)
In-Reply-To: <200809272252.m8RMq4fu057049@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>	<48DCF9FC.2070708@codemonkey.ws>	<20080926220445.GA13099@saturn.kn-bremen.de>
	<200809272252.m8RMq4fu057049@saturn.kn-bremen.de>
Message-ID: <48E23CF5.4000805@codemonkey.ws>

Juergen Lock wrote:
> In article <48DE5256.5000101@codemonkey.ws> you write:
>   
>> [...]
>>     
>
>   
>>>> The one thing that really tripped me up with the whole aio kld-module 
>>>> thing.  Perhaps we should detect the presence of the module at run time and 
>>>> disable aio?  I assume kldload can only be run as root?
>>>>     
>>>>         
>>> Yes.  Atm the ports print a warning when aio is not loaded:
>>>   
>>>       
>> Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
>> modfind("aio") is not available (printing a warning along with that 
>> would be fine).  A non-privileged user cannot load the aio module so 
>> it's not very useful to tell them to load it.
>>     
>
> OK so how about the following?  (only tested with a raw image, but if
> the way its disabled for OpenBSD works for all of them this should as well.)
>
>  Oh and am I right qemu-img doesn't use aio?  If it actually does we may
> want to add the same check there instead of just disabling it.  (I kept it
> enabled for qemu-nbd since thats not built on FreeBSD anyway.)
>   

Disabling aio for everyone is not the right thing if posix-aio is broken.

What would be better is in block-raw-posix.c, to have a one type check 
of modfind() (if we're FreeBSD), and if it fails, set a flag that forces 
the aio routines to call bdrv_aio_{read,write}_em.

Regards,

Anthony Liguori

From anthony at codemonkey.ws  Tue Sep 30 14:53:59 2008
From: anthony at codemonkey.ws (Anthony Liguori)
Date: Tue Sep 30 14:54:06 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
 screen updates... (now updated to r5331)
In-Reply-To: <20080927204729.GA52209@saturn.kn-bremen.de>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
	<20080927204729.GA52209@saturn.kn-bremen.de>
Message-ID: <48E23D47.4030602@codemonkey.ws>

Juergen Lock wrote:
> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>   
>> [...]
>>  I'll see if I can prepare another update over the weekend and then go
>> thru more of the patches that have accumulated in the port...
>>     
>
> OK, here we go :)  First the update: (at r5331 now)
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>   

Can you send this out as a series of patches?  It's much easier to 
comment and apply them that way.

Regards,

Anthony Liguori

From pfgshield-freebsd at yahoo.com  Tue Sep 30 21:33:16 2008
From: pfgshield-freebsd at yahoo.com (Pedro Giffuni)
Date: Tue Sep 30 21:33:47 2008
Subject: Extended precision vs Double Precision
Message-ID: <721952.6911.qm@web32704.mail.mud.yahoo.com>

Hi guys;

I am working on my article for EuroBSDCon and I found this website:

"Linux and the Extended Precision on x86 Processors"

http://www.vinc17.org/research/extended.en.html#bugs

just wondering... do we set Extended Precision in the Linuxulator?

cheers,

    Pedro.





      Scopri il blog di Yahoo! Mail:
Trucchi, novit? e la tua opinione.
http://www.ymailblogit.com/blog
From nox at jelal.kn-bremen.de  Tue Sep 30 22:25:36 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Tue Sep 30 22:25:42 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb,
	vmwarevga, screen updates... (now updated to r5313)
In-Reply-To: <48E23CF5.4000805@codemonkey.ws>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
	<200809272252.m8RMq4fu057049@saturn.kn-bremen.de>
	<48E23CF5.4000805@codemonkey.ws>
Message-ID: <20080930221720.GA44500@saturn.kn-bremen.de>

On Tue, Sep 30, 2008 at 09:51:33AM -0500, Anthony Liguori wrote:
> Juergen Lock wrote:
>> In article <48DE5256.5000101@codemonkey.ws> you write:
>>   
>>> [...]
>>>     
>> 
>>   
>>>>> The one thing that really tripped me up with the whole aio kld-module 
>>>>> thing.  Perhaps we should detect the presence of the module at run time 
>>>>> and disable aio?  I assume kldload can only be run as root?
>>>>>             
>>>> Yes.  Atm the ports print a warning when aio is not loaded:
>>>>         
>>> Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
>>> modfind("aio") is not available (printing a warning along with that would 
>>> be fine).  A non-privileged user cannot load the aio module so it's not 
>>> very useful to tell them to load it.
>>>     
>> 
>> OK so how about the following?  (only tested with a raw image, but if
>> the way its disabled for OpenBSD works for all of them this should as well.)
>> 
>>  Oh and am I right qemu-img doesn't use aio?  If it actually does we may
>> want to add the same check there instead of just disabling it.  (I kept it
>> enabled for qemu-nbd since thats not built on FreeBSD anyway.)
>>   
> 
> Disabling aio for everyone is not the right thing if posix-aio is broken.
> 
Well, I went after what is done for the OpenBSD case (CONFIG_AIO not set),
i.e. tell bdrv_register() to set bdrv_aio_read & frieds to bdrv_aio_read_em
etc for bdrv_raw if aio is not loaded.  I found one bug tho, the same
should be done for bdrv_host_device, i.e. in block.c
	bdrv_register(&bdrv_host_device, 0);
should be
	bdrv_register(&bdrv_host_device, emulate_aio);
too.  The 0 for the others there mean don't emulate i.e. keep aio enabled...

 Or are you talking about qemu-img?  If that would in fact benefit from
using aio like this too we could just add the same test as in vl.c.
(Or we could move the test to bdrv_init(), I just didn't want to print
the warning from in there.)

> What would be better is in block-raw-posix.c, to have a one type check of 
> modfind() (if we're FreeBSD), and if it fails, set a flag that forces the 
> aio routines to call bdrv_aio_{read,write}_em.
> 
 You mean runtime checks every time a raw aio fn is called (even if just
a flag?)  That's what I was trying to avoid... :)

 Regards,
	Juergen
From nox at jelal.kn-bremen.de  Tue Sep 30 22:38:45 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Tue Sep 30 22:38:56 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates... (now updated to r5331)
In-Reply-To: <48E23D47.4030602@codemonkey.ws>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
	<20080927204729.GA52209@saturn.kn-bremen.de>
Message-ID: <200809302235.m8UMZvNB045562@saturn.kn-bremen.de>

In article <48E23D47.4030602@codemonkey.ws> you write:
>Juergen Lock wrote:
>> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>>   
>>> [...]
>>>  I'll see if I can prepare another update over the weekend and then go
>>> thru more of the patches that have accumulated in the port...
>>>     
>>
>> OK, here we go :)  First the update: (at r5331 now)
>> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>>   
>
>Can you send this out as a series of patches?  It's much easier to 
>comment and apply them that way.

OK, but not today. :)

 Regards,
	Juergen
From nox at jelal.kn-bremen.de  Tue Sep 30 22:38:45 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Tue Sep 30 22:38:57 2008
Subject: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga,
	screen updates... (now updated to r5331)
In-Reply-To: <e71790db0809272104p1b3f383epb753fff72bb6f101@mail.gmail.com>
References: <20080921204025.GA81055@saturn.kn-bremen.de>
	<cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com>
	<200809242210.m8OMAcSZ021572@saturn.kn-bremen.de>
	<cd6b4a5b0809241954p159dd86u17fdc2a485008e7d@mail.gmail.com>
	<48DCF9FC.2070708@codemonkey.ws>
	<20080926220445.GA13099@saturn.kn-bremen.de>
	<20080927204729.GA52209@saturn.kn-bremen.de>
Message-ID: <200809302233.m8UMXdca045408@saturn.kn-bremen.de>

In article <e71790db0809272104p1b3f383epb753fff72bb6f101@mail.gmail.com> you write:
>On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>>>[...]
>>>  I'll see if I can prepare another update over the weekend and then go
>>> thru more of the patches that have accumulated in the port...
>>
>> OK, here we go :)  First the update: (at r5331 now)
>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>[...]
>
>I suggest applying the following patch (on top of yours). It includes
>options to build additional sound emulators.
>
>--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
>+++ Makefile	2008-09-28 00:53:03.000000000 -0300
>@@ -38,6 +38,10 @@
> 		GNUTLS "gnutls dependency (vnc encryption)" On \
> 		PCAP "pcap dependency (networking with bpf)" On \
> 		CDROM_DMA "IDE CDROM DMA" On \
>+		AC97 "Intel 82801AA AC97 sound card" Off \
>+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
>+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
>+		GUS "Gravis Ultrasound GF1 sound card" Off \
> 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On
>
> .include <bsd.port.pre.mk>
>@@ -76,6 +80,35 @@
> CONFIGURE_ARGS+=	--enable-pcap
> .endif
>
>+.if defined(WITH_AC97)
>+AUDIO_CARD_LIST=	ac97
>+.endif
>+
>+.if defined(WITH_ADLIB)
>+.if defined(AUDIO_CARD_LIST)
>+AUDIO_CARD_LIST+=	,
>+.endif
>+AUDIO_CARD_LIST+=	adlib
>+.endif
>+
>+.if defined(WITH_CS4231A)
>+.if defined(AUDIO_CARD_LIST)
>+AUDIO_CARD_LIST+=	,
>+.endif
>+AUDIO_CARD_LIST+=	cs4231a
>+.endif
>+
>+.if defined(WITH_GUS)
>+.if defined(AUDIO_CARD_LIST)
>+AUDIO_CARD_LIST+=	,
>+.endif
>+AUDIO_CARD_LIST+=	gus
>+.endif
>+
>+.if defined(AUDIO_CARD_LIST)
>+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
>+.endif
>+
> .if defined(WITH_SAMBA)
> RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
> .endif
>
>Signed-off-by: Carlos Santos <unixmania@gmail.com>

Hmm.  I might just add one knob to compile in all of these instead,
they are still to be enabled individually at runtime, right?

 Thanx,
	Juergen