From remodeler at alentogroup.org Sun Nov 1 00:41:57 2009 From: remodeler at alentogroup.org (remodeler) Date: Sun Nov 1 00:42:04 2009 Subject: dumpon to an encrypted swap partition? Message-ID: <20091101004815.M83360@alentogroup.org> I am running 8.0 RC1 on a multi-user server with a few dozen vnet-enabled jails and netgraph. The swap partition is encrypted by its /etc/fstab entry, like: /dev/ad2s1b.eli none swap sw 0 0 I am getting sporadic kernel panics on reboot, during the GEOM_JOURNAL shutdown sequence. However, they occur after geli detaches the swap partition, so I get an error like: Cannot dump. Device not defined or unavailable. I know I can set dumpdev in /etc/rc.conf to a file rather than a swap partition, but is there a way to (1) have an encrypted swap partition, and (2) dump a core to a swap partition without failure? If I set up a second unencrypted swap, I can't let the system write potentially confidential information into that space. Also, at the end of the panic, I get the message: Automatic reboot in 15 seconds - press a key on the console to abort but then the server hangs and requires manual power-down and reboot. I thought a reboot was inevitable after a kernel panic - that nothing could prevent it in terms of misbehaving processes, etc. Any idea what could cause such a freeze? Thank you. From =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= Sun Nov 1 09:00:22 2009 From: =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= (=?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?=) Date: Sun Nov 1 09:00:30 2009 Subject: make release stop at Creating ISO imagess (success) In-Reply-To: <20091026163950.56716v4m76bon23q@webmail.tint.or.th> References: <20091026143639.13895c34kml7gmmf@webmail.tint.or.th> <20091026095317.GA72492@ei.bzerk.org> <20091026163950.56716v4m76bon23q@webmail.tint.or.th> Message-ID: <20091101153301.687649jdv7towzi5@webmail.tint.or.th> Quoting ????? ??????? : > Quoting Ruben de Groot : > >> On Mon, Oct 26, 2009 at 02:36:39PM +0700, ??????????????? >> ????????????????????? typed: >>> hi sirs, >>> >>> apologized me for disturbing this list but ireally have problem s. >>> i make my own release by follwoing document in releng articles. >>> >>> here is my command >>> >>> cd /usr/src/release >>> time make CHROOTDIR=/kaitag/KAITAG BUILDNAME=7.2-RELEASE \ >>> CVSROOT=/var/ftp/pub/ncvs RELEASETAG=RELENG_7_2_0_RELEASE \ >>> EXTSRCDIR=/usr/src EXTPORTSDIR=/usr/ports \ >>> DOC_LANG=en_US.ISO8859-1 NODOC=NO NOPORTS=NO \ >>> MAKE_DVD=YES MAKE_ISOS=YES CDROM=YES >>> RELEASEDISTFILES=/var/ftp/pub/distfiles \ >>> release >>> >>> the build process goes well but then fetching for cdrtools.tbz begin and >>> stop. >>> in my machine i have installed cdrtools and there is also mkisofs file >>> so i wonder why the script /usr/src/release/i386/mkisofsimages.sh >>> still fetching for cdrtools. >> >> Do you have the cdrtools.tbz package in /var/ftp/pub/distfiles ? >> > > thanks for your time but there is only cdrtools-2.01.tar.bz2 which > is source files for making cdrtools. i keep all packages in a > separate location, /usr/ports/packages/. > >> >> Ruben >> >> from previous errors without any reasons, my instinct tell me that i need to specify EXTLOCALDIR=/usr/local in command line as shown below ====>> begin wmc# time make CHROOTDIR=/kaitag/KAITAG BUILDNAME=7.2-RELEASE CVSROOT=/var/ftp/p ub/ncvs RELEASETAG=RELENG_7_2_0_RELEASE EXTSRCDIR=/usr/src DOC_LANG=en_US.ISO885 9-1 NODOC=NO NOPORTS=NO MAKE_ISOS=YES EXTLOCALDIR=/usr/local RELEASEDISTFILES=/v ar/ftp/pub/distfiles NOCDROM=NO NO_PREFETCHDISTFILES=YES release ====>> end and the result is from, vidcontrol -P + df -ki /mnt + tail -1 + set /dev/md0c 1391 1195 196 86% 24 38 39% /mnt + echo *** File system is 1440 K, 196 left *** File system is 1440 K, 196 left + echo *** 40000 bytes/inode, 38 left *** 40000 bytes/inode, 38 left + umount /mnt + mdconfig -d -u md0 touch floppies.2 touch floppies.3 Setting up FTP distribution area 0 blocks 0 blocks touch ftp.1 Release done + LC_ALL=C TZ=GMT date + echo >>> make release for i386 finished on Sun Nov 1 08:26:53 GMT 2009 >>> make release for i386 finished on Sun Nov 1 08:26:53 GMT 2009 + umount /dev 4866.762u 614.713s 1:55:26.63 79.1% -2242+1015k 210537+37161io 344084pf+2w anyway, there is no cdrom created since i put NOCDROM=NO in command line but where is did change to CDROM=YES and change target to rerelease, i get cdrom as desire. upto this point, release(7) need to be changed a bit. so also i need to experiment further for including packages into disc[123].iso with best regards, -- psr ????? ????????? ???? ?????????? http://makham.blogspot.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From gleb.kurtsou at gmail.com Sun Nov 1 15:14:58 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Sun Nov 1 15:15:05 2009 Subject: dumpon to an encrypted swap partition? In-Reply-To: <20091101004815.M83360@alentogroup.org> References: <20091101004815.M83360@alentogroup.org> Message-ID: <20091101151427.GA2846@tops> On (31/10/2009 19:59), remodeler wrote: > I am running 8.0 RC1 on a multi-user server with a few dozen vnet-enabled > jails and netgraph. The swap partition is encrypted by its /etc/fstab entry, like: > > /dev/ad2s1b.eli none swap sw 0 0 > > I am getting sporadic kernel panics on reboot, during the GEOM_JOURNAL > shutdown sequence. However, they occur after geli detaches the swap partition, > so I get an error like: > > Cannot dump. Device not defined or unavailable. As far as I remember you should configure dump device to be raw swap partition. Like /dev/ad2s1b in your case, and you can continue using it for encrypted swap. I suppose you are using one time passwords for swap partitions, so dump can't be restored after reboot anyway. But there are issues with saving dump from encrypted swap after reboot. See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/124747 It's about dependencies during startup and the patch from PR is not entirely correct/complete. > I know I can set dumpdev in /etc/rc.conf to a file rather than a swap > partition, but is there a way to (1) have an encrypted swap partition, and (2) > dump a core to a swap partition without failure? If I set up a second > unencrypted swap, I can't let the system write potentially confidential > information into that space. No, using file as dumpdev is impossible, not all device drivers support crash dumps (because after kernel panic all interrupts are masked, acquiring mutex always succeeds, driver should be able to operate in poling mode, etc). I've never tried, but it seems dumping to umass devices should be supported now, if you are concerned with security. Otherwise solution would be to create special unencrypted partition for dumps. > Also, at the end of the panic, I get the message: > > Automatic reboot in 15 seconds - press a key on the console to abort > > but then the server hangs and requires manual power-down and reboot. I thought > a reboot was inevitable after a kernel panic - that nothing could prevent it > in terms of misbehaving processes, etc. Any idea what could cause such a freeze? > > Thank you. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From des at des.no Sun Nov 1 16:36:40 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sun Nov 1 16:36:46 2009 Subject: help needed to fix contrib/ee crash/exit when receiving SIGWINCH In-Reply-To: (Alexander Best's message of "Sat, 31 Oct 2009 14:30:47 +0100 (CET)") References: Message-ID: <86bpjmkxre.fsf@ds4.des.no> Alexander Best writes: > great news. so should the PR be closed or should it remain in patched state in > order for 7.x to get patched? Set it to "patched" until you've merged the patch to 6, 7 and 8 (IIRC, 6 has the new ncurses as well) > another question: how about our ncurses base version in general? should it > remain the ncurses release version with our own patchset or would it be better > to update it more frequently with the official ncurses patchsets? i guess this > is the way acpi in the base dir is being handled. vendor updates get > integrated on the fly into the base dir. I would just import releases, unless there is a compelling reason to import a patchset (i.e. it fixes a serious bug and we can't easily apply just that one patch). DES -- Dag-Erling Sm?rgrav - des@des.no From m.boyarov at gmail.com Mon Nov 2 14:25:07 2009 From: m.boyarov at gmail.com (Max Boyarov) Date: Mon Nov 2 14:25:14 2009 Subject: strange gdb behavior Message-ID: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> Hi, Who could help understand this: `--> cat 1.c int main(int argc, char **argv) { return 0; } `--> cc -ggdb -o 1 1.c `--> gdb 1 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 "i386-marcel-freebsd"... (gdb) set args test (gdb) b main Breakpoint 1 at 0x80483d0: file 1.c, line 3. (gdb) r Starting program: /tmp/1 test Breakpoint 1, main () at 1.c:3 3 { (gdb) print argc Error accessing memory address 0x0: Bad address. (gdb) list 1 int 2 main(int argc, char **argv) 3 { 4 return 0; 5 } checked on 9.0-CURRENT, 8.0-BETA3 -- // Max N. Boyarov From shuvaev at physik.uni-wuerzburg.de Mon Nov 2 15:42:19 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Mon Nov 2 15:42:26 2009 Subject: strange gdb behavior In-Reply-To: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> Message-ID: <20091102154212.GA30365@wep4035.physik.uni-wuerzburg.de> On Mon, Nov 02, 2009 at 03:52:33PM +0200, Max Boyarov wrote: > Hi, > > Who could help understand this: > > `--> cat 1.c > int > main(int argc, char **argv) > { > return 0; > } > > [snip] > > (gdb) set args test > (gdb) b main > Breakpoint 1 at 0x80483d0: file 1.c, line 3. > (gdb) r > Starting program: /tmp/1 test > > Breakpoint 1, main () at 1.c:3 > 3 { > (gdb) print argc > Error accessing memory address 0x0: Bad address. > (gdb) list > 1 int > 2 main(int argc, char **argv) > 3 { > 4 return 0; > 5 } > > checked on 9.0-CURRENT, 8.0-BETA3 > On FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198671: Fri Oct 30 16:12:10 CET 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 I have the following: (gdb) set args test (gdb) b main Breakpoint 1 at 0x40052b: file 1.c, line 4. (gdb) r Starting program: /home/lexx/1 test Breakpoint 1, main (argc=2, argv=0x7fffffffe790) at 1.c:4 4 return 0; (gdb) list 1 int 2 main(int argc, char **argv) 3 { 4 return 0; 5 } (gdb) print argc $1 = 2 (gdb) Note that the breakpoint is set to line 4, not line 3 as in your case. There was a series of changes to the linker recently. Update to the latest CURRENT might help. HTH, Alexey. From kostikbel at gmail.com Mon Nov 2 15:51:50 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Nov 2 15:51:57 2009 Subject: strange gdb behavior In-Reply-To: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> Message-ID: <20091102155144.GU2147@deviant.kiev.zoral.com.ua> On Mon, Nov 02, 2009 at 03:52:33PM +0200, Max Boyarov wrote: > Hi, > > Who could help understand this: > > `--> cat 1.c > int > main(int argc, char **argv) > { > return 0; > } > > > `--> cc -ggdb -o 1 1.c > > > `--> gdb 1 > 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 "i386-marcel-freebsd"... > (gdb) set args test > (gdb) b main > Breakpoint 1 at 0x80483d0: file 1.c, line 3. > (gdb) r > Starting program: /tmp/1 test > > Breakpoint 1, main () at 1.c:3 > 3 { > (gdb) print argc > Error accessing memory address 0x0: Bad address. > (gdb) list > 1 int > 2 main(int argc, char **argv) > 3 { > 4 return 0; > 5 } > > checked on 9.0-CURRENT, 8.0-BETA3 Can you check it on RELENG_7 ? It seems to be another old gdb bug. With gdb 7.0, (gdb) b main Breakpoint 1 at 0x8048414: file hello.c, line 8. (gdb) r Starting program: /usr/home/kostik/build/bsd/6/stuff/hello1 Breakpoint 1, main (argc=1, argv=0xbfbfe53c) at hello.c:8 8 for (i = 0; i < argc; i++) while in-tree gdb shows me the same behaviour as yours. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091102/372b0a3d/attachment.pgp From rysto32 at gmail.com Mon Nov 2 18:24:15 2009 From: rysto32 at gmail.com (Ryan Stone) Date: Mon Nov 2 18:24:21 2009 Subject: MIPS: bus_dma(9) and cache problems In-Reply-To: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> References: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> Message-ID: > What sync operation are you doing? ?At least for PREREAD or PREWRITE, > I'd expect any dirty cache lines to be flushed to RAM. ?If this isn't > happening, then you may want to submit a bug report. For a PREREAD, I don't believe that it's correct to flush a dirty cache line to RAM. That would overwrite whatever had been DMA'ed into that cache line. What about the following procedure for a PREREAD for a non-cache aligned buffer I'll call dma_buf 1) read the entire cache line into a buffer, buf1 2) issue the invalidate 3) copy the portion of buf1 that preceeds dma_buf back to that address One problem I can see immediately is that there is a race here: if something tries to access the memory preceeding dma_buf after the invalidate is issued but before the copy completes they will see inconsistent data. Maybe somebody else can think of a way around that. Ryan Stone From jason.harmening at gmail.com Mon Nov 2 19:33:10 2009 From: jason.harmening at gmail.com (Jason Harmening) Date: Mon Nov 2 19:53:15 2009 Subject: MIPS: bus_dma(9) and cache problems In-Reply-To: References: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> Message-ID: <2d1264630911021133uf3033deu20b41adfe54f62c2@mail.gmail.com> On Mon, Nov 2, 2009 at 12:24 PM, Ryan Stone wrote: >> What sync operation are you doing? ?At least for PREREAD or PREWRITE, >> I'd expect any dirty cache lines to be flushed to RAM. ?If this isn't >> happening, then you may want to submit a bug report. > > For a PREREAD, I don't believe that it's correct to flush a dirty > cache line to RAM. ?That would overwrite whatever had been DMA'ed into > that cache line. > I don't think that should matter--if you're issuing a PREREAD, *before* the start of a DMA transfer, the CPU either doesn't care about what's currently in the part of the line that is to be DMA'ed into (because it's about to be overwritten by the device anyway), or it's finished accessing what's in there from a previous DMA operation (in which case you'd expect it to either be present in the cache or already flushed out by something else anyway). But the basic idea is that the CPU shouldn't access the cache line from the time the PRE-whatever operation is issued to the time the POST-whatever operation is issued, so if you have multiple threads (anywhere on the system) accessing that line, you could be screwed. Heh, I just noticed the copyright at the top of the MIPS busdma implementation--apparently you ARE familiar w/ the MIPS sync implementation :) From jhb at freebsd.org Mon Nov 2 20:46:31 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 2 20:46:38 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: References: Message-ID: <200911021028.43044.jhb@freebsd.org> On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > John Baldwin schrieb am 2009-10-21: > > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote: > > > although the mmap(2) manual states in section MAP_ANON: > > > > "The offset argument is ignored." > > > > this doesn't seem to be true. running > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1, > > > 0x12345678)); > > > > and > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1, > > > 0)); > > > > produces different outputs. i've attached a patch to solve the > > > problem. the > > > patch is similar to the one proposed in this PR, but should apply > > > cleanly to > > > CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > A simpler patch would be to simply set pos = 0 below the MAP_STACK > > line if > > MAP_ANON is set. > > how about the following patch. problem seems to be that pos = 0 needs to be > set before pageoff is being calculated. I think that that patch is fine, but will defer to alc@. I think he argued that any non-zero offset passed to MAP_ANON should fail with EINVAL. -- John Baldwin From alexbestms at math.uni-muenster.de Mon Nov 2 21:05:59 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 2 21:06:07 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <200911021028.43044.jhb@freebsd.org> Message-ID: John Baldwin schrieb am 2009-11-02: > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > > John Baldwin schrieb am 2009-10-21: > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote: > > > > although the mmap(2) manual states in section MAP_ANON: > > > > "The offset argument is ignored." > > > > this doesn't seem to be true. running > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, > > > > -1, > > > > 0x12345678)); > > > > and > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, > > > > -1, > > > > 0)); > > > > produces different outputs. i've attached a patch to solve the > > > > problem. the > > > > patch is similar to the one proposed in this PR, but should > > > > apply > > > > cleanly to > > > > CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > A simpler patch would be to simply set pos = 0 below the > > > MAP_STACK > > > line if > > > MAP_ANON is set. > > how about the following patch. problem seems to be that pos = 0 > > needs to be > > set before pageoff is being calculated. > I think that that patch is fine, but will defer to alc@. I think he > argued > that any non-zero offset passed to MAP_ANON should fail with EINVAL. thanks. if that's what the POSIX standard requests that's ok. however in that case we need to change the mmap(2) manual, because right now it says in section MAP_ANON: "The offset argument is ignored." which should be changed to something like: "The offset argument must be zero." also if the behaviour of MAP_ANON changes this also changes the semantics of MAP_STACK since it implies MAP_ANON. so we need to decide if MAP_STACK should silently reset any offset value to zero or like MAP_ANON should fail if offset isn't zero in which case the MAP_STACK section of the mmap(2) manual needs to be changed to someting like: "MAP_STACK implies MAP_ANON, and requires offset to be zero." cheers. alex From alexbestms at math.uni-muenster.de Mon Nov 2 21:32:32 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 2 21:32:39 2009 Subject: help needed to fix contrib/ee crash/exit when receiving SIGWINCH In-Reply-To: <86bpjmkxre.fsf@ds4.des.no> Message-ID: Dag-Erling Sm?rgrav schrieb am 2009-11-01: > Alexander Best writes: > > great news. so should the PR be closed or should it remain in > > patched state in > > order for 7.x to get patched? > Set it to "patched" until you've merged the patch to 6, 7 and 8 > (IIRC, 6 > has the new ncurses as well) ok. the pr stays in patched state. right now the patch is in HEAD, 8-STABLE and 8.0-RELEASE. rafan is thinking about mfc'ing the patch to 6-stable and 7-stable. however if somebody is willing to modify the patch so it applies to those branches that'll be great > > another question: how about our ncurses base version in general? > > should it > > remain the ncurses release version with our own patchset or would > > it be better > > to update it more frequently with the official ncurses patchsets? i > > guess this > > is the way acpi in the base dir is being handled. vendor updates > > get > > integrated on the fly into the base dir. > I would just import releases, unless there is a compelling reason to > import a patchset (i.e. it fixes a serious bug and we can't easily > apply > just that one patch). my thoughts exactly. ncurses in the base dir is quite up to date. however i personally think that other contributed software should really be updated (binutils e.g.). but that's another story. ;) > DES From jhb at freebsd.org Mon Nov 2 22:02:14 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 2 22:02:20 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: References: Message-ID: <200911021702.07938.jhb@freebsd.org> On Monday 02 November 2009 4:05:56 pm Alexander Best wrote: > John Baldwin schrieb am 2009-11-02: > > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > > > John Baldwin schrieb am 2009-10-21: > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote: > > > > > although the mmap(2) manual states in section MAP_ANON: > > > > > > "The offset argument is ignored." > > > > > > this doesn't seem to be true. running > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, > > > > > -1, > > > > > 0x12345678)); > > > > > > and > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, > > > > > -1, > > > > > 0)); > > > > > > produces different outputs. i've attached a patch to solve the > > > > > problem. the > > > > > patch is similar to the one proposed in this PR, but should > > > > > apply > > > > > cleanly to > > > > > CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > > > A simpler patch would be to simply set pos = 0 below the > > > > MAP_STACK > > > > line if > > > > MAP_ANON is set. > > > > how about the following patch. problem seems to be that pos = 0 > > > needs to be > > > set before pageoff is being calculated. > > > I think that that patch is fine, but will defer to alc@. I think he > > argued > > that any non-zero offset passed to MAP_ANON should fail with EINVAL. > > thanks. if that's what the POSIX standard requests that's ok. however in that > case we need to change the mmap(2) manual, because right now it says in > section MAP_ANON: > > "The offset argument is ignored." > > which should be changed to something like: > > "The offset argument must be zero." > > also if the behaviour of MAP_ANON changes this also changes the semantics of > MAP_STACK since it implies MAP_ANON. so we need to decide if MAP_STACK should > silently reset any offset value to zero or like MAP_ANON should fail if offset > isn't zero in which case the MAP_STACK section of the mmap(2) manual needs to > be changed to someting like: > > "MAP_STACK implies MAP_ANON, and requires offset to be zero." Right now MAP_STACK sets pos to 0 in the current code, and I don't expect we would remove that if we decide to reject non-zero offsets for MAP_ANON. I'd probably rather err on the side of leniency and just ignore the offset rather than rejecting non-zero, but I'm a bit burned from the last round of mmap() API changes. :) -- John Baldwin From alexbestms at math.uni-muenster.de Mon Nov 2 22:14:29 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 2 22:14:37 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <200911021702.07938.jhb@freebsd.org> Message-ID: John Baldwin schrieb am 2009-11-02: > On Monday 02 November 2009 4:05:56 pm Alexander Best wrote: > > John Baldwin schrieb am 2009-11-02: > > > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > > > > John Baldwin schrieb am 2009-10-21: > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best > > > > > wrote: > > > > > > although the mmap(2) manual states in section MAP_ANON: > > > > > > "The offset argument is ignored." > > > > > > this doesn't seem to be true. running > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > MAP_ANON, > > > > > > -1, > > > > > > 0x12345678)); > > > > > > and > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > MAP_ANON, > > > > > > -1, > > > > > > 0)); > > > > > > produces different outputs. i've attached a patch to solve > > > > > > the > > > > > > problem. the > > > > > > patch is similar to the one proposed in this PR, but should > > > > > > apply > > > > > > cleanly to > > > > > > CURRENT: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > > > A simpler patch would be to simply set pos = 0 below the > > > > > MAP_STACK > > > > > line if > > > > > MAP_ANON is set. > > > > how about the following patch. problem seems to be that pos = 0 > > > > needs to be > > > > set before pageoff is being calculated. > > > I think that that patch is fine, but will defer to alc@. I think > > > he > > > argued > > > that any non-zero offset passed to MAP_ANON should fail with > > > EINVAL. > > thanks. if that's what the POSIX standard requests that's ok. > > however in that > > case we need to change the mmap(2) manual, because right now it > > says in > > section MAP_ANON: > > "The offset argument is ignored." > > which should be changed to something like: > > "The offset argument must be zero." > > also if the behaviour of MAP_ANON changes this also changes the > > semantics of > > MAP_STACK since it implies MAP_ANON. so we need to decide if > > MAP_STACK should > > silently reset any offset value to zero or like MAP_ANON should > > fail if offset > > isn't zero in which case the MAP_STACK section of the mmap(2) > > manual needs to > > be changed to someting like: > > "MAP_STACK implies MAP_ANON, and requires offset to be zero." > Right now MAP_STACK sets pos to 0 in the current code, and I don't > expect we > would remove that if we decide to reject non-zero offsets for > MAP_ANON. I'd > probably rather err on the side of leniency and just ignore the > offset rather > than rejecting non-zero, but I'm a bit burned from the last round of > mmap() > API changes. :) hmmm...i think this will require quite a few changes. if i remember correctly MAP_STACK at some point does: flags =| MAP_ANON; so if we decide MAP_ANON and MAP_STACK should behave differently this will require some checks to distinguish between both flags further down in the code. let's see what alc@ thinks about this one then. API changes are a nasty nasty business. ;) From rea-fbsd at codelabs.ru Tue Nov 3 07:26:20 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Nov 3 07:26:27 2009 Subject: help needed to fix contrib/ee crash/exit when receiving SIGWINCH In-Reply-To: References: <86bpjmkxre.fsf@ds4.des.no> Message-ID: Mon, Nov 02, 2009 at 10:32:29PM +0100, Alexander Best wrote: > ok. the pr stays in patched state. right now the patch is in HEAD, > 8-STABLE and 8.0-RELEASE. rafan is thinking about mfc'ing the patch to > 6-stable and 7-stable. however if somebody is willing to modify the > patch so it applies to those branches that'll be great Patch applies cleanly to the 7-STABLE, moreover, lib_getch.c from it has the same logics and fifo_push is essentially unmodified in the areas that are relevant for this flaw. I had patched 7-STABLE on the test machine, brought ee from 8.x and verified that unpatched ncurses give immediate exit, while patched curses give working ee in respect to the SIGWINCH. I had also mildly tested vi and sysinstall on the patched 7-STABLE and found no visible regressions. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From nick at van-laarhoven.org Tue Nov 3 10:52:55 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Nov 3 10:53:11 2009 Subject: Mesh networking Message-ID: Anyone interested in Mesh networking might want to have a look at http://meshcom.com/en/products/meshdriver/ We have started to use the mesh driver (ok, on voyage linux). A port should not be difficult, especially the userland daemon. It's dependencies on Linux syscalls are minimal. Starting it through linux emulation does not work (in my FreeBSD setup). Meshcom says they are happy to look at the port when it is done. Cheers, Nick P.S.: I am not affiliated to them other than that I am very impressed with the quality of the software. From m.boyarov at gmail.com Tue Nov 3 11:19:42 2009 From: m.boyarov at gmail.com (Max N. Boyarov) Date: Tue Nov 3 11:19:49 2009 Subject: strange gdb behavior In-Reply-To: <20091102155144.GU2147@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 2 Nov 2009 17:51:44 +0200") References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> <20091102155144.GU2147@deviant.kiev.zoral.com.ua> Message-ID: <7jws274zzq.fsf@bsd.by> Kostik Belousov writes: > On Mon, Nov 02, 2009 at 03:52:33PM +0200, Max Boyarov wrote: >> Hi, [cut] > > Can you check it on RELENG_7 ? It seems to be another old gdb bug. > With gdb 7.0, > (gdb) b main > Breakpoint 1 at 0x8048414: file hello.c, line 8. > (gdb) r > Starting program: /usr/home/kostik/build/bsd/6/stuff/hello1 > > Breakpoint 1, main (argc=1, argv=0xbfbfe53c) at hello.c:8 > 8 for (i = 0; i < argc; i++) > > while in-tree gdb shows me the same behaviour as yours. $ cat gdbt.c #include int main(int argc, char **argv) { int t; t = getopt(argc, argv, "f:"); return t; } $ cat gdbt.gdb b main run print &argc next print &argc list quit $ cat gdbt.sh #!/bin/sh uname -mr cc -O0 -ggdb -o gdbt gdbt.c && gdb -nx -quiet -x gdbt.gdb gdbt 9.0-CURRENT i386 / r198846 Breakpoint 1 at 0x80483f0: file gdbt.c, line 5. Breakpoint 1, main (argc=Error accessing memory address 0x2: Bad address. ) at gdbt.c:5 5 { $1 = (int *) 0x2 main (argc=1, argv=0xbfbfe7e0) at gdbt.c:8 8 t = getopt(argc, argv, "f:"); $2 = (int *) 0xbfbfe7c0 3 int 4 main(int argc, char **argv) 5 { 6 int t; 7 8 t = getopt(argc, argv, "f:"); 9 10 return t; 11 } 9.0-CURRENT amd64 /r198480 Breakpoint 1 at 0x40057f: file gdbt.c, line 8. Breakpoint 1, main (argc=1, argv=0x7fffffffeac0) at gdbt.c:8 8 t = getopt(argc, argv, "f:"); $1 = (int *) 0x7fffffffea5c 10 return t; $2 = (int *) 0x7fffffffea5c 5 { 6 int t; 7 8 t = getopt(argc, argv, "f:"); 9 10 return t; 11 } 7.2-RELEASE-p1 i386 Breakpoint 1 at 0x8048400: file gdbt.c, line 5. Breakpoint 1, main (argc=Error accessing memory address 0x2: Bad address. ) at gdbt.c:5 5 { $1 = (int *) 0x2 main (argc=1, argv=0xbfbfeca4) at gdbt.c:8 8 t = getopt(argc, argv, "f:"); $2 = (int *) 0xbfbfec80 3 int 4 main(int argc, char **argv) 5 { 6 int t; 7 8 t = getopt(argc, argv, "f:"); 9 10 return t; 11 } 7.2-RELEASE-p4 amd64 Breakpoint 1 at 0x40057f: file gdbt.c, line 8. Breakpoint 1, main (argc=1, argv=0x7fffffffebc8) at gdbt.c:8 8 t = getopt(argc, argv, "f:"); $1 = (int *) 0x7fffffffeb5c 10 return t; $2 = (int *) 0x7fffffffeb5c 5 { 6 int t; 7 8 t = getopt(argc, argv, "f:"); 9 10 return t; 11 } -- Max N. Boyarov xmpp:zotrix@jabber.ru From des at des.no Tue Nov 3 11:35:34 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Nov 3 11:35:43 2009 Subject: strange gdb behavior In-Reply-To: <7jws274zzq.fsf@bsd.by> (Max N. Boyarov's message of "Tue, 03 Nov 2009 13:19:37 +0200") References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> <20091102155144.GU2147@deviant.kiev.zoral.com.ua> <7jws274zzq.fsf@bsd.by> Message-ID: <86zl73n8mz.fsf@ds4.des.no> m.boyarov@gmail.com (Max N. Boyarov) writes: > 9.0-CURRENT i386 / r198846 > [broken] > 9.0-CURRENT amd64 /r198480 > [works] > 7.2-RELEASE-p1 i386 > [broken] > 7.2-RELEASE-p4 amd64 > [works] See a pattern? DES -- Dag-Erling Sm?rgrav - des@des.no From lihong at ieee.org Tue Nov 3 13:07:56 2009 From: lihong at ieee.org (Eric) Date: Tue Nov 3 13:11:12 2009 Subject: Mesh networking In-Reply-To: References: Message-ID: <1257251738.2188.4.camel@localhost> On Tue, 2009-11-03 at 11:52 +0100, Nick Hibma wrote: > Anyone interested in Mesh networking might want to have a look at > > http://meshcom.com/en/products/meshdriver/ > > We have started to use the mesh driver (ok, on voyage linux). A port > should not be difficult, especially the userland daemon. It's > dependencies on Linux syscalls are minimal. > > Starting it through linux emulation does not work (in my FreeBSD setup). > > Meshcom says they are happy to look at the port when it is done. > > Cheers, > > Nick > > P.S.: I am not affiliated to them other than that I am very impressed > with the quality of the software. Does it IEEE 802.20 compliant? -- Best Regards, Eric L. Chen From lihong at ieee.org Tue Nov 3 13:24:54 2009 From: lihong at ieee.org (Eric) Date: Tue Nov 3 13:25:00 2009 Subject: Mesh networking In-Reply-To: <1257251738.2188.4.camel@localhost> References: <1257251738.2188.4.camel@localhost> Message-ID: <1257254687.2188.5.camel@localhost> On Tue, 2009-11-03 at 20:35 +0800, Eric wrote: > On Tue, 2009-11-03 at 11:52 +0100, Nick Hibma wrote: > > Anyone interested in Mesh networking might want to have a look at > > > > http://meshcom.com/en/products/meshdriver/ > > > > We have started to use the mesh driver (ok, on voyage linux). A port > > should not be difficult, especially the userland daemon. It's > > dependencies on Linux syscalls are minimal. > > > > Starting it through linux emulation does not work (in my FreeBSD setup). > > > > Meshcom says they are happy to look at the port when it is done. > > > > Cheers, > > > > Nick > > > > P.S.: I am not affiliated to them other than that I am very impressed > > with the quality of the software. > > Does it IEEE 802.20 compliant? > Sorry, I mean 802.21. /Eric From nick at van-laarhoven.org Tue Nov 3 14:13:29 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Nov 3 14:27:28 2009 Subject: Mesh networking In-Reply-To: <1257251738.2188.4.camel@localhost> References: <1257251738.2188.4.camel@localhost> Message-ID: <5D1658C3-537E-4A97-B6E2-FFE9AF3E87D6@van-laarhoven.org> It's their own variation on AODV I believe. Nick On 3 Nov 2009, at 13:35, Eric wrote: > On Tue, 2009-11-03 at 11:52 +0100, Nick Hibma wrote: >> Anyone interested in Mesh networking might want to have a look at >> >> http://meshcom.com/en/products/meshdriver/ >> >> We have started to use the mesh driver (ok, on voyage linux). A port >> should not be difficult, especially the userland daemon. It's >> dependencies on Linux syscalls are minimal. >> >> Starting it through linux emulation does not work (in my FreeBSD >> setup). >> >> Meshcom says they are happy to look at the port when it is done. >> >> Cheers, >> >> Nick >> >> P.S.: I am not affiliated to them other than that I am very impressed >> with the quality of the software. > > Does it IEEE 802.20 compliant? > > -- > Best Regards, > Eric L. Chen > From jhb at freebsd.org Tue Nov 3 14:32:38 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Nov 3 14:46:02 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: References: Message-ID: <200911030932.24583.jhb@freebsd.org> On Monday 02 November 2009 5:14:27 pm Alexander Best wrote: > John Baldwin schrieb am 2009-11-02: > > On Monday 02 November 2009 4:05:56 pm Alexander Best wrote: > > > John Baldwin schrieb am 2009-11-02: > > > > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > > > > > John Baldwin schrieb am 2009-10-21: > > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best > > > > > > wrote: > > > > > > > although the mmap(2) manual states in section MAP_ANON: > > > > > > > > "The offset argument is ignored." > > > > > > > > this doesn't seem to be true. running > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > > MAP_ANON, > > > > > > > -1, > > > > > > > 0x12345678)); > > > > > > > > and > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > > MAP_ANON, > > > > > > > -1, > > > > > > > 0)); > > > > > > > > produces different outputs. i've attached a patch to solve > > > > > > > the > > > > > > > problem. the > > > > > > > patch is similar to the one proposed in this PR, but should > > > > > > > apply > > > > > > > cleanly to > > > > > > > CURRENT: > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > > > > > A simpler patch would be to simply set pos = 0 below the > > > > > > MAP_STACK > > > > > > line if > > > > > > MAP_ANON is set. > > > > > > how about the following patch. problem seems to be that pos = 0 > > > > > needs to be > > > > > set before pageoff is being calculated. > > > > > I think that that patch is fine, but will defer to alc@. I think > > > > he > > > > argued > > > > that any non-zero offset passed to MAP_ANON should fail with > > > > EINVAL. > > > > thanks. if that's what the POSIX standard requests that's ok. > > > however in that > > > case we need to change the mmap(2) manual, because right now it > > > says in > > > section MAP_ANON: > > > > "The offset argument is ignored." > > > > which should be changed to something like: > > > > "The offset argument must be zero." > > > > also if the behaviour of MAP_ANON changes this also changes the > > > semantics of > > > MAP_STACK since it implies MAP_ANON. so we need to decide if > > > MAP_STACK should > > > silently reset any offset value to zero or like MAP_ANON should > > > fail if offset > > > isn't zero in which case the MAP_STACK section of the mmap(2) > > > manual needs to > > > be changed to someting like: > > > > "MAP_STACK implies MAP_ANON, and requires offset to be zero." > > > Right now MAP_STACK sets pos to 0 in the current code, and I don't > > expect we > > would remove that if we decide to reject non-zero offsets for > > MAP_ANON. I'd > > probably rather err on the side of leniency and just ignore the > > offset rather > > than rejecting non-zero, but I'm a bit burned from the last round of > > mmap() > > API changes. :) > > hmmm...i think this will require quite a few changes. if i remember correctly > MAP_STACK at some point does: > > flags =| MAP_ANON; > > so if we decide MAP_ANON and MAP_STACK should behave differently this will > require some checks to distinguish between both flags further down in the > code. > > let's see what alc@ thinks about this one then. API changes are a nasty nasty > business. ;) Umm, if you revert your change and just add a simple clause that does: if (flags & MAP_ANON && pos != 0) return (EINVAL); after the MAP_STACK section then I think that would work fine. It would not require any further magic apart from that. -- John Baldwin From alexbestms at math.uni-muenster.de Tue Nov 3 15:50:40 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 15:54:58 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <200911030932.24583.jhb@freebsd.org> Message-ID: John Baldwin schrieb am 2009-11-03: > On Monday 02 November 2009 5:14:27 pm Alexander Best wrote: > > John Baldwin schrieb am 2009-11-02: > > > On Monday 02 November 2009 4:05:56 pm Alexander Best wrote: > > > > John Baldwin schrieb am 2009-11-02: > > > > > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > > > > > > John Baldwin schrieb am 2009-10-21: > > > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best > > > > > > > wrote: > > > > > > > > although the mmap(2) manual states in section MAP_ANON: > > > > > > > > "The offset argument is ignored." > > > > > > > > this doesn't seem to be true. running > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > > > MAP_ANON, > > > > > > > > -1, > > > > > > > > 0x12345678)); > > > > > > > > and > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > > > MAP_ANON, > > > > > > > > -1, > > > > > > > > 0)); > > > > > > > > produces different outputs. i've attached a patch to > > > > > > > > solve > > > > > > > > the > > > > > > > > problem. the > > > > > > > > patch is similar to the one proposed in this PR, but > > > > > > > > should > > > > > > > > apply > > > > > > > > cleanly to > > > > > > > > CURRENT: > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > > > > > A simpler patch would be to simply set pos = 0 below the > > > > > > > MAP_STACK > > > > > > > line if > > > > > > > MAP_ANON is set. > > > > > > how about the following patch. problem seems to be that pos > > > > > > = 0 > > > > > > needs to be > > > > > > set before pageoff is being calculated. > > > > > I think that that patch is fine, but will defer to alc@. I > > > > > think > > > > > he > > > > > argued > > > > > that any non-zero offset passed to MAP_ANON should fail with > > > > > EINVAL. > > > > thanks. if that's what the POSIX standard requests that's ok. > > > > however in that > > > > case we need to change the mmap(2) manual, because right now it > > > > says in > > > > section MAP_ANON: > > > > "The offset argument is ignored." > > > > which should be changed to something like: > > > > "The offset argument must be zero." > > > > also if the behaviour of MAP_ANON changes this also changes the > > > > semantics of > > > > MAP_STACK since it implies MAP_ANON. so we need to decide if > > > > MAP_STACK should > > > > silently reset any offset value to zero or like MAP_ANON should > > > > fail if offset > > > > isn't zero in which case the MAP_STACK section of the mmap(2) > > > > manual needs to > > > > be changed to someting like: > > > > "MAP_STACK implies MAP_ANON, and requires offset to be zero." > > > Right now MAP_STACK sets pos to 0 in the current code, and I > > > don't > > > expect we > > > would remove that if we decide to reject non-zero offsets for > > > MAP_ANON. I'd > > > probably rather err on the side of leniency and just ignore the > > > offset rather > > > than rejecting non-zero, but I'm a bit burned from the last round > > > of > > > mmap() > > > API changes. :) > > hmmm...i think this will require quite a few changes. if i remember > correctly > > MAP_STACK at some point does: > > flags =| MAP_ANON; > > so if we decide MAP_ANON and MAP_STACK should behave differently > > this will > > require some checks to distinguish between both flags further down > > in the > > code. > > let's see what alc@ thinks about this one then. API changes are a > > nasty > nasty > > business. ;) > Umm, if you revert your change and just add a simple clause that > does: > if (flags & MAP_ANON && pos != 0) > return (EINVAL); > after the MAP_STACK section then I think that would work fine. It > would > not require any further magic apart from that. oh. you're right. didn't think of that one. indeed this would let mmap fail with MAP_ANON and pos != 0, but would keep the current MAP_STACK behaviour (which is ignoring pos). sounds like a really clean and useful mmap API change. if alc@ agrees i could put your change in the form of a patch and together with a mmap(2) manual change, submit it as followup to kern/71258. it shouldn't be a big deal mfc'ing the changes to 8-stable (maybe even 8.0-release), 7-stable and 6-stable. well...better make that 8.1-release. ;) who knows what weird mmap calls are in the ports. ;) i'll try to build universe over the night to see if the changes break anything. alex From alexbestms at math.uni-muenster.de Tue Nov 3 17:18:15 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 17:18:21 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: Message-ID: Alexander Best schrieb am 2009-11-03: > John Baldwin schrieb am 2009-11-03: > > On Monday 02 November 2009 5:14:27 pm Alexander Best wrote: > > > John Baldwin schrieb am 2009-11-02: > > > > On Monday 02 November 2009 4:05:56 pm Alexander Best wrote: > > > > > John Baldwin schrieb am 2009-11-02: > > > > > > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote: > > > > > > > John Baldwin schrieb am 2009-10-21: > > > > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best > > > > > > > > wrote: > > > > > > > > > although the mmap(2) manual states in section > > > > > > > > > MAP_ANON: > > > > > > > > > "The offset argument is ignored." > > > > > > > > > this doesn't seem to be true. running > > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > > > > MAP_ANON, > > > > > > > > > -1, > > > > > > > > > 0x12345678)); > > > > > > > > > and > > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, > > > > > > > > > MAP_ANON, > > > > > > > > > -1, > > > > > > > > > 0)); > > > > > > > > > produces different outputs. i've attached a patch to > > > > > > > > > solve > > > > > > > > > the > > > > > > > > > problem. the > > > > > > > > > patch is similar to the one proposed in this PR, but > > > > > > > > > should > > > > > > > > > apply > > > > > > > > > cleanly to > > > > > > > > > CURRENT: > > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > > > > > > A simpler patch would be to simply set pos = 0 below > > > > > > > > the > > > > > > > > MAP_STACK > > > > > > > > line if > > > > > > > > MAP_ANON is set. > > > > > > > how about the following patch. problem seems to be that > > > > > > > pos > > > > > > > = 0 > > > > > > > needs to be > > > > > > > set before pageoff is being calculated. > > > > > > I think that that patch is fine, but will defer to alc@. I > > > > > > think > > > > > > he > > > > > > argued > > > > > > that any non-zero offset passed to MAP_ANON should fail > > > > > > with > > > > > > EINVAL. > > > > > thanks. if that's what the POSIX standard requests that's ok. > > > > > however in that > > > > > case we need to change the mmap(2) manual, because right now > > > > > it > > > > > says in > > > > > section MAP_ANON: > > > > > "The offset argument is ignored." > > > > > which should be changed to something like: > > > > > "The offset argument must be zero." > > > > > also if the behaviour of MAP_ANON changes this also changes > > > > > the > > > > > semantics of > > > > > MAP_STACK since it implies MAP_ANON. so we need to decide if > > > > > MAP_STACK should > > > > > silently reset any offset value to zero or like MAP_ANON > > > > > should > > > > > fail if offset > > > > > isn't zero in which case the MAP_STACK section of the mmap(2) > > > > > manual needs to > > > > > be changed to someting like: > > > > > "MAP_STACK implies MAP_ANON, and requires offset to be zero." > > > > Right now MAP_STACK sets pos to 0 in the current code, and I > > > > don't > > > > expect we > > > > would remove that if we decide to reject non-zero offsets for > > > > MAP_ANON. I'd > > > > probably rather err on the side of leniency and just ignore the > > > > offset rather > > > > than rejecting non-zero, but I'm a bit burned from the last > > > > round > > > > of > > > > mmap() > > > > API changes. :) > > > hmmm...i think this will require quite a few changes. if i > > > remember > > correctly > > > MAP_STACK at some point does: > > > flags =| MAP_ANON; > > > so if we decide MAP_ANON and MAP_STACK should behave differently > > > this will > > > require some checks to distinguish between both flags further > > > down > > > in the > > > code. > > > let's see what alc@ thinks about this one then. API changes are a > > > nasty > > nasty > > > business. ;) > > Umm, if you revert your change and just add a simple clause that > > does: > > if (flags & MAP_ANON && pos != 0) > > return (EINVAL); > > after the MAP_STACK section then I think that would work fine. It > > would > > not require any further magic apart from that. > oh. you're right. didn't think of that one. indeed this would let > mmap fail > with MAP_ANON and pos != 0, but would keep the current MAP_STACK > behaviour > (which is ignoring pos). > sounds like a really clean and useful mmap API change. if alc@ agrees > i could > put your change in the form of a patch and together with a mmap(2) > manual > change, submit it as followup to kern/71258. it shouldn't be a big > deal > mfc'ing the changes to 8-stable (maybe even 8.0-release), 7-stable > and > 6-stable. well...better make that 8.1-release. ;) who knows what > weird mmap > calls are in the ports. ;) > i'll try to build universe over the night to see if the changes break > anything. just realised that building universe or only world is pretty useless since the API changes only affect apps during runtime and at compilation time. :) i've run a few tests. the following app: #include #include #include main() { printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_STACK, -1, 1)); printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_ANON, -1, 1)); } outputs: 0x1000 0xffffffff as expected. #include #include #include main() { printf("%p\n", mmap((void*)0, 0x1000, PROT_READ|PROT_WRITE, MAP_STACK, -1, 0)); printf("%p\n", mmap((void*)0, 0x1000, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0)); } however produces this output: 0xffffffff 0x28195000 which seems a bit odd. the mmap(2) manual doesn't say anything about MAP_STACK not working when addr is zero. i'll see if this is caused by the changes jhb@ suggested or not. > alex From ed at 80386.nl Tue Nov 3 17:24:54 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Nov 3 17:25:01 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: References: Message-ID: <20091103172452.GU1293@hoeg.nl> Hi Alan, * Alan Cox wrote: > The standards for mmap(2) actually disallow values of "off" that are not a > multiple of the page size. > > See http://www.opengroup.org/onlinepubs/000095399/functions/mmap.html for > the following: > Just by accident I saw they changed that behaviour in a newer version of the spec: http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091103/64e98264/attachment.pgp From alexbestms at math.uni-muenster.de Tue Nov 3 17:40:54 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 17:41:01 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: Message-ID: Alexander Best schrieb am 2009-11-03: > Alexander Best schrieb am 2009-11-03: > > John Baldwin schrieb am 2009-11-03: > > > On Monday 02 November 2009 5:14:27 pm Alexander Best wrote: > > > > John Baldwin schrieb am 2009-11-02: > > > > > On Monday 02 November 2009 4:05:56 pm Alexander Best wrote: > > > > > > John Baldwin schrieb am 2009-11-02: > > > > > > > On Friday 30 October 2009 10:38:24 pm Alexander Best > > > > > > > wrote: > > > > > > > > John Baldwin schrieb am 2009-10-21: > > > > > > > > > On Wednesday 21 October 2009 11:51:04 am Alexander > > > > > > > > > Best > > > > > > > > > wrote: > > > > > > > > > > although the mmap(2) manual states in section > > > > > > > > > > MAP_ANON: > > > > > > > > > > "The offset argument is ignored." > > > > > > > > > > this doesn't seem to be true. running > > > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, > > > > > > > > > > PROT_NONE, > > > > > > > > > > MAP_ANON, > > > > > > > > > > -1, > > > > > > > > > > 0x12345678)); > > > > > > > > > > and > > > > > > > > > > printf("%p\n", mmap((void*)0x1000, 0x1000, > > > > > > > > > > PROT_NONE, > > > > > > > > > > MAP_ANON, > > > > > > > > > > -1, > > > > > > > > > > 0)); > > > > > > > > > > produces different outputs. i've attached a patch > > > > > > > > > > to > > > > > > > > > > solve > > > > > > > > > > the > > > > > > > > > > problem. the > > > > > > > > > > patch is similar to the one proposed in this PR, > > > > > > > > > > but > > > > > > > > > > should > > > > > > > > > > apply > > > > > > > > > > cleanly to > > > > > > > > > > CURRENT: > > > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258 > > > > > > > > > A simpler patch would be to simply set pos = 0 below > > > > > > > > > the > > > > > > > > > MAP_STACK > > > > > > > > > line if > > > > > > > > > MAP_ANON is set. > > > > > > > > how about the following patch. problem seems to be that > > > > > > > > pos > > > > > > > > = 0 > > > > > > > > needs to be > > > > > > > > set before pageoff is being calculated. > > > > > > > I think that that patch is fine, but will defer to alc@. > > > > > > > I > > > > > > > think > > > > > > > he > > > > > > > argued > > > > > > > that any non-zero offset passed to MAP_ANON should fail > > > > > > > with > > > > > > > EINVAL. > > > > > > thanks. if that's what the POSIX standard requests that's > > > > > > ok. > > > > > > however in that > > > > > > case we need to change the mmap(2) manual, because right > > > > > > now > > > > > > it > > > > > > says in > > > > > > section MAP_ANON: > > > > > > "The offset argument is ignored." > > > > > > which should be changed to something like: > > > > > > "The offset argument must be zero." > > > > > > also if the behaviour of MAP_ANON changes this also changes > > > > > > the > > > > > > semantics of > > > > > > MAP_STACK since it implies MAP_ANON. so we need to decide > > > > > > if > > > > > > MAP_STACK should > > > > > > silently reset any offset value to zero or like MAP_ANON > > > > > > should > > > > > > fail if offset > > > > > > isn't zero in which case the MAP_STACK section of the > > > > > > mmap(2) > > > > > > manual needs to > > > > > > be changed to someting like: > > > > > > "MAP_STACK implies MAP_ANON, and requires offset to be > > > > > > zero." > > > > > Right now MAP_STACK sets pos to 0 in the current code, and I > > > > > don't > > > > > expect we > > > > > would remove that if we decide to reject non-zero offsets for > > > > > MAP_ANON. I'd > > > > > probably rather err on the side of leniency and just ignore > > > > > the > > > > > offset rather > > > > > than rejecting non-zero, but I'm a bit burned from the last > > > > > round > > > > > of > > > > > mmap() > > > > > API changes. :) > > > > hmmm...i think this will require quite a few changes. if i > > > > remember > > > correctly > > > > MAP_STACK at some point does: > > > > flags =| MAP_ANON; > > > > so if we decide MAP_ANON and MAP_STACK should behave > > > > differently > > > > this will > > > > require some checks to distinguish between both flags further > > > > down > > > > in the > > > > code. > > > > let's see what alc@ thinks about this one then. API changes are > > > > a > > > > nasty > > > nasty > > > > business. ;) > > > Umm, if you revert your change and just add a simple clause that > > > does: > > > if (flags & MAP_ANON && pos != 0) > > > return (EINVAL); > > > after the MAP_STACK section then I think that would work fine. > > > It > > > would > > > not require any further magic apart from that. > > oh. you're right. didn't think of that one. indeed this would let > > mmap fail > > with MAP_ANON and pos != 0, but would keep the current MAP_STACK > > behaviour > > (which is ignoring pos). > > sounds like a really clean and useful mmap API change. if alc@ > > agrees > > i could > > put your change in the form of a patch and together with a mmap(2) > > manual > > change, submit it as followup to kern/71258. it shouldn't be a big > > deal > > mfc'ing the changes to 8-stable (maybe even 8.0-release), 7-stable > > and > > 6-stable. well...better make that 8.1-release. ;) who knows what > > weird mmap > > calls are in the ports. ;) > > i'll try to build universe over the night to see if the changes > > break > > anything. > just realised that building universe or only world is pretty useless > since the > API changes only affect apps during runtime and at compilation time. > :) > i've run a few tests. the following app: > #include > #include > #include > main() { > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE, > MAP_STACK, -1, 1)); > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_READ|PROT_WRITE, > MAP_ANON, > -1, 1)); > } > outputs: > 0x1000 > 0xffffffff > as expected. > #include > #include > #include > main() { > printf("%p\n", mmap((void*)0, 0x1000, PROT_READ|PROT_WRITE, > MAP_STACK, -1, > 0)); > printf("%p\n", mmap((void*)0, 0x1000, PROT_READ|PROT_WRITE, > MAP_ANON, -1, > 0)); > } > however produces this output: > 0xffffffff > 0x28195000 > which seems a bit odd. the mmap(2) manual doesn't say anything about > MAP_STACK > not working when addr is zero. > i'll see if this is caused by the changes jhb@ suggested or not. ok. checked it. not being caused by your changes. maybe i missed something and in fact MAP_STACK requires addr to be non zero. couldn't find it in the mmap(2) manual though. > > alex From alexbestms at math.uni-muenster.de Tue Nov 3 17:50:39 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 17:50:45 2009 Subject: help needed to fix contrib/ee crash/exit when receiving SIGWINCH In-Reply-To: Message-ID: Eygene Ryabinkin schrieb am 2009-11-03: > Mon, Nov 02, 2009 at 10:32:29PM +0100, Alexander Best wrote: > > ok. the pr stays in patched state. right now the patch is in HEAD, > > 8-STABLE and 8.0-RELEASE. rafan is thinking about mfc'ing the patch > > to > > 6-stable and 7-stable. however if somebody is willing to modify the > > patch so it applies to those branches that'll be great > Patch applies cleanly to the 7-STABLE, moreover, lib_getch.c from it > has the same logics and fifo_push is essentially unmodified in the > areas that are relevant for this flaw. > I had patched 7-STABLE on the test machine, brought ee from 8.x and > verified that unpatched ncurses give immediate exit, while patched > curses give working ee in respect to the SIGWINCH. > I had also mildly tested vi and sysinstall on the patched 7-STABLE > and found no visible regressions. great. so do we need/want the patch in 6.x? alex From mel.flynn+fbsd.hackers at mailing.thruhere.net Tue Nov 3 20:22:33 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Tue Nov 3 20:22:40 2009 Subject: Issue with grep -i (on i386 only?) Message-ID: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Hi, attached a little test script for grep's -i performance. I tried a few different machines and the 64-bit 7.2 machine I could steal doesn't seem to be affected and out performs pcregrep. On i386 machines, grep -i is significantly slower: i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00, Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free dev.cpu.0.freq: 2992 (Intel P-IV HTT enabled) 16Meg file result: =>>> 16777216 =>>> fgrep 0.04 real 0.02 user 0.01 sys 0.04 real 0.03 user 0.01 sys =>>> pcregrep 0.21 real 0.19 user 0.02 sys 0.21 real 0.20 user 0.00 sys =>>> grep 0.04 real 0.02 user 0.01 sys << not -i 3.64 real 3.61 user 0.01 sys << -i i386, 8.0-RC1 FreeBSD 8.0-RC1 #15 r197337M, load averages: 1.61, 1.35, 1.12 Mem: 920M Active, 87M Inact, 215M Wired, 69M Cache, 112M Buf, 195M Free dev.cpu.0.freq: 1733 (Intel dual core laptop) 16Meg file result: =>>> 16777216 =>>> fgrep 0.04 real 0.02 user 0.01 sys 0.05 real 0.04 user 0.00 sys =>>> pcregrep 0.26 real 0.23 user 0.01 sys 0.29 real 0.24 user 0.00 sys =>>> grep 0.04 real 0.04 user 0.00 sys 4.73 real 4.15 user 0.01 sys amd64, 7.2-RELEASE-p4 #1 r198384M, load averages: 0.00, 0.00, 0.00 Mem: 115M Active, 182M Inact, 264M Wired, 101M Cache, 213M Buf, 1311M Free CPU: Dual-Core AMD Opteron(tm) Processor 2210 (1800.08-MHz K8-class CPU) 64Meg file result: =>>> 67108864 =>>> fgrep 0.18 real 0.13 user 0.04 sys 0.19 real 0.17 user 0.02 sys =>>> pcregrep 0.89 real 0.85 user 0.03 sys 0.98 real 0.92 user 0.06 sys =>>> grep 0.18 real 0.16 user 0.01 sys 0.19 real 0.16 user 0.03 sys So on the laptop I modified the testscript as it is attached now and while there is still a significant delay, the wallclock time is less then half, when the expression is rewritten with the same meaning: =>>> 16777216 =>>> fgrep 0.04 real 0.03 user 0.00 sys 0.05 real 0.03 user 0.01 sys 0.02 real 0.00 user 0.00 sys =>>> pcregrep 0.26 real 0.21 user 0.02 sys 0.26 real 0.22 user 0.02 sys 0.44 real 0.35 user 0.01 sys =>>> grep 0.04 real 0.04 user 0.00 sys 4.45 real 4.15 user 0.01 sys 2.00 real 1.81 user 0.00 sys <-- [fF][Oo][Oo] So it looks to me that, while there is a problem with case insensitive comparison, just rewriting the expression is an optimization grep could perform. Either way, with the new text tools being written (done?) is this problem being attacked, not fixable due to specifications or not considered an issue? Any PR's needed / I missed? Patches to try? [And it just occured to me bsdgrep is in ports]: =>>> bsdgrep 0.93 real 0.74 user 0.00 sys 4.80 real 4.33 user 0.02 sys 4.97 real 4.34 user 0.01 sys So here the optimization does not fly. -- Mel -------------- next part -------------- #!/bin/sh # vim: ts=4 sw=4 noet tw=78 ai PCREGREP=`which pcregrep` BSDGREP=`which bsdgrep` [ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}` [ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}` me=`basename $0` BYTES="1048576 2097152 4194304 8388608 16777216" if [ ! -x /usr/bin/jot ]; then echo "Need jot" exit 1 fi if [ ! -x /usr/bin/rs ]; then echo "Need rs" exit 1 fi for b in ${BYTES}; do TMPFILE=`mktemp -t ${me}` if [ ! -f ${TMPFILE} ]; then echo Can\'t create tmp files in ${TMPDIR:="/tmp"} exit 2 fi jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE} echo "=>>> ${b}" for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do echo " =>>> ${prog}" /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null done rm ${TMPFILE} done From gabor at FreeBSD.org Tue Nov 3 21:19:14 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Nov 3 21:19:21 2009 Subject: Issue with grep -i (on i386 only?) In-Reply-To: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: <4AF09E49.3010705@FreeBSD.org> Mel Flynn escribi?: > Hi, > > attached a little test script for grep's -i performance. I tried a few > different machines and the 64-bit 7.2 machine I could steal doesn't seem to be > affected and out performs pcregrep. > Note, that pcregrep isn't POSIX regex so it's not a good base of comparison. PCRE provides a POSIX-compliant interface to deal with Perl-compatible regex for those, who are already familiar with the former but it's still Perl regex and not POSIX! That's why some people get confused when PCRE comes to the topic. > On i386 machines, grep -i is significantly slower: > i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00, > Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free > dev.cpu.0.freq: 2992 (Intel P-IV HTT enabled) > 16Meg file result: > =>>> 16777216 > =>>> fgrep > 0.04 real 0.02 user 0.01 sys > 0.04 real 0.03 user 0.01 sys > =>>> pcregrep > 0.21 real 0.19 user 0.02 sys > 0.21 real 0.20 user 0.00 sys > =>>> grep > 0.04 real 0.02 user 0.01 sys << not -i > 3.64 real 3.61 user 0.01 sys << -i > It's an interesting observation, I have never heard of this. > So it looks to me that, while there is a problem with case insensitive > comparison, just rewriting the expression is an optimization grep could > perform. > Either way, with the new text tools being written (done?) is this problem > being attacked, not fixable due to specifications or not considered an issue? > Any PR's needed / I missed? Patches to try? > > [And it just occured to me bsdgrep is in ports]: > =>>> bsdgrep > 0.93 real 0.74 user 0.00 sys > 4.80 real 4.33 user 0.02 sys > 4.97 real 4.34 user 0.01 sys > > So here the optimization does not fly. Unfortunately, this is the most important issue with BSDL texttools. In the grep case, the BSDL version is ready and feature-complete but the performance isn't quite satisfying. The main reason of this is GNU grep uses a lot of shortcuts, which results in a bloated code (8000 LOC), while BSDL grep keeps everything simple and straightforward (1500 LOC). IMO, the desired solution would be to keep grep small and get a modern regex library for FreeBSD, which performs well. Pushing regex optimizations into grep is a bad idea because it not just makes the code bloated but other regex users won't benefit from the optimization so the problem should be fixed at its roots. And the current regex library we have is old, slow and doesn't support wchar, at all. Btw, do you mind if I include your script into the BSD grep distribution? I already planned to write something like this for future testing. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From mel.flynn+fbsd.hackers at mailing.thruhere.net Tue Nov 3 22:14:50 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Tue Nov 3 22:15:13 2009 Subject: Issue with grep -i (on i386 only?) In-Reply-To: <4AF09E49.3010705@FreeBSD.org> References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4AF09E49.3010705@FreeBSD.org> Message-ID: <200911032314.45247.mel.flynn+fbsd.hackers@mailing.thruhere.net> On Tuesday 03 November 2009 22:19:05 Gabor Kovesdan wrote: > Mel Flynn escribi?: > > Hi, > > > > attached a little test script for grep's -i performance. I tried a few > > different machines and the 64-bit 7.2 machine I could steal doesn't seem > > to be affected and out performs pcregrep. > > Note, that pcregrep isn't POSIX regex so it's not a good base of > comparison. PCRE provides a POSIX-compliant interface to deal with > Perl-compatible regex for those, who are already familiar with the > former but it's still Perl regex and not POSIX! That's why some people > get confused when PCRE comes to the topic. I realize this, but for the case in question it does not matter. Both 'regexes' should do the same in PCRE and POSIX. I provided the comparison to show that the 'problem of case insensitive comparison' is solvable, at the very least for the simple case. > > On i386 machines, grep -i is significantly slower: > > i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00, > > Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free > > dev.cpu.0.freq: 2992 (Intel P-IV HTT enabled) > > 16Meg file result: > > =>>> 16777216 > > =>>> fgrep > > 0.04 real 0.02 user 0.01 sys > > 0.04 real 0.03 user 0.01 sys > > =>>> pcregrep > > 0.21 real 0.19 user 0.02 sys > > 0.21 real 0.20 user 0.00 sys > > =>>> grep > > 0.04 real 0.02 user 0.01 sys << not -i > > 3.64 real 3.61 user 0.01 sys << -i > > It's an interesting observation, I have never heard of this. > > > So it looks to me that, while there is a problem with case insensitive > > comparison, just rewriting the expression is an optimization grep could > > perform. > > Either way, with the new text tools being written (done?) is this problem > > being attacked, not fixable due to specifications or not considered an > > issue? Any PR's needed / I missed? Patches to try? > > > > [And it just occured to me bsdgrep is in ports]: > > =>>> bsdgrep > > 0.93 real 0.74 user 0.00 sys > > 4.80 real 4.33 user 0.02 sys > > 4.97 real 4.34 user 0.01 sys > > > > So here the optimization does not fly. > > Unfortunately, this is the most important issue with BSDL texttools. In > the grep case, the BSDL version is ready and feature-complete but the > performance isn't quite satisfying. The main reason of this is GNU grep > uses a lot of shortcuts, which results in a bloated code (8000 LOC), > while BSDL grep keeps everything simple and straightforward (1500 LOC). > IMO, the desired solution would be to keep grep small and get a modern > regex library for FreeBSD, which performs well. Pushing regex > optimizations into grep is a bad idea because it not just makes the code > bloated but other regex users won't benefit from the optimization so the > problem should be fixed at its roots. And the current regex library we > have is old, slow and doesn't support wchar, at all. With this kind of difference, I don't really care who performs the optimization, but it seems that multiple options at the same character spot is not handled very well, with an extra penalty for "case insensitive". Why this isn't present on my 64-bit machine is a bit of a mystery to me, but since almost no time is spent in sys, I can't blame it on kernel. > Btw, do you mind if I include your script into the BSD grep > distribution? I already planned to write something like this for future > testing. Consider it public domain. -- Mel From rea-fbsd at codelabs.ru Wed Nov 4 03:05:43 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Nov 4 03:06:15 2009 Subject: Issue with grep -i (on i386 only?) In-Reply-To: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: Mel, good day. Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote: > So on the laptop I modified the testscript as it is attached now and > while there is still a significant delay, the wallclock time is less > then half, when the expression is rewritten with the same meaning: > =>>> 16777216 > =>>> fgrep > 0.04 real 0.03 user 0.00 sys > 0.05 real 0.03 user 0.01 sys > 0.02 real 0.00 user 0.00 sys > =>>> pcregrep > 0.26 real 0.21 user 0.02 sys > 0.26 real 0.22 user 0.02 sys > 0.44 real 0.35 user 0.01 sys > =>>> grep > 0.04 real 0.04 user 0.00 sys > 4.45 real 4.15 user 0.01 sys > 2.00 real 1.81 user 0.00 sys <-- [fF][Oo][Oo] Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor: ----- =>>> 16777216 =>>> fgrep 0,09 real 0,04 user 0,05 sys 0,18 real 0,06 user 0,03 sys 0,05 real 0,01 user 0,04 sys =>>> pcregrep 0,47 real 0,29 user 0,07 sys 0,52 real 0,33 user 0,07 sys 0,77 real 0,45 user 0,03 sys =>>> grep 0,09 real 0,08 user 0,01 sys 0,10 real 0,04 user 0,05 sys 0,23 real 0,12 user 0,03 sys ----- Pattern for the plain 'grep' is stable: first and second variants always give the same time within a 0.01 second variation and the last variant gives 2x slowdown. I tried sizes up to the 64M -- the pattern stays. The same stuff for the amd64, so in my case I don't see the difference in behaviour. So, maybe, the problem isn't 32 vs 64 but lies somewhere else. > attached a little test script for grep's -i performance. Some notes about the script, especially if (or some variant of it) will be included to the testing framework. > #!/bin/sh > # vim: ts=4 sw=4 noet tw=78 ai > > PCREGREP=`which pcregrep` > BSDGREP=`which bsdgrep` > [ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}` > [ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}` You'll want '[ -n "${PCREGREP}" ] && ...' (with quoted variable) to really achieve the kind of test you wanted. > if [ ! -x /usr/bin/jot ]; then > echo "Need jot" > exit 1 > fi > if [ ! -x /usr/bin/rs ]; then > echo "Need rs" > exit 1 > fi Probably this is better be written as ----- for prog in jot rs; do if [ -z "`which "$prog"`" ]; then echo "Need $prog" exit 1 fi done ----- because the latter code uses unqualified 'jot' and 'rs'. > for b in ${BYTES}; do > TMPFILE=`mktemp -t ${me}` > if [ ! -f ${TMPFILE} ]; then > echo Can\'t create tmp files in ${TMPDIR:="/tmp"} > exit 2 > fi > jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE} > echo "=>>> ${b}" > for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do > echo " =>>> ${prog}" > /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null > /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null > /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null > done > rm ${TMPFILE} > done Most likely, it is better to create the temporary file only once and to trap the signals with the file removal -- this will handle the cases when user presses ^C during the execution -- temporary file should be cleaned in this case. The code is simple: ----- TMPFILE=`mktemp -t ${me}` if [ ! -f ${TMPFILE} ]; then echo "Can't create tmp file in ${TMPDIR:=/tmp}" exit 2 fi trap 'rm -f "${TMPFILE}"' 0 1 2 3 15 ----- Attaching modified version with the bonus -- 'K' and 'M' size prefixes: it was boring to specify many digits when I had played with sizes ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From olivermahmoudi at gmail.com Wed Nov 4 08:31:35 2009 From: olivermahmoudi at gmail.com (Oliver Mahmoudi) Date: Wed Nov 4 08:31:42 2009 Subject: writing a FreeBSD C library In-Reply-To: <4AE60F70.9070808@FreeBSD.org> References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> Message-ID: <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> Thank you for your emails. Neither one of the methods that you two suggested brought about the desired solution, but I have solved it. using gcc for the plain source with the -I switch gives: % gcc -o aprog aprog.c -I ~/mylib/ /var/tmp//ccHrDiyd.o(.text+0x19): In function `main': : undefined reference to `myprnf' creating an object file first and then linking with ld gives me: % ld -o aprog aprog.o mylib.a ld: warning: cannot find entry symbol _start; defaulting to 0000000008048080 mylib.a(lb.o)(.text+0x33): In function `_myprf': : undefined reference to `puts' whereas placing mylib.a before the -o switch and then linking with ld gives: % ld mylib.a -o aprog aprog.o ld: warning: cannot find entry symbol _start; defaulting to 0000000008048080 aprog.o(.text+0x19): In function `main': : undefined reference to `myprnf' which is essentially the same message it gives when compiling and linking with gcc in one step. The fact that the order of the arguments matters is also mentioned somewhere in gcc(1) and ld(1). The solution was to simply compile and link it like so: % gcc -o testfile aprog.c mylib.a % ./testfile hello world % This is in essence a synthesis of what you two suggested. Anyways, thanks again. Oliver > From alexjeffburke at gmail.com Wed Nov 4 08:43:38 2009 From: alexjeffburke at gmail.com (Alex Burke) Date: Wed Nov 4 08:43:45 2009 Subject: Issue with grep -i (on i386 only?) In-Reply-To: References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: On Wednesday, November 4, 2009, Eygene Ryabinkin wrote: > Mel, good day. > > Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote: >> So on the laptop I modified the testscript as it is attached now and >> while there is still a significant delay, the wallclock time is less >> then half, when the expression is rewritten with the same meaning: >> =>>> 16777216 >> ? ? =>>> fgrep >> ? ? ? ? 0.04 real ? ? ? ? 0.03 user ? ? ? ? 0.00 sys >> ? ? ? ? 0.05 real ? ? ? ? 0.03 user ? ? ? ? 0.01 sys >> ? ? ? ? 0.02 real ? ? ? ? 0.00 user ? ? ? ? 0.00 sys >> ? ? =>>> pcregrep >> ? ? ? ? 0.26 real ? ? ? ? 0.21 user ? ? ? ? 0.02 sys >> ? ? ? ? 0.26 real ? ? ? ? 0.22 user ? ? ? ? 0.02 sys >> ? ? ? ? 0.44 real ? ? ? ? 0.35 user ? ? ? ? 0.01 sys >> ? ? =>>> grep >> ? ? ? ? 0.04 real ? ? ? ? 0.04 user ? ? ? ? 0.00 sys >> ? ? ? ? 4.45 real ? ? ? ? 4.15 user ? ? ? ? 0.01 sys >> ? ? ? ? 2.00 real ? ? ? ? 1.81 user ? ? ? ? 0.00 sys <-- [fF][Oo][Oo] > > Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor: > ----- > =>>> 16777216 > ? ?=>>> fgrep > ? ? ? ?0,09 real ? ? ? ? 0,04 user ? ? ? ? 0,05 sys > ? ? ? ?0,18 real ? ? ? ? 0,06 user ? ? ? ? 0,03 sys > ? ? ? ?0,05 real ? ? ? ? 0,01 user ? ? ? ? 0,04 sys > ? ?=>>> pcregrep > ? ? ? ?0,47 real ? ? ? ? 0,29 user ? ? ? ? 0,07 sys > ? ? ? ?0,52 real ? ? ? ? 0,33 user ? ? ? ? 0,07 sys > ? ? ? ?0,77 real ? ? ? ? 0,45 user ? ? ? ? 0,03 sys > ? ?=>>> grep > ? ? ? ?0,09 real ? ? ? ? 0,08 user ? ? ? ? 0,01 sys > ? ? ? ?0,10 real ? ? ? ? 0,04 user ? ? ? ? 0,05 sys > ? ? ? ?0,23 real ? ? ? ? 0,12 user ? ? ? ? 0,03 sys > ----- > Pattern for the plain 'grep' is stable: first and second variants always > give the same time within a 0.01 second variation and the last variant > gives 2x slowdown. > > I tried sizes up to the 64M -- the pattern stays. ?The same stuff for > the amd64, so in my case I don't see the difference in behaviour. ?So, > maybe, the problem isn't 32 vs 64 but lies somewhere else. > >> attached a little test script for grep's -i performance. > > Some notes about the script, especially if (or some variant of it) > will be included to the testing framework. > >> #!/bin/sh >> # vim: ts=4 sw=4 noet tw=78 ai >> >> PCREGREP=`which pcregrep` >> BSDGREP=`which bsdgrep` >> [ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}` >> [ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}` > > You'll want '[ -n "${PCREGREP}" ] && ...' (with quoted variable) to > really achieve the kind of test you wanted. > >> if [ ! -x /usr/bin/jot ]; then >> ? ? ? echo "Need jot" >> ? ? ? exit 1 >> fi >> if [ ! -x /usr/bin/rs ]; then >> ? ? ? echo "Need rs" >> ? ? ? exit 1 >> fi > > Probably this is better be written as > ----- > for prog in jot rs; do > ? ? ? ?if [ -z "`which "$prog"`" ]; then > ? ? ? ? ? ? ? ?echo "Need $prog" > ? ? ? ? ? ? ? ?exit 1 > ? ? ? ?fi > done > ----- > because the latter code uses unqualified 'jot' and 'rs'. > >> for b in ${BYTES}; do >> ? ? ? TMPFILE=`mktemp -t ${me}` >> ? ? ? if [ ! -f ${TMPFILE} ]; then >> ? ? ? ? ? ? ? echo Can\'t create tmp files in ${TMPDIR:="/tmp"} >> ? ? ? ? ? ? ? exit 2 >> ? ? ? fi >> ? ? ? jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE} >> ? ? ? echo "=>>> ${b}" >> ? ? ? for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do >> ? ? ? ? ? ? ? echo " ? ?=>>> ${prog}" >> ? ? ? ? ? ? ? /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null >> ? ? ? ? ? ? ? /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null >> ? ? ? ? ? ? ? /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null >> ? ? ? done >> ? ? ? rm ${TMPFILE} >> done > > Most likely, it is better to create the temporary file only once > and to trap the signals with the file removal -- this will handle > the cases when user presses ^C during the execution -- temporary > file should be cleaned in this case. ?The code is simple: > ----- > TMPFILE=`mktemp -t ${me}` > if [ ! -f ${TMPFILE} ]; then > ? ? ? ?echo "Can't create tmp file in ${TMPDIR:=/tmp}" > ? ? ? ?exit 2 > fi > trap 'rm -f "${TMPFILE}"' 0 1 2 3 15 > ----- > > Attaching modified version with the bonus -- 'K' and 'M' size prefixes: > it was boring to specify many digits when I had played with sizes ;)) > -- > Eygene > ?_ ? ? ? ? ? ? ? ?___ ? ? ? _.--. ? # > ?\`.|\..----...-'` ? `-._.-'_.-'` ? # ?Remember that it is hard > ?/ ?' ` ? ? ? ? , ? ? ? __.--' ? ? ?# ?to read the on-line manual > ?)/' _/ ? ? \ ? `-_, ? / ? ? ? ? ? ?# ?while single-stepping the kernel. > ?`-'" `"\_ ?,_.-;_.-\_ ', ?fsc/as ? # > ? ? _.-'_./ ? {_.' ? ; / ? ? ? ? ? # ? ?-- FreeBSD Developers handbook > ? ?{_.-``-' ? ? ? ? {_/ ? ? ? ? ? ?# > From redcrash at gmail.com Wed Nov 4 09:27:32 2009 From: redcrash at gmail.com (Harald Servat) Date: Wed Nov 4 09:27:38 2009 Subject: writing a FreeBSD C library In-Reply-To: <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> Message-ID: Hello Oliver, 2009/11/4 Oliver Mahmoudi > Thank you for your emails. > Neither one of the methods that you two suggested brought about the desired > solution, but I have solved it. > > using gcc for the plain source with the -I switch gives: > % gcc -o aprog aprog.c -I ~/mylib/ > /var/tmp//ccHrDiyd.o(.text+0x19): In function `main': > : undefined reference to `myprnf' > > creating an object file first and then linking with ld gives me: > % ld -o aprog aprog.o mylib.a > ld: warning: cannot find entry symbol _start; defaulting to > 0000000008048080 > mylib.a(lb.o)(.text+0x33): In function `_myprf': > : undefined reference to `puts' > > whereas placing mylib.a before the -o switch and then linking with ld > gives: > % ld mylib.a -o aprog aprog.o > ld: warning: cannot find entry symbol _start; defaulting to > 0000000008048080 > aprog.o(.text+0x19): In function `main': > : undefined reference to `myprnf' > > which is essentially the same message it gives when compiling and linking > with gcc in one step. The fact that the order of the arguments matters is > also mentioned somewhere in gcc(1) and ld(1). > > The solution was to simply compile and link it like so: > % gcc -o testfile aprog.c mylib.a > % ./testfile > hello world > % > > > This is in essence a synthesis of what you two suggested. > > I'm afraid that this is not the most common usage of libraries in the unix world. Libraries, typically, are called lib[SOMETHING].a (if they are static libraries) or lib[SOMETHING].so* (if they are shared libraries). In addition, the -l X option in the gcc compiler looks for libX.[a|so] in the all specified paths defined by -L, so in your first command gcc -o aprog aprog.c -I ~/mylib/ you're making gcc to look for for something called lib~/mylib/.[a|so] which I doubt it can be found. So, I suggest you to: 1.- Name your "mylib.a" into "libmylib.a" (or other name that begins with lib), 2.- add -L. to your 1st gcc invocation (in order to instruct gcc to look at the current directory, i.e., "."), and 3.- add -lmylib (if you called your library libmylib.a) to the gcc Your compile instruction, then, should look like gcc -o aproc aprog.c -L. -lmylib Regards. > > Anyways, thanks again. > > > Oliver > > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- _________________________________________________________________ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From des at des.no Wed Nov 4 12:03:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 4 12:04:06 2009 Subject: writing a FreeBSD C library In-Reply-To: (Harald Servat's message of "Wed, 4 Nov 2009 10:02:25 +0100") References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> Message-ID: <86bpjih4yd.fsf@ds4.des.no> Harald Servat writes: > In addition, the -l X option in the gcc compiler looks for libX.[a|so] in > the all specified paths defined by -L, so in your first command > gcc -o aprog aprog.c -I ~/mylib/ > you're making gcc to look for for something called lib~/mylib/.[a|so] > which I doubt it can be found. You're confusing -l with -I... but the rest of your email is correct. DES -- Dag-Erling Sm?rgrav - des@des.no From mel.flynn+fbsd.hackers at mailing.thruhere.net Wed Nov 4 12:49:59 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Wed Nov 4 12:50:31 2009 Subject: Issue with grep -i (on i386 only?) In-Reply-To: References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: <200911041349.54943.mel.flynn+fbsd.hackers@mailing.thruhere.net> On Wednesday 04 November 2009 04:05:44 Eygene Ryabinkin wrote: > Mel, good day. > > Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote: > > So on the laptop I modified the testscript as it is attached now and > > while there is still a significant delay, the wallclock time is less > > then half, when the expression is rewritten with the same meaning: > > =>>> 16777216 > > =>>> fgrep > > 0.04 real 0.03 user 0.00 sys > > 0.05 real 0.03 user 0.01 sys > > 0.02 real 0.00 user 0.00 sys > > =>>> pcregrep > > 0.26 real 0.21 user 0.02 sys > > 0.26 real 0.22 user 0.02 sys > > 0.44 real 0.35 user 0.01 sys > > =>>> grep > > 0.04 real 0.04 user 0.00 sys > > 4.45 real 4.15 user 0.01 sys > > 2.00 real 1.81 user 0.00 sys <-- [fF][Oo][Oo] > > Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor: > ----- > =>>> 16777216 > =>>> fgrep > 0,09 real 0,04 user 0,05 sys > 0,18 real 0,06 user 0,03 sys > 0,05 real 0,01 user 0,04 sys > =>>> pcregrep > 0,47 real 0,29 user 0,07 sys > 0,52 real 0,33 user 0,07 sys > 0,77 real 0,45 user 0,03 sys > =>>> grep > 0,09 real 0,08 user 0,01 sys > 0,10 real 0,04 user 0,05 sys > 0,23 real 0,12 user 0,03 sys > ----- > Pattern for the plain 'grep' is stable: first and second variants always > give the same time within a 0.01 second variation and the last variant > gives 2x slowdown. > > I tried sizes up to the 64M -- the pattern stays. The same stuff for > the amd64, so in my case I don't see the difference in behaviour. So, > maybe, the problem isn't 32 vs 64 but lies somewhere else. Well, just ruled out the last commonality: The i386 machines tested all had MAXPHYS to 1M, except the one I just tried: =>>> 16777216 =>>> fgrep 0.04 real 0.03 user 0.00 sys 0.04 real 0.03 user 0.00 sys 0.02 real 0.00 user 0.01 sys =>>> grep 0.04 real 0.02 user 0.02 sys 3.70 real 3.56 user 0.00 sys 1.91 real 1.83 user 0.02 sys Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults aren't that). Since fgrep is fast and basically seeds the cache for grep, I'm ruling out disks/io reads. In fact, /tmp on this laptop is memory disk (one reason I couldn't go up to 64M :)). I honestly can't figure out what my 'local problem' could be or your optimization. Thanks for the fix ups. One more below sig. -- Mel --- grep-test.sh.orig 2009-11-04 03:17:05.000000000 -0900 +++ grep-test.sh 2009-11-04 03:29:55.000000000 -0900 @@ -34,6 +34,10 @@ ;; esac + if [ ! -f ${TMPFILE} ]; then + # signalled + exit 0; + fi jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE} echo "=>>> ${b}" for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do From jhb at freebsd.org Wed Nov 4 13:18:32 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 4 13:18:39 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <20091103172452.GU1293@hoeg.nl> References: <20091103172452.GU1293@hoeg.nl> Message-ID: <200911040812.18712.jhb@freebsd.org> On Tuesday 03 November 2009 12:24:52 pm Ed Schouten wrote: > Hi Alan, > > * Alan Cox wrote: > > The standards for mmap(2) actually disallow values of "off" that are not a > > multiple of the page size. > > > > See http://www.opengroup.org/onlinepubs/000095399/functions/mmap.html for > > the following: > > > > Just by accident I saw they changed that behaviour in a newer version of > the spec: > > http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html Note that the spec doesn't cover MAP_ANON at all FWIW. -- John Baldwin From redcrash at gmail.com Wed Nov 4 13:52:53 2009 From: redcrash at gmail.com (Harald Servat) Date: Wed Nov 4 13:52:59 2009 Subject: writing a FreeBSD C library In-Reply-To: <86bpjih4yd.fsf@ds4.des.no> References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> <86bpjih4yd.fsf@ds4.des.no> Message-ID: Oh, yes! You're right DES. They look the same to me here in the web-browser :) Oliver, regarding the Dag-Erling correction, the -I option in gcc refers to include header files (typically files ended with .h), not for naming libraries as I mentioned. Regards. 2009/11/4 Dag-Erling Sm?rgrav > Harald Servat writes: > > In addition, the -l X option in the gcc compiler looks for libX.[a|so] > in > > the all specified paths defined by -L, so in your first command > > gcc -o aprog aprog.c -I ~/mylib/ > > you're making gcc to look for for something called lib~/mylib/.[a|so] > > which I doubt it can be found. > > You're confusing -l with -I... but the rest of your email is correct. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > -- _________________________________________________________________ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From ed at 80386.nl Wed Nov 4 16:26:47 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 4 16:26:54 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <200911040812.18712.jhb@freebsd.org> References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> Message-ID: <20091104162646.GZ1293@hoeg.nl> * John Baldwin wrote: > Note that the spec doesn't cover MAP_ANON at all FWIW. Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON. They do provide MAP_ANON for compatibility, if I remember correctly. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091104/710109e1/attachment.pgp From alc at cs.rice.edu Wed Nov 4 18:25:21 2009 From: alc at cs.rice.edu (Alan Cox) Date: Wed Nov 4 18:25:30 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <20091104162646.GZ1293@hoeg.nl> References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> <20091104162646.GZ1293@hoeg.nl> Message-ID: <4AF1C707.6000706@cs.rice.edu> Ed Schouten wrote: > * John Baldwin wrote: > >> Note that the spec doesn't cover MAP_ANON at all FWIW. >> > > Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON. > They do provide MAP_ANON for compatibility, if I remember correctly. > > For what it's worth, I believe that Solaris does the exact opposite. They provide MAP_ANONYMOUS for compatibility. It seems like a good idea for us to do the same. We also have an unimplemented option MAP_RENAME defined for compatibility with "Sun" that is nowhere mentioned in modern Solaris documentation. Alan From ed at 80386.nl Wed Nov 4 18:34:36 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 4 18:34:47 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <4AF1C707.6000706@cs.rice.edu> References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> <20091104162646.GZ1293@hoeg.nl> <4AF1C707.6000706@cs.rice.edu> Message-ID: <20091104183434.GB1293@hoeg.nl> * Alan Cox wrote: > For what it's worth, I believe that Solaris does the exact opposite. > They provide MAP_ANONYMOUS for compatibility. It seems like a good > idea for us to do the same. Something like this? Index: mman.h =================================================================== --- mman.h (revision 198919) +++ mman.h (working copy) @@ -82,6 +82,9 @@ */ #define MAP_FILE 0x0000 /* map from file (default) */ #define MAP_ANON 0x1000 /* allocated from memory, swap space */ +#ifndef _KERNEL +#define MAP_ANONYMOUS MAP_ANON /* For compatibility. */ +#endif /* !_KERNEL */ /* * Extended flags -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091104/f7171876/attachment.pgp From alc at cs.rice.edu Wed Nov 4 18:42:37 2009 From: alc at cs.rice.edu (Alan Cox) Date: Wed Nov 4 18:42:44 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <20091104183434.GB1293@hoeg.nl> References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> <20091104162646.GZ1293@hoeg.nl> <4AF1C707.6000706@cs.rice.edu> <20091104183434.GB1293@hoeg.nl> Message-ID: <4AF1CB11.2090503@cs.rice.edu> Ed Schouten wrote: > * Alan Cox wrote: > >> For what it's worth, I believe that Solaris does the exact opposite. >> They provide MAP_ANONYMOUS for compatibility. It seems like a good >> idea for us to do the same. >> > > Something like this? > > Index: mman.h > =================================================================== > --- mman.h (revision 198919) > +++ mman.h (working copy) > @@ -82,6 +82,9 @@ > */ > #define MAP_FILE 0x0000 /* map from file (default) */ > #define MAP_ANON 0x1000 /* allocated from memory, swap space */ > +#ifndef _KERNEL > +#define MAP_ANONYMOUS MAP_ANON /* For compatibility. */ > +#endif /* !_KERNEL */ > > /* > * Extended flags > > Yes. If no one objects in the next day or so, then please commit this change. Alan From alexbestms at math.uni-muenster.de Wed Nov 4 19:09:29 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Nov 4 19:09:35 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <4AF1CB11.2090503@cs.rice.edu> Message-ID: Alan Cox schrieb am 2009-11-04: > Ed Schouten wrote: > >* Alan Cox wrote: > For what it's worth, I believe that Solaris does the exact opposite. > >>They provide MAP_ANONYMOUS for compatibility. It seems like a good > >>idea for us to do the same. > >Something like this? > >Index: mman.h > >=================================================================== > >--- mman.h (revision 198919) > >+++ mman.h (working copy) > >@@ -82,6 +82,9 @@ > > */ > >#define MAP_FILE 0x0000 /* map from file (default) */ > >#define MAP_ANON 0x1000 /* allocated from memory, > >swap space */ > >+#ifndef _KERNEL > >+#define MAP_ANONYMOUS MAP_ANON /* For compatibility. */ > >+#endif /* !_KERNEL */ > > /* > > * Extended flags > Yes. If no one objects in the next day or so, then please commit > this change. > Alan should this compatibility addition be documented in the mmap(2) manual? any thoughts on the previous change request so mmap fails with MAP_ANON and pos=0? alex From alexbestms at math.uni-muenster.de Wed Nov 4 20:26:30 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Nov 4 20:26:36 2009 Subject: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED Message-ID: just had a look at the linux mmap(2) manual and noticed a very neat thing they seem to have in most manuals: in the ERRORS section they also document which signals one has to expect. for mmap they are SIGSEGV and SIGBUS. thanks very useful imo. alex From kayve at sfsu.edu Wed Nov 4 21:44:24 2009 From: kayve at sfsu.edu (KAYVEN RIESE) Date: Wed Nov 4 21:44:31 2009 Subject: writing a FreeBSD C library In-Reply-To: References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> <86bpjih4yd.fsf@ds4.des.no> Message-ID: On Wed, 4 Nov 2009, Harald Servat wrote: > Oh, yes! You're right DES. They look the same to me here in the web-browser > :) Oh, no. shoulda used a serif font! {:P > > Oliver, regarding the Dag-Erling correction, the -I option in gcc refers to > include header files (typically files ended with .h), not for naming > libraries as I mentioned. > > Regards. > > 2009/11/4 Dag-Erling Sm?rgrav > >> Harald Servat writes: >>> In addition, the -l X option in the gcc compiler looks for libX.[a|so] >> in >>> the all specified paths defined by -L, so in your first command >>> gcc -o aprog aprog.c -I ~/mylib/ >>> you're making gcc to look for for something called lib~/mylib/.[a|so] >>> which I doubt it can be found. >> >> You're confusing -l with -I... but the rest of your email is correct. >> >> DES >> -- >> Dag-Erling Sm?rgrav - des@des.no >> > > > > -- > _________________________________________________________________ > Fry: You can see how I lived before I met you. > Bender: You lived before you met me?! > Fry: Yeah, lots of people did. > Bender: Really?! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From mel.flynn+fbsd.hackers at mailing.thruhere.net Wed Nov 4 23:03:54 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Wed Nov 4 23:04:01 2009 Subject: Grep -i and UTF-8 (Was: Re: Issue with grep -i (on i386 only?)) In-Reply-To: <200911041349.54943.mel.flynn+fbsd.hackers@mailing.thruhere.net> References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> <200911041349.54943.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: <200911050003.51080.mel.flynn+fbsd.hackers@mailing.thruhere.net> On Wednesday 04 November 2009 13:49:54 Mel Flynn wrote: > Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults > aren't that). Since fgrep is fast and basically seeds the cache for grep, > I'm ruling out disks/io reads. In fact, /tmp on this laptop is memory disk > (one reason I couldn't go up to 64M :)). I honestly can't figure out what > my 'local problem' could be or your optimization. It hit me. Rather then a local problem, it's a locale problem: =>>> 16777216 =>>> en_US.UTF-8 =>>> fgrep 0.04 real 0.04 user 0.00 sys 0.04 real 0.02 user 0.02 sys 0.02 real 0.01 user 0.00 sys =>>> grep 0.04 real 0.04 user 0.00 sys 3.74 real 3.55 user 0.02 sys 1.95 real 1.83 user 0.03 sys =>>> en_US.ISO8859-1 =>>> fgrep 0.04 real 0.04 user 0.00 sys 0.04 real 0.03 user 0.00 sys 0.02 real 0.01 user 0.01 sys =>>> grep 0.05 real 0.03 user 0.00 sys 0.05 real 0.04 user 0.00 sys 0.08 real 0.04 user 0.03 sys =>>> en_US.US-ASCII =>>> fgrep 0.04 real 0.01 user 0.02 sys 0.05 real 0.03 user 0.01 sys 0.02 real 0.00 user 0.02 sys =>>> grep 0.04 real 0.03 user 0.00 sys 0.05 real 0.03 user 0.00 sys 0.08 real 0.06 user 0.01 sys -- Mel From dclark at engr.scu.edu Wed Nov 4 23:07:30 2009 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Wed Nov 4 23:32:52 2009 Subject: gdb/libkvm problem - can someone explain this? In-Reply-To: Message-ID: With FreeBSD 4.x, gdb -k is able to read and interpret the last 4 bytes of a page (4k) boundary. In BSD 6.x/7.x/8.x using the kgdb program, if one issues the kgdb command: (gdb) x /x 0xcbed8ffd An "invalid address" error is returned. However, if one issues the command: (gdb) x /10x 0xcbed8ff0 it is able to read the memory (and past) just fine. The following patch returns the usr/src/lib/libkvm/kvm_i386.c behavior closer to the BSD4.x version and seems to remedy this situation. @@ -289,11 +289,13 @@ #define PG_FRAME4M (~PAGE4M_MASK) pde_pa = ((u_long)pde & PG_FRAME4M) + (va & PAGE4M_MASK); s = _kvm_pa2off(kd, pde_pa, &ofs); +#if 0 if (s < sizeof pde) { _kvm_syserr(kd, kd->program, "_kvm_vatop: pde_pa not found"); goto invalid; } +#endif *pa = ofs; return (NBPDR - (va & PAGE4M_MASK)); } Does anyone see any problem or have any comments about this? Paul Lai Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University Santa Clara, CA. http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/libkvm_problem.txt From alexbestms at math.uni-muenster.de Thu Nov 5 01:17:17 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Nov 5 01:17:24 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" Message-ID: hi there, i dug up this old pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 and was surprised it still remains valid for 9-CURRENT. indeed running the following code: #include #include #include #include main() { rmdir("/"); printf("rmdir errno: %d\n", errno); mkdir("/", 511); printf("mkdir errno: %d\n", errno); } returns: rmdir errno: 21 mkdir errno: 21 which is EISDIR. as the pr already said EISDIR isn't mentioned at all in mkdir(2) or rmdir(2). so i guess this should either get fixed or we add a "BUGS" section to both manuals where this problem gets mentioned. alex From gary.jennejohn at freenet.de Thu Nov 5 09:12:32 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Nov 5 09:12:50 2009 Subject: gdb/libkvm problem - can someone explain this? In-Reply-To: References: Message-ID: <20091105101226.5c6ef961@ernst.jennejohn.org> On Wed, 4 Nov 2009 15:06:17 -0800 (PST) "Dorr H. Clark" wrote: > > With FreeBSD 4.x, gdb -k is able to read and interpret > the last 4 bytes of a page (4k) boundary. > > In BSD 6.x/7.x/8.x using the kgdb program, > if one issues the kgdb command: > (gdb) x /x 0xcbed8ffd > An "invalid address" error is returned. > This is only 3 bytes - d, e, f. Try it with 0xcbed8ffc. BTW you got a little carried away with cross posting. --- Gary Jennejohn From jhb at freebsd.org Thu Nov 5 13:56:37 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 5 13:56:44 2009 Subject: gdb/libkvm problem - can someone explain this? In-Reply-To: References: Message-ID: <200911050856.13188.jhb@freebsd.org> On Wednesday 04 November 2009 6:06:17 pm Dorr H. Clark wrote: > > With FreeBSD 4.x, gdb -k is able to read and interpret > the last 4 bytes of a page (4k) boundary. > > In BSD 6.x/7.x/8.x using the kgdb program, > if one issues the kgdb command: > (gdb) x /x 0xcbed8ffd > An "invalid address" error is returned. > > However, if one issues the command: > (gdb) x /10x 0xcbed8ff0 > it is able to read the memory (and past) just fine. > > The following patch returns the usr/src/lib/libkvm/kvm_i386.c > behavior closer to the BSD4.x version and seems to remedy this situation. > > @@ -289,11 +289,13 @@ > #define PG_FRAME4M (~PAGE4M_MASK) > pde_pa = ((u_long)pde & PG_FRAME4M) + (va & PAGE4M_MASK); > s = _kvm_pa2off(kd, pde_pa, &ofs); > +#if 0 > if (s < sizeof pde) { > _kvm_syserr(kd, kd->program, > "_kvm_vatop: pde_pa not found"); > goto invalid; > } > +#endif > *pa = ofs; > return (NBPDR - (va & PAGE4M_MASK)); > } > > Does anyone see any problem or have any comments about this? How about this. It needs to fail if the page is not found at all, but this should fix your edge case. It also matches what kvm_amd64.c does. I think this was just a copy and paste bug. Index: kvm_i386.c =================================================================== --- kvm_i386.c (revision 198888) +++ kvm_i386.c (working copy) @@ -295,9 +295,9 @@ #define PG_FRAME4M (~PAGE4M_MASK) pde_pa = ((u_long)pde & PG_FRAME4M) + (va & PAGE4M_MASK); s = _kvm_pa2off(kd, pde_pa, &ofs); - if (s < sizeof pde) { - _kvm_syserr(kd, kd->program, - "_kvm_vatop: pde_pa not found"); + if (s == 0) { + _kvm_err(kd, kd->program, + "_kvm_vatop: 4MB page address not in dump"); goto invalid; } *pa = ofs; @@ -391,9 +391,9 @@ #define PG_FRAME2M (~PAGE2M_MASK) pde_pa = ((u_long)pde & PG_FRAME2M) + (va & PAGE2M_MASK); s = _kvm_pa2off(kd, pde_pa, &ofs); - if (s < sizeof pde) { - _kvm_syserr(kd, kd->program, - "_kvm_vatop_pae: pde_pa not found"); + if (s == 0) { + _kvm_err(kd, kd->program, + "_kvm_vatop: 2MB page address not in dump"); goto invalid; } *pa = ofs; -- John Baldwin From alc at cs.rice.edu Thu Nov 5 18:03:45 2009 From: alc at cs.rice.edu (Alan Cox) Date: Thu Nov 5 18:03:52 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: References: Message-ID: <4AF31377.60405@cs.rice.edu> Alexander Best wrote: > Alan Cox schrieb am 2009-11-04: > >> Ed Schouten wrote: >> >>> * Alan Cox wrote: >>> > > >> For what it's worth, I believe that Solaris does the exact opposite. >> >>>> They provide MAP_ANONYMOUS for compatibility. It seems like a good >>>> idea for us to do the same. >>>> > > > >>> Something like this? >>> > > >>> Index: mman.h >>> =================================================================== >>> --- mman.h (revision 198919) >>> +++ mman.h (working copy) >>> @@ -82,6 +82,9 @@ >>> */ >>> #define MAP_FILE 0x0000 /* map from file (default) */ >>> #define MAP_ANON 0x1000 /* allocated from memory, >>> swap space */ >>> +#ifndef _KERNEL >>> +#define MAP_ANONYMOUS MAP_ANON /* For compatibility. */ >>> +#endif /* !_KERNEL */ >>> /* >>> * Extended flags >>> > > > > >> Yes. If no one objects in the next day or so, then please commit >> this change. >> > > >> Alan >> > > should this compatibility addition be documented in the mmap(2) manual? > > I don't have a strong opinion one way or the other, but I would lean toward "yes". That said, Solaris doesn't. > any thoughts on the previous change request so mmap fails with MAP_ANON and > pos=0? > > Unfortunately, no. My FreeBSD time for the last few days has been spent looking into some anomalies in wiring memory and writing breakpoints. Alan From dclark at engr.scu.edu Fri Nov 6 01:06:24 2009 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Fri Nov 6 03:08:15 2009 Subject: resource leak in fifo_vnops.c: 6.x/7.x/8.x In-Reply-To: Message-ID: We believe we have identified a significant resource leak present in 6.x, 7.x, and 8.x. We believe this is a regression versus FreeBSD 4.x which appears to do the Right Thing (tm). We have a test program (see below) which will run the system out of sockets by repeated exercise of the failing code path in the kernel. Our proposed fix is applied to the file usr/src/sys/fs/fifofs/fifo_vnops.c @@ -237,6 +237,8 @@ if (ap->a_mode & FWRITE) { if ((ap->a_mode & O_NONBLOCK) && fip->fi_readers == 0) { mtx_unlock(&fifo_mtx); + /* Exclusive VOP lock is held - safe to clean */ + fifo_cleanup(vp); return (ENXIO); } fip->fi_writers++; Test program follows. We welcome feedback on this proposed fix. Chitti Nimmagadda Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University Santa Clara, CA. A test program which reveals the issue is presented here: #include #include #include #include #include #include #include #include #include #include #define FIFOPATH "/tmp/fifobug.debug" void getsysctl(name, ptr, len) const char *name; void *ptr; size_t len; { size_t nlen = len; if (sysctlbyname(name, ptr, &nlen, NULL, 0) != 0) { perror("sysctl"); printf("name: %s\n", name); exit(-1); } if (nlen != len) { printf("sysctl(%s...) expected %lu, got %lu", name, (unsigned long)len, (unsigned long)nlen); exit(-2); } } main(int argc, char *argv[]) { int acnt = 0, bcnt = 0, maxcnt; int fd; unsigned int maxiter; int notdone = 1; int i= 0; getsysctl("kern.ipc.maxsockets", &maxcnt, sizeof(maxcnt)); if (argc == 2) { maxiter = atoi(argv[1]); } else { maxiter = maxcnt*2; } unlink(FIFOPATH); printf("Max sockets: %d\n", maxcnt); printf("FIFO %s will be created, opened, deleted %d times\n", FIFOPATH, maxiter); getsysctl("kern.ipc.numopensockets", &bcnt, sizeof(bcnt)); while(notdone && (i++ < maxiter)) { if (mkfifo(FIFOPATH, 0) == 0) { chmod(FIFOPATH, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH); } fd = open(FIFOPATH, O_WRONLY|O_NONBLOCK); if ((fd <= 0) && (errno != ENXIO)) { notdone = 0; } unlink(FIFOPATH); } getsysctl("kern.ipc.numopensockets", &acnt, sizeof(acnt)); printf("Open Sockets: Before Test: %d, After Test: %d, diff: %d\n", bcnt, acnt, acnt - bcnt); if (notdone) { printf("FIFO/socket bug is fixed\n"); exit(0); } else { printf("FIFO/socket bug is NOT fixed\n"); exit(-1); } } http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/fifo_socket_leak.txt From cronfy at sprinthost.ru Fri Nov 6 05:12:43 2009 From: cronfy at sprinthost.ru (cronfy) Date: Fri Nov 6 05:12:49 2009 Subject: resource leak in fifo_vnops.c: 6.x/7.x/8.x In-Reply-To: References: Message-ID: <4AF3B013.5080205@sprinthost.ru> Hello. Is it possible to prevent normal user from taking up that large number of sockets? Ulimit'ing with openfiles does not look to help..:( > We believe we have identified a significant resource leak > present in 6.x, 7.x, and 8.x. We believe this is a regression > versus FreeBSD 4.x which appears to do the Right Thing (tm). > From attilio at freebsd.org Fri Nov 6 08:57:22 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 08:57:35 2009 Subject: resource leak in fifo_vnops.c: 6.x/7.x/8.x In-Reply-To: References: Message-ID: <3bbf2fe10911060057t5ebfb330n486c80018826fa93@mail.gmail.com> 2009/11/6 Dorr H. Clark : > > > We believe we have identified a significant resource leak > present in 6.x, 7.x, and 8.x. We believe this is a regression > versus FreeBSD 4.x which appears to do the Right Thing (tm). > > We have a test program (see below) which will run the system > out of sockets by repeated exercise of the failing code > path in the kernel. > > Our proposed fix is applied to the file usr/src/sys/fs/fifofs/fifo_vnops.c > > > @@ -237,6 +237,8 @@ > if (ap->a_mode & FWRITE) { > if ((ap->a_mode & O_NONBLOCK) && fip->fi_readers == 0) { > mtx_unlock(&fifo_mtx); > + /* Exclusive VOP lock is held - safe to clean */ > + fifo_cleanup(vp); > return (ENXIO); > } > fip->fi_writers++; I think it should also check that fip->if_writers == 0 (and possibly the checks within fifo_cleanup() should just be assertions, but that's orthogonal someway) and the comment is not needed. Attilio -- Peace can only be achieved by understanding - A. Einstein From ale at FreeBSD.org Fri Nov 6 14:33:07 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Fri Nov 6 14:33:13 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: References: Message-ID: <4AF42D61.6050403@FreeBSD.org> Alexander Best ha scritto: > i dug up this old pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 I think the EISDIR error is coming from kern/vfs_lookup.c, lookup() function with cn_nameptr = "": /* * Check for degenerate name (e.g. / or "") * which is a way of talking about a directory, * e.g. like "/." or ".". */ if (cnp->cn_nameptr[0] == '\0') { ... if (cnp->cn_nameiop != LOOKUP) { error = EISDIR; goto bad; } ... -- Alex Dupre From alexbestms at math.uni-muenster.de Fri Nov 6 15:32:33 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 15:32:40 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <4AF42D61.6050403@FreeBSD.org> Message-ID: Alex Dupre schrieb am 2009-11-06: > Alexander Best ha scritto: > > i dug up this old pr > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > I think the EISDIR error is coming from kern/vfs_lookup.c, lookup() > function with cn_nameptr = "": > /* > * Check for degenerate name (e.g. / or "") > * which is a way of talking about a directory, > * e.g. like "/." or ".". > */ > if (cnp->cn_nameptr[0] == '\0') { > ... > if (cnp->cn_nameiop != LOOKUP) { > error = EISDIR; > goto bad; > } > ... thanks a lot for finding the problem in the src. what do you think of the patch attached to this message? after applying it the example code i posted in my previous message returns the following output (instead of EISDIR): rmdir errno: 16 (which is EBUSY) mkdir errno: 17 (which is EEXIST) i don't know if these really are the correct return values, but it's what the originator of the PR requested. alex -------------- next part -------------- --- vfs_lookup.c 2009-11-06 16:14:41.000000000 +0100 +++ /usr/src/sys/kern/vfs_lookup.c 2009-11-06 16:13:19.000000000 +0100 @@ -35,7 +35,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: head/sys/kern/vfs_lookup.c 195939 2009-07-29 07:44:43Z rwatson $"); #include "opt_kdtrace.h" #include "opt_ktrace.h" @@ -563,8 +563,12 @@ error = ENOTDIR; goto bad; } - if (cnp->cn_nameiop != LOOKUP) { - error = EISDIR; + if (cnp->cn_nameiop != LOOKUP && cnp->cn_nameiop == DELETE) { + error = EBUSY; + goto bad; + } + if (cnp->cn_nameiop != LOOKUP && cnp->cn_nameiop == CREATE) { + error = EEXIST; goto bad; } if (wantparent) { From ale at FreeBSD.org Fri Nov 6 15:45:52 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Fri Nov 6 15:45:59 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: References: Message-ID: <4AF444AC.1030507@FreeBSD.org> Alexander Best ha scritto: > thanks a lot for finding the problem in the src. what do you think of the > patch attached to this message? I'm sorry, but I haven't enough knowledge about this subsystem to judge your patch. Someone else should jump in. -- Alex Dupre From alexbestms at math.uni-muenster.de Fri Nov 6 16:03:00 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 16:03:19 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <4AF444AC.1030507@FreeBSD.org> Message-ID: Alex Dupre schrieb am 2009-11-06: > Alexander Best ha scritto: > > thanks a lot for finding the problem in the src. what do you think > > of the > > patch attached to this message? > I'm sorry, but I haven't enough knowledge about this subsystem to > judge > your patch. Someone else should jump in. neither do i. ;) i fear the patch is just a dirty hack and probably breaks tons of conventions. ;) i'll post the patch as followup to the PR and see what happens. thanks again for having a look at the problem and pointing out the responsible code. alex From alexbestms at math.uni-muenster.de Fri Nov 6 16:15:58 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 16:16:05 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <20091106170853.7d0b0b6f@ernst.jennejohn.org> Message-ID: Gary Jennejohn schrieb am 2009-11-06: > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > Alexander Best wrote: > > Alex Dupre schrieb am 2009-11-06: > > > Alexander Best ha scritto: > > > > i dug up this old pr > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > lookup() > > > function with cn_nameptr = "": > > > /* > > > * Check for degenerate name (e.g. / or "") > > > * which is a way of talking about a directory, > > > * e.g. like "/." or ".". > > > */ > > > if (cnp->cn_nameptr[0] == '\0') { > > > ... > > > if (cnp->cn_nameiop != LOOKUP) { > > > error = EISDIR; > > > goto bad; > > > } > > > ... > > thanks a lot for finding the problem in the src. what do you think > > of the > > patch attached to this message? after applying it the example code > > i posted in > > my previous message returns the following output (instead of > > EISDIR): > > rmdir errno: 16 (which is EBUSY) > > mkdir errno: 17 (which is EEXIST) > > i don't know if these really are the correct return values, but > > it's what the > > originator of the PR requested. > What if cn_nameiop is != LOOKUP but also neither DELETE nor CREATE, > assuming that case is possible? I'd leave the original if-clause at > the end to catch that. > --- > Gary Jennejohn good point. cn_nameiop can be either LOOKUP, CREATE, RENAME, or DELETE. i'll check if maybe errno is also set incorrectly when RENAME is used and hack up a better patch which will handle all possible cn_nameiop values. thanks for pointing this out. alex From alexbestms at math.uni-muenster.de Fri Nov 6 16:43:14 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 16:43:21 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <20091106170853.7d0b0b6f@ernst.jennejohn.org> Message-ID: Gary Jennejohn schrieb am 2009-11-06: > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > Alexander Best wrote: > > Alex Dupre schrieb am 2009-11-06: > > > Alexander Best ha scritto: > > > > i dug up this old pr > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > lookup() > > > function with cn_nameptr = "": > > > /* > > > * Check for degenerate name (e.g. / or "") > > > * which is a way of talking about a directory, > > > * e.g. like "/." or ".". > > > */ > > > if (cnp->cn_nameptr[0] == '\0') { > > > ... > > > if (cnp->cn_nameiop != LOOKUP) { > > > error = EISDIR; > > > goto bad; > > > } > > > ... > > thanks a lot for finding the problem in the src. what do you think > > of the > > patch attached to this message? after applying it the example code > > i posted in > > my previous message returns the following output (instead of > > EISDIR): > > rmdir errno: 16 (which is EBUSY) > > mkdir errno: 17 (which is EEXIST) > > i don't know if these really are the correct return values, but > > it's what the > > originator of the PR requested. > What if cn_nameiop is != LOOKUP but also neither DELETE nor CREATE, > assuming that case is possible? I'd leave the original if-clause at > the end to catch that. > --- > Gary Jennejohn how about this patch? 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't think it's necessary since the first blocks should cover all the possible cases. 2. i've used rename() to test the case (cnp->cn_nameiop != RENAME). is this correct or does rename() use a combo of DELETE and CREATE? problem is that the rename(2) manual doesn't seem to cover the case that arg 1 is a mountpoint. right now EBUSY gets returned if cnp->cn_nameiop != RENAME. however BUSY needs to be added to all manuals which use cnp->cn_nameiop != RENAME (shouldn't be too many). or are there any other suggestions what rename() should return if arg 1 is a mountpoint? cheers. alex -------------- next part -------------- --- vfs_lookup.c 2009-11-06 16:14:41.000000000 +0100 +++ /usr/src/sys/kern/vfs_lookup.c 2009-11-06 17:41:40.000000000 +0100 @@ -35,7 +35,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: head/sys/kern/vfs_lookup.c 195939 2009-07-29 07:44:43Z rwatson $"); #include "opt_kdtrace.h" #include "opt_ktrace.h" @@ -563,6 +563,15 @@ error = ENOTDIR; goto bad; } + if (cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME) { + error = EBUSY; + goto bad; + } + if (cnp->cn_nameiop == CREATE) { + error = EEXIST; + goto bad; + } + /* XXX This block might not be needed. */ if (cnp->cn_nameiop != LOOKUP) { error = EISDIR; goto bad; From garyj at denx.de Fri Nov 6 16:08:57 2009 From: garyj at denx.de (Gary Jennejohn) Date: Fri Nov 6 16:44:23 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: References: <4AF42D61.6050403@FreeBSD.org> Message-ID: <20091106170853.7d0b0b6f@ernst.jennejohn.org> On Fri, 06 Nov 2009 16:32:22 +0100 (CET) Alexander Best wrote: > Alex Dupre schrieb am 2009-11-06: > > Alexander Best ha scritto: > > > i dug up this old pr > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > I think the EISDIR error is coming from kern/vfs_lookup.c, lookup() > > function with cn_nameptr = "": > > > > /* > > * Check for degenerate name (e.g. / or "") > > * which is a way of talking about a directory, > > * e.g. like "/." or ".". > > */ > > if (cnp->cn_nameptr[0] == '\0') { > > ... > > if (cnp->cn_nameiop != LOOKUP) { > > error = EISDIR; > > goto bad; > > } > > ... > > thanks a lot for finding the problem in the src. what do you think of the > patch attached to this message? after applying it the example code i posted in > my previous message returns the following output (instead of EISDIR): > > rmdir errno: 16 (which is EBUSY) > mkdir errno: 17 (which is EEXIST) > > i don't know if these really are the correct return values, but it's what the > originator of the PR requested. > What if cn_nameiop is != LOOKUP but also neither DELETE nor CREATE, assuming that case is possible? I'd leave the original if-clause at the end to catch that. --- Gary Jennejohn From gary.jennejohn at freenet.de Fri Nov 6 17:23:12 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri Nov 6 17:23:18 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: References: <20091106170853.7d0b0b6f@ernst.jennejohn.org> Message-ID: <20091106182308.14dffc50@ernst.jennejohn.org> On Fri, 06 Nov 2009 17:43:06 +0100 (CET) Alexander Best wrote: > Gary Jennejohn schrieb am 2009-11-06: > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > Alexander Best wrote: > > > > Alex Dupre schrieb am 2009-11-06: > > > > Alexander Best ha scritto: > > > > > i dug up this old pr > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > > lookup() > > > > function with cn_nameptr = "": > > > > > > /* > > > > * Check for degenerate name (e.g. / or "") > > > > * which is a way of talking about a directory, > > > > * e.g. like "/." or ".". > > > > */ > > > > if (cnp->cn_nameptr[0] == '\0') { > > > > ... > > > > if (cnp->cn_nameiop != LOOKUP) { > > > > error = EISDIR; > > > > goto bad; > > > > } > > > > ... > > > > thanks a lot for finding the problem in the src. what do you think > > > of the > > > patch attached to this message? after applying it the example code > > > i posted in > > > my previous message returns the following output (instead of > > > EISDIR): > > > > rmdir errno: 16 (which is EBUSY) > > > mkdir errno: 17 (which is EEXIST) > > > > i don't know if these really are the correct return values, but > > > it's what the > > > originator of the PR requested. > > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor CREATE, > > assuming that case is possible? I'd leave the original if-clause at > > the end to catch that. > > > --- > > Gary Jennejohn > > how about this patch? > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't think it's > necessary since the first blocks should cover all the possible cases. > 2. i've used rename() to test the case (cnp->cn_nameiop != RENAME). is this > correct or does rename() use a combo of DELETE and CREATE? problem is that the > rename(2) manual doesn't seem to cover the case that arg 1 is a mountpoint. > right now EBUSY gets returned if cnp->cn_nameiop != RENAME. however BUSY needs > to be added to all manuals which use cnp->cn_nameiop != RENAME (shouldn't be > too many). or are there any other suggestions what rename() should return if > arg 1 is a mountpoint? > Hmm. In rename(2) there's [EINVAL] The from argument is a parent directory of to, or an attempt is made to rename `.' or `..'. and a few lines below your patch this case is handled for ISDOTDOT for both RENAME and DELETE. I don't see off hand where renaming or deleting "." is handled. According to the comment above your patch the case of "/." or "." is being checked, which would seem to correspond to the above part of rename(2), i.e. perhaps EINVAL should be returned for RENAME and DELETE. --- Gary Jennejohn From alexbestms at math.uni-muenster.de Fri Nov 6 17:42:30 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 17:42:37 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <20091106182308.14dffc50@ernst.jennejohn.org> Message-ID: Gary Jennejohn schrieb am 2009-11-06: > On Fri, 06 Nov 2009 17:43:06 +0100 (CET) > Alexander Best wrote: > > Gary Jennejohn schrieb am 2009-11-06: > > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > > Alexander Best wrote: > > > > Alex Dupre schrieb am 2009-11-06: > > > > > Alexander Best ha scritto: > > > > > > i dug up this old pr > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > > > lookup() > > > > > function with cn_nameptr = "": > > > > > /* > > > > > * Check for degenerate name (e.g. / or "") > > > > > * which is a way of talking about a directory, > > > > > * e.g. like "/." or ".". > > > > > */ > > > > > if (cnp->cn_nameptr[0] == '\0') { > > > > > ... > > > > > if (cnp->cn_nameiop != LOOKUP) { > > > > > error = EISDIR; > > > > > goto bad; > > > > > } > > > > > ... > > > > thanks a lot for finding the problem in the src. what do you > > > > think > > > > of the > > > > patch attached to this message? after applying it the example > > > > code > > > > i posted in > > > > my previous message returns the following output (instead of > > > > EISDIR): > > > > rmdir errno: 16 (which is EBUSY) > > > > mkdir errno: 17 (which is EEXIST) > > > > i don't know if these really are the correct return values, but > > > > it's what the > > > > originator of the PR requested. > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor > > > CREATE, > > > assuming that case is possible? I'd leave the original if-clause > > > at > > > the end to catch that. > > > --- > > > Gary Jennejohn > > how about this patch? > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't > > think it's > > necessary since the first blocks should cover all the possible > > cases. > > 2. i've used rename() to test the case (cnp->cn_nameiop != RENAME). > > is this > > correct or does rename() use a combo of DELETE and CREATE? problem > > is that the > > rename(2) manual doesn't seem to cover the case that arg 1 is a > > mountpoint. > > right now EBUSY gets returned if cnp->cn_nameiop != RENAME. however > > BUSY needs > > to be added to all manuals which use cnp->cn_nameiop != RENAME > > (shouldn't be > > too many). or are there any other suggestions what rename() should > > return if > > arg 1 is a mountpoint? > Hmm. In rename(2) there's > [EINVAL] The from argument is a parent directory of to, or > an > attempt is made to rename `.' or `..'. > and a few lines below your patch this case is handled for ISDOTDOT > for both RENAME and DELETE. I don't see off hand where renaming or > deleting "." is handled. > According to the comment above your patch the case of "/." or "." is > being checked, which would seem to correspond to the above part of > rename(2), i.e. perhaps EINVAL should be returned for RENAME and > DELETE. > --- > Gary Jennejohn that would be an option. however in the case of rmdir(2) EINVAL and EBUYS would both fit. depends whether be forbid deletion of / because it is a mountpoint or because / is actually /. and paths ending with . are forbidden as arg in rmdir(2). i guess we have to take a look at the POSIX specs before we can decide how to handle this. also i've discovered that permission checks for / seem to be handled differently than any other dir. on my machine /usr is a mountpoint. doing rmdir /usr returns EACCES as regular user and EBUSY as superuser. doing rmdir / as regular user however doesn't seem to check permission but returns EBUSY right away. but that's not a problem i guess. this is probably happening because the kern/vfs_lookup.c code is being executed before anything else (including permission checks). i'll have a look what POSIX has to say about the return values. but i agree with you. returning EINVAL seems logical. alex. From alexbestms at math.uni-muenster.de Fri Nov 6 17:52:42 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 17:52:49 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: Message-ID: Alexander Best schrieb am 2009-11-06: > Gary Jennejohn schrieb am 2009-11-06: > > On Fri, 06 Nov 2009 17:43:06 +0100 (CET) > > Alexander Best wrote: > > > Gary Jennejohn schrieb am 2009-11-06: > > > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > > > Alexander Best wrote: > > > > > Alex Dupre schrieb am 2009-11-06: > > > > > > Alexander Best ha scritto: > > > > > > > i dug up this old pr > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > > > > lookup() > > > > > > function with cn_nameptr = "": > > > > > > /* > > > > > > * Check for degenerate name (e.g. / or "") > > > > > > * which is a way of talking about a directory, > > > > > > * e.g. like "/." or ".". > > > > > > */ > > > > > > if (cnp->cn_nameptr[0] == '\0') { > > > > > > ... > > > > > > if (cnp->cn_nameiop != LOOKUP) { > > > > > > error = EISDIR; > > > > > > goto bad; > > > > > > } > > > > > > ... > > > > > thanks a lot for finding the problem in the src. what do you > > > > > think > > > > > of the > > > > > patch attached to this message? after applying it the example > > > > > code > > > > > i posted in > > > > > my previous message returns the following output (instead of > > > > > EISDIR): > > > > > rmdir errno: 16 (which is EBUSY) > > > > > mkdir errno: 17 (which is EEXIST) > > > > > i don't know if these really are the correct return values, > > > > > but > > > > > it's what the > > > > > originator of the PR requested. > > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor > > > > CREATE, > > > > assuming that case is possible? I'd leave the original > > > > if-clause > > > > at > > > > the end to catch that. > > > > --- > > > > Gary Jennejohn > > > how about this patch? > > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't > > > think it's > > > necessary since the first blocks should cover all the possible > > > cases. > > > 2. i've used rename() to test the case (cnp->cn_nameiop != > > > RENAME). > > > is this > > > correct or does rename() use a combo of DELETE and CREATE? > > > problem > > > is that the > > > rename(2) manual doesn't seem to cover the case that arg 1 is a > > > mountpoint. > > > right now EBUSY gets returned if cnp->cn_nameiop != RENAME. > > > however > > > BUSY needs > > > to be added to all manuals which use cnp->cn_nameiop != RENAME > > > (shouldn't be > > > too many). or are there any other suggestions what rename() > > > should > > > return if > > > arg 1 is a mountpoint? > > Hmm. In rename(2) there's > > [EINVAL] The from argument is a parent directory of to, > > or > > an > > attempt is made to rename `.' or `..'. > > and a few lines below your patch this case is handled for ISDOTDOT > > for both RENAME and DELETE. I don't see off hand where renaming or > > deleting "." is handled. > > According to the comment above your patch the case of "/." or "." > > is > > being checked, which would seem to correspond to the above part of > > rename(2), i.e. perhaps EINVAL should be returned for RENAME and > > DELETE. > > --- > > Gary Jennejohn > that would be an option. however in the case of rmdir(2) EINVAL and > EBUYS > would both fit. depends whether be forbid deletion of / because it is > a > mountpoint or because / is actually /. and paths ending with . are > forbidden > as arg in rmdir(2). > i guess we have to take a look at the POSIX specs before we can > decide how to > handle this. > also i've discovered that permission checks for / seem to be handled > differently than any other dir. on my machine /usr is a mountpoint. > doing > rmdir /usr returns EACCES as regular user and EBUSY as superuser. > doing rmdir > / as regular user however doesn't seem to check permission but > returns EBUSY > right away. but that's not a problem i guess. this is probably > happening > because the kern/vfs_lookup.c code is being executed before anything > else > (including permission checks). > i'll have a look what POSIX has to say about the return values. but i > agree > with you. returning EINVAL seems logical. > alex. ok. here it goes. POSIX says: rmdir() [http://www.opengroup.org/onlinepubs/9699919799/functions/rmdir.html#tag_16_618]: If the directory is the root directory or the current working directory of any process, it is unspecified whether the function succeeds, or whether it shall fail and set errno to [EBUSY]. mkdir() [http://www.opengroup.org/onlinepubs/9699919799/functions/mkdir.html#tag_16_372]: nothing regarding /. rename() [http://www.opengroup.org/onlinepubs/9699919799/functions/rename.html#tag_16_614]: If either pathname argument refers to a path whose final component is either dot or dot-dot, rename() shall fail. so at least rmdir() should return EBUSY. also POSIX defines EBUSY for return() which isn't documented in our return(2) manual. alex From anti_spamsys at yahoo.com Fri Nov 6 19:19:52 2009 From: anti_spamsys at yahoo.com (Trever) Date: Fri Nov 6 19:19:58 2009 Subject: Why is default value of NKPT so small? mfsroot Message-ID: <761362.20406.qm@web113204.mail.gq1.yahoo.com> Does anyone know what the thinking is behind the default value of NKTP in /usr/src/sys/i386/include/pmap.h? It seems to me that it's too small, though I'm wondering if there are some considerations in changing it's value that I should know about. Too small because: making it a little more than twice as large (so you can get about a 300MB mfsroot to boot) means you can (by default) boot a standard FreeBSD system into memory, and I know I can't be the only one who would value that a great deal for many reasons. As it stands you have to ax things out (like depenguinator does, for example). Or you have to recompile the kernel. Does it have to be like this? Which leads me to two more questions: - is it possible to change the NKTP value without recompiling the kernel? I think there isn't but I'll ask. - is it possible to change the NKTP value without editing pmap.h (can I pass a variable into the kernel build process)? Thanks, Trever From alexbestms at math.uni-muenster.de Fri Nov 6 19:27:58 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 19:28:04 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: Message-ID: Alexander Best schrieb am 2009-11-06: > Alexander Best schrieb am 2009-11-06: > > Gary Jennejohn schrieb am 2009-11-06: > > > On Fri, 06 Nov 2009 17:43:06 +0100 (CET) > > > Alexander Best wrote: > > > > Gary Jennejohn schrieb am 2009-11-06: > > > > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > > > > Alexander Best wrote: > > > > > > Alex Dupre schrieb am 2009-11-06: > > > > > > > Alexander Best ha scritto: > > > > > > > > i dug up this old pr > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > > > > > I think the EISDIR error is coming from > > > > > > > kern/vfs_lookup.c, > > > > > > > lookup() > > > > > > > function with cn_nameptr = "": > > > > > > > /* > > > > > > > * Check for degenerate name (e.g. / or "") > > > > > > > * which is a way of talking about a directory, > > > > > > > * e.g. like "/." or ".". > > > > > > > */ > > > > > > > if (cnp->cn_nameptr[0] == '\0') { > > > > > > > ... > > > > > > > if (cnp->cn_nameiop != LOOKUP) { > > > > > > > error = EISDIR; > > > > > > > goto bad; > > > > > > > } > > > > > > > ... > > > > > > thanks a lot for finding the problem in the src. what do > > > > > > you > > > > > > think > > > > > > of the > > > > > > patch attached to this message? after applying it the > > > > > > example > > > > > > code > > > > > > i posted in > > > > > > my previous message returns the following output (instead > > > > > > of > > > > > > EISDIR): > > > > > > rmdir errno: 16 (which is EBUSY) > > > > > > mkdir errno: 17 (which is EEXIST) > > > > > > i don't know if these really are the correct return values, > > > > > > but > > > > > > it's what the > > > > > > originator of the PR requested. > > > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor > > > > > CREATE, > > > > > assuming that case is possible? I'd leave the original > > > > > if-clause > > > > > at > > > > > the end to catch that. > > > > > --- > > > > > Gary Jennejohn > > > > how about this patch? > > > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't > > > > think it's > > > > necessary since the first blocks should cover all the possible > > > > cases. > > > > 2. i've used rename() to test the case (cnp->cn_nameiop != > > > > RENAME). > > > > is this > > > > correct or does rename() use a combo of DELETE and CREATE? > > > > problem > > > > is that the > > > > rename(2) manual doesn't seem to cover the case that arg 1 is a > > > > mountpoint. > > > > right now EBUSY gets returned if cnp->cn_nameiop != RENAME. > > > > however > > > > BUSY needs > > > > to be added to all manuals which use cnp->cn_nameiop != RENAME > > > > (shouldn't be > > > > too many). or are there any other suggestions what rename() > > > > should > > > > return if > > > > arg 1 is a mountpoint? > > > Hmm. In rename(2) there's > > > [EINVAL] The from argument is a parent directory of to, > > > or > > > an > > > attempt is made to rename `.' or `..'. > > > and a few lines below your patch this case is handled for > > > ISDOTDOT > > > for both RENAME and DELETE. I don't see off hand where renaming > > > or > > > deleting "." is handled. > > > According to the comment above your patch the case of "/." or "." > > > is > > > being checked, which would seem to correspond to the above part > > > of > > > rename(2), i.e. perhaps EINVAL should be returned for RENAME and > > > DELETE. > > > --- > > > Gary Jennejohn > > that would be an option. however in the case of rmdir(2) EINVAL and > > EBUYS > > would both fit. depends whether be forbid deletion of / because it > > is > > a > > mountpoint or because / is actually /. and paths ending with . are > > forbidden > > as arg in rmdir(2). > > i guess we have to take a look at the POSIX specs before we can > > decide how to > > handle this. > > also i've discovered that permission checks for / seem to be > > handled > > differently than any other dir. on my machine /usr is a mountpoint. > > doing > > rmdir /usr returns EACCES as regular user and EBUSY as superuser. > > doing rmdir > > / as regular user however doesn't seem to check permission but > > returns EBUSY > > right away. but that's not a problem i guess. this is probably > > happening > > because the kern/vfs_lookup.c code is being executed before > > anything > > else > > (including permission checks). > > i'll have a look what POSIX has to say about the return values. but > > i > > agree > > with you. returning EINVAL seems logical. > > alex. > ok. here it goes. POSIX says: > rmdir() > [http://www.opengroup.org/onlinepubs/9699919799/functions/rmdir.html#tag_16_618]: > If the directory is the root directory or the current working > directory of any > process, it is unspecified whether the function succeeds, or whether > it shall > fail and set errno to [EBUSY]. > mkdir() > [http://www.opengroup.org/onlinepubs/9699919799/functions/mkdir.html#tag_16_372]: > nothing regarding /. > rename() > [http://www.opengroup.org/onlinepubs/9699919799/functions/rename.html#tag_16_614]: > If either pathname argument refers to a path whose final component is > either > dot or dot-dot, rename() shall fail. > so at least rmdir() should return EBUSY. also POSIX defines EBUSY for > return() > which isn't documented in our return(2) manual. > alex this is getting a bit more complicated now. i've had a look at kern/vfs_syscalls.c where the basic rmdir(), rename() and mkdir() cals are being defined. looks like they themself set certain errno values, but those values get overwritten by kern/vfs_lookup.c i guess the right approach would be this one: if rmdir(), rename() or mkdir() is called with / set errno=EISDIR in kern/vfs_lookup.c. then in kern/vfs_syscalls.c do something like if(errno == EISDIR) return XXX; XXX being EBUSY for rmdir(), EINVAL for rename(), etc. i'll see if i can get this sorted out. alex From alexbestms at math.uni-muenster.de Fri Nov 6 21:09:59 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 21:10:06 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <20091106182308.14dffc50@ernst.jennejohn.org> Message-ID: Gary Jennejohn schrieb am 2009-11-06: > On Fri, 06 Nov 2009 17:43:06 +0100 (CET) > Alexander Best wrote: > > Gary Jennejohn schrieb am 2009-11-06: > > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > > Alexander Best wrote: > > > > Alex Dupre schrieb am 2009-11-06: > > > > > Alexander Best ha scritto: > > > > > > i dug up this old pr > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > > > lookup() > > > > > function with cn_nameptr = "": > > > > > /* > > > > > * Check for degenerate name (e.g. / or "") > > > > > * which is a way of talking about a directory, > > > > > * e.g. like "/." or ".". > > > > > */ > > > > > if (cnp->cn_nameptr[0] == '\0') { > > > > > ... > > > > > if (cnp->cn_nameiop != LOOKUP) { > > > > > error = EISDIR; > > > > > goto bad; > > > > > } > > > > > ... > > > > thanks a lot for finding the problem in the src. what do you > > > > think > > > > of the > > > > patch attached to this message? after applying it the example > > > > code > > > > i posted in > > > > my previous message returns the following output (instead of > > > > EISDIR): > > > > rmdir errno: 16 (which is EBUSY) > > > > mkdir errno: 17 (which is EEXIST) > > > > i don't know if these really are the correct return values, but > > > > it's what the > > > > originator of the PR requested. > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor > > > CREATE, > > > assuming that case is possible? I'd leave the original if-clause > > > at > > > the end to catch that. > > > --- > > > Gary Jennejohn > > how about this patch? > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't > > think it's > > necessary since the first blocks should cover all the possible > > cases. > > 2. i've used rename() to test the case (cnp->cn_nameiop != RENAME). > > is this > > correct or does rename() use a combo of DELETE and CREATE? problem > > is that the > > rename(2) manual doesn't seem to cover the case that arg 1 is a > > mountpoint. > > right now EBUSY gets returned if cnp->cn_nameiop != RENAME. however > > BUSY needs > > to be added to all manuals which use cnp->cn_nameiop != RENAME > > (shouldn't be > > too many). or are there any other suggestions what rename() should > > return if > > arg 1 is a mountpoint? > Hmm. In rename(2) there's > [EINVAL] The from argument is a parent directory of to, or > an > attempt is made to rename `.' or `..'. > and a few lines below your patch this case is handled for ISDOTDOT > for both RENAME and DELETE. I don't see off hand where renaming or > deleting "." is handled. > According to the comment above your patch the case of "/." or "." is > being checked, which would seem to correspond to the above part of > rename(2), i.e. perhaps EINVAL should be returned for RENAME and > DELETE. > --- > Gary Jennejohn here's a completely new patch. all the changes are in kern/vfs_syscall.c. so kern/vfs_lookup.c now stays just the way it is (please revert any changes from the previous patches i posted). after applying the patch this is the output from a slightly modified version of the test app i attached in my very first post: rmdir errno: 16 (EBUSY) <- EBUSY is required by POSIX mkdir errno: 17 (EEXIST) rename errno: 22 (EINVAL) these are the results when called with "/" as arg. the output doesn't differ if run with or without superuser privileges. when run with "." as arg this is the output as regular user: rmdir errno: 22 (EINVAL) mkdir errno: 17 (EEXIST) rename errno: 13 (EACCES) and as superuser: rmdir errno: 22 (EINVAL) mkdir errno: 17 (EEXIST) rename errno: 22 (EINVAL) does this look reasonable? would be nice if mkdir and rmdir would also check privileges at first like rename, but that's a different story i guess. ;) alex -------------- next part -------------- --- vfs_syscalls.c 2009-11-06 22:07:08.000000000 +0100 +++ /usr/src/sys/kern/vfs_syscalls.c 2009-11-06 21:37:47.000000000 +0100 @@ -35,7 +35,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: head/sys/kern/vfs_syscalls.c 196887 2009-09-06 11:44:46Z kib $"); #include "opt_compat.h" #include "opt_kdtrace.h" @@ -3587,8 +3587,12 @@ AUDITVNODE1, pathseg, old, oldfd, td); #endif - if ((error = namei(&fromnd)) != 0) + if ((error = namei(&fromnd)) != 0) { + /* Translate error code for rename("/", "dir2"). */ + if (error == EISDIR) + error = EINVAL; return (error); + } fvfslocked = NDHASGIANT(&fromnd); tvfslocked = 0; #ifdef MAC @@ -3737,8 +3741,12 @@ NDINIT_AT(&nd, CREATE, LOCKPARENT | SAVENAME | MPSAFE | AUDITVNODE1, segflg, path, fd, td); nd.ni_cnd.cn_flags |= WILLBEDIR; - if ((error = namei(&nd)) != 0) + if ((error = namei(&nd)) != 0) { + /* Translate error code for mkdir("/"). */ + if (error == EISDIR) + error = EEXIST; return (error); + } vfslocked = NDHASGIANT(&nd); vp = nd.ni_vp; if (vp != NULL) { @@ -3825,10 +3833,15 @@ bwillwrite(); NDINIT_AT(&nd, DELETE, LOCKPARENT | LOCKLEAF | MPSAFE | AUDITVNODE1, pathseg, path, fd, td); - if ((error = namei(&nd)) != 0) + if ((error = namei(&nd)) != 0) { + /* Translate error code for rmdir("/"). */ + if (error == EISDIR) + error = EBUSY; return (error); + } vfslocked = NDHASGIANT(&nd); vp = nd.ni_vp; + /* XXX namei() takes care of this case. */ if (vp->v_type != VDIR) { error = ENOTDIR; goto out; @@ -3841,6 +3854,7 @@ goto out; } /* + * XXX namei() takes care of this case. * The root of a mounted filesystem cannot be deleted. */ if (vp->v_vflag & VV_ROOT) { From alexbestms at math.uni-muenster.de Fri Nov 6 21:34:12 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Nov 6 21:34:19 2009 Subject: SIGUNUSED Message-ID: some programmers tend to do the following in their apps to install a standard handler for all signals (mostly SIG_IGN): int counter; for (counter = 1; counter < SIGUNUSED; counter++) signal(counter, SIG_IGN); any objections if we also have SIGUNUSED in our signal.h? seems like a reasonable addition. since the highest signal number (excluding SIGRT[MIN|MAX]) is SIGTHR with 32 we could add #define SIGUNUSED 33 alex. From jilles at stack.nl Fri Nov 6 22:11:52 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Nov 6 22:11:59 2009 Subject: SIGUNUSED In-Reply-To: References: Message-ID: <20091106221150.GA60707@stack.nl> On Fri, Nov 06, 2009 at 10:33:57PM +0100, Alexander Best wrote: > some programmers tend to do the following in their apps to install a standard > handler for all signals (mostly SIG_IGN): > int counter; > for (counter = 1; counter < SIGUNUSED; counter++) > signal(counter, SIG_IGN); > any objections if we also have SIGUNUSED in our signal.h? seems like a > reasonable addition. since the highest signal number (excluding > SIGRT[MIN|MAX]) is SIGTHR with 32 we could add > #define SIGUNUSED 33 That code is wrong, SIGUNUSED is not meant to be used in that way. It seems to originate from Linux, but it is not available on all architectures there, and where it is available it is a valid signal. Also, ignoring all signals tends not to be a good idea. For traps, it's either the same as the default action (FreeBSD unless admin sets kern.forcesigexit=0), or it is an infinite loop or other undefined behaviour. -- Jilles Tjoelker From jilles at stack.nl Fri Nov 6 22:24:47 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Nov 6 22:24:54 2009 Subject: [patch] add pwait utility Message-ID: <20091106222446.GB60707@stack.nl> I propose adding a small new utility to /usr/bin: pwait. Similar to the Solaris utility of the same name, it waits for any process to terminate. Some use cases I have in mind: * rc.subr's wait_for_pids. This is a cleaner and more efficient fix for PR conf/132766. In the rare case that /usr is not available, the old sleep(1) method can be used. * interactive use, e.g. to shut down the computer when some task is done even if the task is already running -- Jilles Tjoelker -------------- next part -------------- A non-text attachment was scrubbed... Name: pwait.patch Type: text/x-diff Size: 7561 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091106/75d12b9b/pwait.bin From alexbestms at math.uni-muenster.de Sat Nov 7 02:17:52 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Nov 7 02:17:58 2009 Subject: SIGUNUSED In-Reply-To: <20091106221150.GA60707@stack.nl> Message-ID: Jilles Tjoelker schrieb am 2009-11-06: > On Fri, Nov 06, 2009 at 10:33:57PM +0100, Alexander Best wrote: > > some programmers tend to do the following in their apps to install > > a standard > > handler for all signals (mostly SIG_IGN): > > int counter; > > for (counter = 1; counter < SIGUNUSED; counter++) > > signal(counter, SIG_IGN); > > any objections if we also have SIGUNUSED in our signal.h? seems > > like a > > reasonable addition. since the highest signal number (excluding > > SIGRT[MIN|MAX]) is SIGTHR with 32 we could add > > #define SIGUNUSED 33 > That code is wrong, SIGUNUSED is not meant to be used in that way. It > seems to originate from Linux, but it is not available on all > architectures there, and where it is available it is a valid signal. > Also, ignoring all signals tends not to be a good idea. For traps, > it's > either the same as the default action (FreeBSD unless admin sets > kern.forcesigexit=0), or it is an infinite loop or other undefined > behaviour. oh. i see. i'm not a linux user. that's why i thought SIGUNUSED was designed exactly for that purpose. as a side not: our own easyedit does exactly what you said wasn't a good programming style. ;) check line 554 of contrib/ee/ee.c: for (counter = 1; counter < 24; counter++) signal(counter, SIG_IGN); cheers. alex From nate at thatsmathematics.com Sat Nov 7 02:34:12 2009 From: nate at thatsmathematics.com (Nate Eldredge) Date: Sat Nov 7 02:34:43 2009 Subject: SIGUNUSED In-Reply-To: References: Message-ID: On Sat, 7 Nov 2009, Alexander Best wrote: > Jilles Tjoelker schrieb am 2009-11-06: >> On Fri, Nov 06, 2009 at 10:33:57PM +0100, Alexander Best wrote: >>> some programmers tend to do the following in their apps to install >>> a standard >>> handler for all signals (mostly SIG_IGN): > >>> int counter; > >>> for (counter = 1; counter < SIGUNUSED; counter++) >>> signal(counter, SIG_IGN); >> That code is wrong, SIGUNUSED is not meant to be used in that way. It >> seems to originate from Linux, but it is not available on all >> architectures there, and where it is available it is a valid signal. > oh. i see. i'm not a linux user. that's why i thought SIGUNUSED was designed > exactly for that purpose. I think that's what NSIG was for. But it seems to be BSD-specific, and perhaps obsolecent. -- Nate Eldredge nate@thatsmathematics.com From sam at freebsd.org Sat Nov 7 04:19:25 2009 From: sam at freebsd.org (Sam Leffler) Date: Sat Nov 7 04:19:32 2009 Subject: Mesh networking In-Reply-To: References: Message-ID: <4AF4EEE6.4080605@freebsd.org> Nick Hibma wrote: > Anyone interested in Mesh networking might want to have a look at > > http://meshcom.com/en/products/meshdriver/ > > We have started to use the mesh driver (ok, on voyage linux). A port > should not be difficult, especially the userland daemon. It's > dependencies on Linux syscalls are minimal. > > Starting it through linux emulation does not work (in my FreeBSD setup). > > Meshcom says they are happy to look at the port when it is done. People have been doing L3 mesh for years. It has it's limitations. We already have 802.11s support which is the right way to go. The only limitation right now is the lack of crypto (D4.0 should have something usable but adding support will take a while). Sam From uqs at spoerlein.net Sat Nov 7 07:02:04 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Sat Nov 7 07:02:14 2009 Subject: [patch] add pwait utility In-Reply-To: <20091106222446.GB60707@stack.nl> References: <20091106222446.GB60707@stack.nl> Message-ID: <20091107070201.GF34407@acme.spoerlein.net> On Fri, 06.11.2009 at 23:24:46 +0100, Jilles Tjoelker wrote: > I propose adding a small new utility to /usr/bin: pwait. Similar to the > Solaris utility of the same name, it waits for any process to terminate. > Some use cases I have in mind: > > * rc.subr's wait_for_pids. This is a cleaner and more efficient fix for > PR conf/132766. In the rare case that /usr is not available, the old > sleep(1) method can be used. > * interactive use, e.g. to shut down the computer when some task is done > even if the task is already running Hi Jilles, this is great! I found no sleep(3) calls in the code and it looks like the kevent stuff will make pwait exit the instant the PID is gone. This is really nice and should be used to improve wait_for_pids. I understand that shutdown duration is of zero importance for server operations, but when using FreeBSD on the desktop or laptop I often do "halt -p", just because it is seriously faster and I know the implications. A slower machine of mine is calling sleep(1) inside wait_for_pid way too often during shutdown. I'd also vote to reduce the sleep(1) call from 2s to 0.5s. Gotta do some benchmarking here ... Regards, Uli From gary.jennejohn at freenet.de Sat Nov 7 10:09:38 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Nov 7 10:09:46 2009 Subject: Why is default value of NKPT so small? mfsroot In-Reply-To: <761362.20406.qm@web113204.mail.gq1.yahoo.com> References: <761362.20406.qm@web113204.mail.gq1.yahoo.com> Message-ID: <20091107110935.0cb624b9@ernst.jennejohn.org> On Fri, 6 Nov 2009 11:19:51 -0800 (PST) Trever wrote: > Does anyone know what the thinking is behind the default value of NKTP in /usr/src/sys/i386/include/pmap.h? > Seems to be based on the maximum amount of usable memory. If you define PAE then it's set to 240. For AMD64 it's set to 32. > Which leads me to two more questions: > - is it possible to change the NKTP value without recompiling the kernel? I think there isn't but I'll ask. No. > - is it possible to change the NKTP value without editing pmap.h (can I pass a variable into the kernel build process)? > Well, the header files all semm to have "#ifndef NKPT" in them. Try doing "NKPT=xxx;export NKPT" before compiling the kernel and see what happens. --- Gary Jennejohn From gary.jennejohn at freenet.de Sat Nov 7 10:21:18 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Nov 7 10:21:25 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: References: <20091106182308.14dffc50@ernst.jennejohn.org> Message-ID: <20091107112116.50eb45ee@ernst.jennejohn.org> On Fri, 06 Nov 2009 22:09:49 +0100 (CET) Alexander Best wrote: > here's a completely new patch. all the changes are in kern/vfs_syscall.c. so > kern/vfs_lookup.c now stays just the way it is (please revert any changes from > the previous patches i posted). > > after applying the patch this is the output from a slightly modified version > of the test app i attached in my very first post: > > rmdir errno: 16 (EBUSY) <- EBUSY is required by POSIX > mkdir errno: 17 (EEXIST) > rename errno: 22 (EINVAL) > > these are the results when called with "/" as arg. the output doesn't differ > if run with or without superuser privileges. > > when run with "." as arg this is the output as regular user: > > rmdir errno: 22 (EINVAL) > mkdir errno: 17 (EEXIST) > rename errno: 13 (EACCES) > > and as superuser: > > rmdir errno: 22 (EINVAL) > mkdir errno: 17 (EEXIST) > rename errno: 22 (EINVAL) > > does this look reasonable? would be nice if mkdir and rmdir would also check > privileges at first like rename, but that's a different story i guess. ;) > The only problem I see with this is that vfs_syscall.c now has knowledge about the internal details of vfs_lookup.c Maybe just mention in the comments that this is the case and could be a problem if vfs_lookup.c is changed for some reason? That's what I do when I have to use something like this. But we don't want to turn this into a gigantic bikeshed - we already have enough of those. --- Gary Jennejohn From gary.jennejohn at freenet.de Sat Nov 7 10:28:35 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Nov 7 10:28:43 2009 Subject: [patch] add pwait utility In-Reply-To: <20091106222446.GB60707@stack.nl> References: <20091106222446.GB60707@stack.nl> Message-ID: <20091107112832.24b0c0d4@ernst.jennejohn.org> On Fri, 6 Nov 2009 23:24:46 +0100 Jilles Tjoelker wrote: > I propose adding a small new utility to /usr/bin: pwait. Similar to the > Solaris utility of the same name, it waits for any process to terminate. > Why not /bin so it can be used before /usr is mounted? --- Gary Jennejohn From alexbestms at math.uni-muenster.de Sat Nov 7 11:45:35 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Nov 7 11:45:42 2009 Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" In-Reply-To: <20091107112116.50eb45ee@ernst.jennejohn.org> Message-ID: Gary Jennejohn schrieb am 2009-11-07: > On Fri, 06 Nov 2009 22:09:49 +0100 (CET) > Alexander Best wrote: > > here's a completely new patch. all the changes are in > > kern/vfs_syscall.c. so > > kern/vfs_lookup.c now stays just the way it is (please revert any > > changes from > > the previous patches i posted). > > after applying the patch this is the output from a slightly > > modified version > > of the test app i attached in my very first post: > > rmdir errno: 16 (EBUSY) <- EBUSY is required by POSIX > > mkdir errno: 17 (EEXIST) > > rename errno: 22 (EINVAL) > > these are the results when called with "/" as arg. the output > > doesn't differ > > if run with or without superuser privileges. > > when run with "." as arg this is the output as regular user: > > rmdir errno: 22 (EINVAL) > > mkdir errno: 17 (EEXIST) > > rename errno: 13 (EACCES) > > and as superuser: > > rmdir errno: 22 (EINVAL) > > mkdir errno: 17 (EEXIST) > > rename errno: 22 (EINVAL) > > does this look reasonable? would be nice if mkdir and rmdir would > > also check > > privileges at first like rename, but that's a different story i > > guess. ;) > The only problem I see with this is that vfs_syscall.c now has > knowledge > about the internal details of vfs_lookup.c > Maybe just mention in the comments that this is the case and could be > a problem if vfs_lookup.c is changed for some reason? That's what I > do when I have to use something like this. > But we don't want to turn this into a gigantic bikeshed - we already > have enough of those. > --- > Gary Jennejohn well like you said there are 2 possibilities of dealing with this: 1. in vfs_lookup.c or 2. in vfs_syscall.c personally i think vfs_syscall.c is the better solution. i only tested rmdir(), rename() and mkdir(). however lots of other apps/functions might be depending on vfs_lookup.c and are expecting namei() to return EISDIR for arg="/". if we change this behaviour we might break a lot of other stuff. also looking at vfs_syscall.c shows that a lot of code in there already depends and knows about vfs_lookup.c internal details. so we wouldn't be changing the whole vfs_syscall.c semantics. but you're right. this is the perfect topic for a bikeshed. ;) i'll wait for a few more days and if nobody has a problem with the last patch i'll submitted it as followup to kern/59739. thanks a lot for your help. :) cheers. alex From eugen at eg.sd.rdtc.ru Sat Nov 7 07:41:05 2009 From: eugen at eg.sd.rdtc.ru (Eugene Grosbein) Date: Sat Nov 7 12:25:58 2009 Subject: [patch] add pwait utility In-Reply-To: <20091106222446.GB60707@stack.nl> References: <20091106222446.GB60707@stack.nl> Message-ID: <20091107072854.GC14078@rdtc.ru> On Fri, Nov 06, 2009 at 11:24:46PM +0100, Jilles Tjoelker wrote: > I propose adding a small new utility to /usr/bin: pwait. Similar to the > Solaris utility of the same name, it waits for any process to terminate. > Some use cases I have in mind: > > * rc.subr's wait_for_pids. This is a cleaner and more efficient fix for > PR conf/132766. In the rare case that /usr is not available, the old > sleep(1) method can be used. > * interactive use, e.g. to shut down the computer when some task is done > even if the task is already running I've always missed such command exactly for later case :-) Vote for it. Eugene Grosbein From eugen at eg.sd.rdtc.ru Sat Nov 7 07:41:08 2009 From: eugen at eg.sd.rdtc.ru (Eugene Grosbein) Date: Sat Nov 7 12:26:11 2009 Subject: SIGUNUSED In-Reply-To: References: <20091106221150.GA60707@stack.nl> Message-ID: <20091107072622.GB14078@rdtc.ru> On Sat, Nov 07, 2009 at 03:17:49AM +0100, Alexander Best wrote: > as a side not: > our own easyedit does exactly what you said wasn't a good programming style. > ;) check line 554 of contrib/ee/ee.c: > > for (counter = 1; counter < 24; counter++) > signal(counter, SIG_IGN); Easy Editor is contributed software (now lives in contrib/). Such naive signgal handling had already hurt it in the past, f.e. plain ignore of SIGTTIN, SIGTTOU without sanity checks for STDIN_FILENO, STDOUT_FILENO made it CPU hog for 'ee file &' or 'ee References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> Message-ID: <20091107130136.GI2331@deviant.kiev.zoral.com.ua> On Sat, Nov 07, 2009 at 11:28:32AM +0100, Gary Jennejohn wrote: > On Fri, 6 Nov 2009 23:24:46 +0100 > Jilles Tjoelker wrote: > > > I propose adding a small new utility to /usr/bin: pwait. Similar to the > > Solaris utility of the same name, it waits for any process to terminate. > > > > Why not /bin so it can be used before /usr is mounted? And it seems to make sense to add this functionality to pkill/pgrep binary, creating another hardlink to it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091107/7166c9c8/attachment.pgp From rpaulo at freebsd.org Sat Nov 7 13:50:51 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sat Nov 7 13:50:58 2009 Subject: [patch] add pwait utility In-Reply-To: <20091107070201.GF34407@acme.spoerlein.net> References: <20091106222446.GB60707@stack.nl> <20091107070201.GF34407@acme.spoerlein.net> Message-ID: <9FCC2EE8-D9B1-4283-A022-C4B94FE0642C@freebsd.org> On 7 Nov 2009, at 07:02, Ulrich Sp?rlein wrote: > I understand that shutdown duration is of zero importance for server > operations, FWIW, I don't agree with this. -- Rui Paulo From des at des.no Sat Nov 7 15:48:01 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Nov 7 15:48:08 2009 Subject: SIGUNUSED In-Reply-To: <20091106221150.GA60707@stack.nl> (Jilles Tjoelker's message of "Fri, 6 Nov 2009 23:11:50 +0100") References: <20091106221150.GA60707@stack.nl> Message-ID: <867hu2gwuo.fsf@ds4.des.no> Jilles Tjoelker writes: > That code is wrong, SIGUNUSED is not meant to be used in that way. It > seems to originate from Linux, but it is not available on all > architectures there, and where it is available it is a valid signal. >From signal(7): SIGUNUSED -,31,- Term Unused signal (will be SIGSYS) and there is no higher-numbered signal, but the -s mean it is not available on at alpha, sparc64 or mips. There is no reference to it in any section 2 or 3 man page. DES -- Dag-Erling Sm?rgrav - des@des.no From jilles at stack.nl Sat Nov 7 20:19:55 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Nov 7 20:20:04 2009 Subject: [patch] add pwait utility In-Reply-To: <20091107130136.GI2331@deviant.kiev.zoral.com.ua> References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> <20091107130136.GI2331@deviant.kiev.zoral.com.ua> Message-ID: <20091107201954.GA84099@stack.nl> On Sat, Nov 07, 2009 at 03:01:36PM +0200, Kostik Belousov wrote: > On Sat, Nov 07, 2009 at 11:28:32AM +0100, Gary Jennejohn wrote: > > On Fri, 6 Nov 2009 23:24:46 +0100 > > Jilles Tjoelker wrote: > > > I propose adding a small new utility to /usr/bin: pwait. Similar to the > > > Solaris utility of the same name, it waits for any process to terminate. > > Why not /bin so it can be used before /usr is mounted? > And it seems to make sense to add this functionality to pkill/pgrep > binary, creating another hardlink to it. Hmm, pwait's syntax is incompatible: it takes pids (pkill says: use kill) and the -v option does something totally different. -- Jilles Tjoelker From dougb at FreeBSD.org Sat Nov 7 20:27:39 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Nov 7 20:27:45 2009 Subject: [patch] add pwait utility In-Reply-To: <20091107201954.GA84099@stack.nl> References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> <20091107130136.GI2331@deviant.kiev.zoral.com.ua> <20091107201954.GA84099@stack.nl> Message-ID: <4AF5D840.6090707@FreeBSD.org> Jilles Tjoelker wrote: > On Sat, Nov 07, 2009 at 03:01:36PM +0200, Kostik Belousov wrote: >> On Sat, Nov 07, 2009 at 11:28:32AM +0100, Gary Jennejohn wrote: >>> On Fri, 6 Nov 2009 23:24:46 +0100 >>> Jilles Tjoelker wrote: > >>>> I propose adding a small new utility to /usr/bin: pwait. Similar to the >>>> Solaris utility of the same name, it waits for any process to terminate. > >>> Why not /bin so it can be used before /usr is mounted? I agree. It's such a tiny thing there's no reason not to put it in /bin, and the potential benefits (being able to use it when /usr is not present) far outweigh the costs. >> And it seems to make sense to add this functionality to pkill/pgrep >> binary, creating another hardlink to it. > > Hmm, pwait's syntax is incompatible: it takes pids (pkill says: use > kill) and the -v option does something totally different. I agree with Jilles, I don't see any reason to complicate this. If there is some reason that pkill/pgrep would need the functionality internally then the pwait stuff could be turned into a library, but I don't think that's what Kostik was proposing. When you get this committed (in whatever form) send a note to freebsd-rc@freebsd.org so that we can look at re-implementing wait_for_pids with this. I think this is a very nice addition, thanks for taking it on. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From gabor at FreeBSD.org Sat Nov 7 21:17:15 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Sat Nov 7 21:17:21 2009 Subject: [patch] add pwait utility In-Reply-To: <20091107201954.GA84099@stack.nl> References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> <20091107130136.GI2331@deviant.kiev.zoral.com.ua> <20091107201954.GA84099@stack.nl> Message-ID: <4AF5E3D5.3050009@FreeBSD.org> Jilles Tjoelker escribi?: >> And it seems to make sense to add this functionality to pkill/pgrep >> binary, creating another hardlink to it. >> > > Hmm, pwait's syntax is incompatible: it takes pids (pkill says: use > kill) and the -v option does something totally different. > That's not an issue. You can declare extern char *__progname; and use it to parse the command line arguments in a different way. Of course, it only makes sense if pkill/pgrep has some inner functionality you can make use of to avoid duplication. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From alexbestms at math.uni-muenster.de Sun Nov 8 02:19:15 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Nov 8 02:19:21 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't Message-ID: no problem. i've sent the final patch as followup to kern/71258 and also attached it to this message. to make it short. what's being changed by the patch: 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL 2) if MAP_STACK is defined and offset !=0 ====> offset = 0 would be great if you could have a look at the patch if you've got a spare minute. cheers. alex -------------- next part -------------- Index: sys/vm/vm_mmap.c =================================================================== --- sys/vm/vm_mmap.c (revision 199016) +++ sys/vm/vm_mmap.c (working copy) @@ -244,6 +244,9 @@ pos = 0; } + if (flags & MAP_ANON && pos != 0) + return (EINVAL); + /* * Align the file position to a page boundary, * and save its page offset component. @@ -300,7 +303,6 @@ handle = NULL; handle_type = OBJT_DEFAULT; maxprot = VM_PROT_ALL; - pos = 0; } else { /* * Mapping file, get fp for validation and From randyhyde at me.com Sun Nov 8 17:32:41 2009 From: randyhyde at me.com (Randall Hyde) Date: Sun Nov 8 18:00:29 2009 Subject: HLA v2.6 for FreeBSD is now available Message-ID: <99460406942256701304784967284744984406-Webmail@me.com> Hi All, HLA v2.6 for FreeBSD is now available from the HLA download site on Webster: http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/HighLevelAsm/dnld.html v2.6 includes full PE/COFF native code generation for Win32, ELF native code generation for Linux and FreeBSD, and Mach-O native code generation for Mac OS X. v2.6 also implements a new overloads declaration for high-level-like procedure, method, and iterator calls. This is above and beyond the usual set of defect corrections. HLA is a high-level 32-bit x86 assembler that supports the 32-bit 80x86 instruction set as well as adding a set of high-level-like language features. More information on HLA is available at http://webster.cs.ucr.edu. Cheers, Randy Hyde From alexbestms at math.uni-muenster.de Mon Nov 9 00:47:51 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 9 00:47:58 2009 Subject: [patch] burncd: honour for envar SPEED Message-ID: any thoughts on these small changes to burncd? alex -------------- next part -------------- Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -78,13 +78,16 @@ { int arg, addr, ch, fd; int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; + int nogap = 0, speed = 0, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; const char *dev; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + if ((speed = getenv("SPEED")) == NULL) + speed = 4 * 177; + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -164,6 +164,12 @@ .Fl f flag. .El +.Bl -tag -width ".Ev SPEED" +.It Ev SPEED +The write speed to use if one is not specified with the +.Fl s +flag. +.El .Sh FILES .Bl -tag -width ".Pa /dev/acd0" .It Pa /dev/acd0 From gabor at FreeBSD.org Mon Nov 9 00:53:22 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Mon Nov 9 00:53:29 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: References: Message-ID: <4AF767FA.7040004@FreeBSD.org> Alexander Best escribi?: > any thoughts on these small changes to burncd? > > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > + int nogap = 0, speed = 0, test_write = 0, force = 0; > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > const char *dev; > > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > > + if ((speed = getenv("SPEED")) == NULL) > + speed = 4 * 177; > + It seems incorrect. The speed variable is of type int, while getenv returns char *. You should first assign getenv("SPEED") to a char * variable and if it isn't NULL then you should convert it to int or fall back to the default value otherwise. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From gabor at FreeBSD.org Mon Nov 9 01:02:43 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Mon Nov 9 01:02:49 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <4AF767FA.7040004@FreeBSD.org> References: <4AF767FA.7040004@FreeBSD.org> Message-ID: <4AF76A2C.400@FreeBSD.org> Gabor Kovesdan escribi?: > Alexander Best escribi?: >> any thoughts on these small changes to burncd? >> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; >> + int nogap = 0, speed = 0, test_write = 0, force = 0; >> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; >> const char *dev; >> >> if ((dev = getenv("CDROM")) == NULL) >> dev = "/dev/acd0"; >> >> + if ((speed = getenv("SPEED")) == NULL) >> + speed = 4 * 177; >> + > It seems incorrect. The speed variable is of type int, while getenv > returns char *. You should first assign getenv("SPEED") to a char * > variable and if it isn't NULL then you should convert it to int or > fall back to the default value otherwise. And one more thing. Personally, I think that a more specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED is just too general. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From alexbestms at math.uni-muenster.de Mon Nov 9 01:19:13 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 9 01:19:21 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <4AF76A2C.400@FreeBSD.org> Message-ID: Gabor Kovesdan schrieb am 2009-11-09: > Gabor Kovesdan escribi?: > >Alexander Best escribi?: > >>any thoughts on these small changes to burncd? > >> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > >>+ int nogap = 0, speed = 0, test_write = 0, force = 0; > >> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > >> const char *dev; > >> if ((dev = getenv("CDROM")) == NULL) > >> dev = "/dev/acd0"; > >>+ if ((speed = getenv("SPEED")) == NULL) > >>+ speed = 4 * 177; > >>+ > >It seems incorrect. The speed variable is of type int, while getenv > >returns char *. You should first assign getenv("SPEED") to a char * > >variable and if it isn't NULL then you should convert it to int or > >fall back to the default value otherwise. > And one more thing. Personally, I think that a more > specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED > is just too general. > -- > Gabor Kovesdan > FreeBSD Volunteer > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org thanks for the help. how about this revised patch? cheers. alex -------------- next part -------------- Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -164,6 +164,12 @@ .Fl f flag. .El +.Bl -tag -width ".Ev WRITE_SPEED" +.It Ev WRITE_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. +.El .Sh FILES .Bl -tag -width ".Pa /dev/acd0" .It Pa /dev/acd0 Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,20 @@ int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; - const char *dev; + const char *dev, *env_speed; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + if ((env_speed = getenv("WRITE_SPEED")) != NULL) + if (strcasecmp("max", getenv) == 0) + speed = CDR_MAX_SPEED; + else + speed = atoi(env_speed) * 177; + if (speed <= 0) + errx(EX_USAGE, "Invalid speed: %s", env_speed); + } + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': From alexbestms at math.uni-muenster.de Mon Nov 9 01:22:44 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 9 01:22:51 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <4AF76A2C.400@FreeBSD.org> Message-ID: Gabor Kovesdan schrieb am 2009-11-09: > Gabor Kovesdan escribi?: > >Alexander Best escribi?: > >>any thoughts on these small changes to burncd? > >> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > >>+ int nogap = 0, speed = 0, test_write = 0, force = 0; > >> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > >> const char *dev; > >> if ((dev = getenv("CDROM")) == NULL) > >> dev = "/dev/acd0"; > >>+ if ((speed = getenv("SPEED")) == NULL) > >>+ speed = 4 * 177; > >>+ > >It seems incorrect. The speed variable is of type int, while getenv > >returns char *. You should first assign getenv("SPEED") to a char * > >variable and if it isn't NULL then you should convert it to int or > >fall back to the default value otherwise. > And one more thing. Personally, I think that a more > specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED > is just too general. > -- > Gabor Kovesdan > FreeBSD Volunteer > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org ooops. this one fixes the typos. ;) alex -------------- next part -------------- --- burncd.c.typo 2009-11-09 02:19:47.000000000 +0100 +++ burncd.c 2009-11-09 02:20:27.000000000 +0100 @@ -85,8 +85,8 @@ if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; - if ((env_speed = getenv("WRITE_SPEED")) != NULL) - if (strcasecmp("max", getenv) == 0) + if ((env_speed = getenv("WRITE_SPEED")) != NULL) { + if (strcasecmp("max", env_speed) == 0) speed = CDR_MAX_SPEED; else speed = atoi(env_speed) * 177; From keramida at ceid.upatras.gr Mon Nov 9 07:10:09 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Nov 9 07:10:16 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 01:47:40 +0100 (CET)") References: Message-ID: <873a4o2my9.fsf@kobe.laptop> On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best wrote: > any thoughts on these small changes to burncd? > > Index: usr.sbin/burncd/burncd.c > =================================================================== > --- usr.sbin/burncd/burncd.c (revision 199064) > +++ usr.sbin/burncd/burncd.c (working copy) > @@ -78,13 +78,16 @@ > { > int arg, addr, ch, fd; > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > + int nogap = 0, speed = 0, test_write = 0, force = 0; > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > const char *dev; > > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > > + if ((speed = getenv("SPEED")) == NULL) > + speed = 4 * 177; > + > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > switch (ch) { > case 'd': Hi Alexander, The idea seems very good, but since the value of SPEED is user supplied data, I would rather see a bit of validation code after getenv(). With this version of the patch, burncd would happily accept and try to use values that are quite absurd, i.e.: env SPEED=12234567890 burncd ... It may also be sensible to do the translation from "human readable" speed values and the multiplication with 177 _after_ the value has been parsed from getenv(), so that e.g. one can write: env SPEED=4 burncd and get behavior similar to the current default. -------------- 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-hackers/attachments/20091109/603693d6/attachment.pgp From keramida at ceid.upatras.gr Mon Nov 9 07:19:37 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Nov 9 07:19:43 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 02:22:36 +0100 (CET)") References: Message-ID: <87y6mg17y2.fsf@kobe.laptop> On Mon, 09 Nov 2009 02:22:36 +0100 (CET), Alexander Best wrote: > --- burncd.c.typo 2009-11-09 02:19:47.000000000 +0100 > +++ burncd.c 2009-11-09 02:20:27.000000000 +0100 > @@ -85,8 +85,8 @@ > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > > - if ((env_speed = getenv("WRITE_SPEED")) != NULL) > - if (strcasecmp("max", getenv) == 0) > + if ((env_speed = getenv("WRITE_SPEED")) != NULL) { > + if (strcasecmp("max", env_speed) == 0) > speed = CDR_MAX_SPEED; > else > speed = atoi(env_speed) * 177; atoi() doesn't really have error checking and it does not necessarily affect `errno'. I'd probably prefer something that uses strtoul() and a few more value/range checks, i.e.: : #include : #include : : { : char *endp; : long xspeed; : : speed = 4 * 177; : if ((env_speed = getenv("SPEED")) != NULL) { : if (strcasecmp("max", env_speed) == 0) { : speed = CDR_MAX_SPEED; : } else { : end = NULL; : errno = 0; : xspeed = strtol(env_speed, &endp, 0); : if (errno != 0 || (endp != NULL && endp != str && : *endp != '\0' && (isdigit(*endp) != 0 || : isspace(*endp) == 0))) : err(1, "invalid write speed: %s", env_speed); : if (xspeed < 0 || xspeed > INT_MAX) : err(1, "write speed out of range: %ld", xspeed); : speed = (int)xspeed * 177; : } : } : } -------------- 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-hackers/attachments/20091109/d9868a32/attachment.pgp From des at des.no Mon Nov 9 10:00:45 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 9 10:00:58 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <87y6mg17y2.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 09 Nov 2009 09:19:33 +0200") References: <87y6mg17y2.fsf@kobe.laptop> Message-ID: <86hbt4j9v8.fsf@ds4.des.no> Giorgos Keramidas writes: > atoi() doesn't really have error checking and it does not necessarily > affect `errno'. man 3 expand_number And please don't call it SPEED or WRITE_SPEED or anything generic; call it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar used to specify the device is called CDROM, not DEVICE. DES -- Dag-Erling Sm?rgrav - des@des.no From keramida at freebsd.org Mon Nov 9 11:59:43 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Mon Nov 9 11:59:50 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <86hbt4j9v8.fsf@ds4.des.no> ("Dag-Erling =?iso-8859-1?Q?Sm=F8?= =?iso-8859-1?Q?rgrav=22's?= message of "Mon, 09 Nov 2009 11:00:43 +0100") References: <87y6mg17y2.fsf@kobe.laptop> <86hbt4j9v8.fsf@ds4.des.no> Message-ID: <87vdhkgc99.fsf@kobe.laptop> On Mon, 09 Nov 2009 11:00:43 +0100, Dag-Erling Sm?rgrav wrote: > Giorgos Keramidas writes: >> atoi() doesn't really have error checking and it does not necessarily >> affect `errno'. > > man 3 expand_number I know, but thanks. In this case, expand_number's logic for parsing possible SI suffixes is not useful and may be slightly confusing. I'm not sure what CDROM_SPEED='4m' would mean for burncd's -s option, for example. > And please don't call it SPEED or WRITE_SPEED or anything generic; call > it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar > used to specify the device is called CDROM, not DEVICE. Good point. -------------- 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-hackers/attachments/20091109/99ddd83a/attachment.pgp From des at des.no Mon Nov 9 12:32:23 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 9 12:32:30 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <87vdhkgc99.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 09 Nov 2009 13:37:22 +0200") References: <87y6mg17y2.fsf@kobe.laptop> <86hbt4j9v8.fsf@ds4.des.no> <87vdhkgc99.fsf@kobe.laptop> Message-ID: <86skcnj2ui.fsf@ds4.des.no> Giorgos Keramidas writes: > Dag-Erling Sm?rgrav wrote: > > man 3 expand_number > I know, but thanks. In this case, expand_number's logic for parsing > possible SI suffixes is not useful and may be slightly confusing. > > I'm not sure what CDROM_SPEED='4m' would mean for burncd's -s option, > for example. Hmm, I thought the speed was expressed in kBps or something... DES -- Dag-Erling Sm?rgrav - des@des.no From alexbestms at math.uni-muenster.de Mon Nov 9 14:39:17 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Nov 9 14:39:24 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <873a4o2my9.fsf@kobe.laptop> Message-ID: Giorgos Keramidas schrieb am 2009-11-09: > On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best > wrote: > > any thoughts on these small changes to burncd? > > Index: usr.sbin/burncd/burncd.c > > =================================================================== > > --- usr.sbin/burncd/burncd.c (revision 199064) > > +++ usr.sbin/burncd/burncd.c (working copy) > > @@ -78,13 +78,16 @@ > > { > > int arg, addr, ch, fd; > > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, > > preemp = 0; > > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > > + int nogap = 0, speed = 0, test_write = 0, force = 0; > > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > > const char *dev; > > if ((dev = getenv("CDROM")) == NULL) > > dev = "/dev/acd0"; > > + if ((speed = getenv("SPEED")) == NULL) > > + speed = 4 * 177; > > + > > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > > switch (ch) { > > case 'd': > Hi Alexander, > The idea seems very good, but since the value of SPEED is user > supplied > data, I would rather see a bit of validation code after getenv(). > With > this version of the patch, burncd would happily accept and try to use > values that are quite absurd, i.e.: > env SPEED=12234567890 burncd ... > It may also be sensible to do the translation from "human readable" > speed values and the multiplication with 177 _after_ the value has > been > parsed from getenv(), so that e.g. one can write: > env SPEED=4 burncd > and get behavior similar to the current default. i don't quite get why the value supplied with the envar has to be validated. if the user supplies a speed value using the -s switch no validation (except <= 0) is being performed either. also i think there's a speed check in the atapi code. if the speed requested is > the maximum driver speed it gets set to the maximum driver speed automatically. cheers. alex From keramida at freebsd.org Mon Nov 9 14:52:13 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Mon Nov 9 14:52:20 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 15:28:29 +0100 (CET)") References: Message-ID: <87hbt3hht2.fsf@kobe.laptop> On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best wrote: > Giorgos Keramidas schrieb am 2009-11-09: >> Hi Alexander, > >> The idea seems very good, but since the value of SPEED is user >> supplied data, I would rather see a bit of validation code after >> getenv(). With this version of the patch, burncd would happily >> accept and try to use values that are quite absurd, i.e.: > >> env SPEED=12234567890 burncd ... > >> It may also be sensible to do the translation from "human readable" >> speed values and the multiplication with 177 _after_ the value has >> been parsed from getenv(), so that e.g. one can write: > >> env SPEED=4 burncd > >> and get behavior similar to the current default. > > i don't quite get why the value supplied with the envar has to be > validated. if the user supplies a speed value using the -s switch no > validation (except <= 0) is being performed either. This is probably me being paranoid. I'd prefer *both* places to check the supplied value for invalid values, even if the check is something like "negative numbers are not ok". > also i think there's a speed check in the atapi code. if the speed > requested is > the maximum driver speed it gets set to the maximum > driver speed automatically. If the capping happens automatically we're fine. From a cursory look at the kernel sources this morning, I didn't manage to find a speed-range check in sys/dev/ata. The acd_set_speed() code is a small function: : static int : acd_set_speed(device_t dev, int rdspeed, int wrspeed) : { : int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed >> 8, rdspeed, : wrspeed >> 8, wrspeed, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; : int error; : : error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30); : if (!error) : acd_get_cap(dev); : return error; : } and that's all. It probably relies on the hardware to cap the speed, but I am not very familiar with the rest of the ATA code to be sure. Your patch is fine, but as a followup commit I'd probably like seeing atoi() go away. AFAICT, it currently allows invalid speed values, defaulting to speed=0 when a user types: burncd -s foobar [options ...] We can fix that later though :) From jhb at freebsd.org Mon Nov 9 15:50:20 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 9 15:50:39 2009 Subject: Why is default value of NKPT so small? mfsroot In-Reply-To: <761362.20406.qm@web113204.mail.gq1.yahoo.com> References: <761362.20406.qm@web113204.mail.gq1.yahoo.com> Message-ID: <200911090927.05010.jhb@freebsd.org> On Friday 06 November 2009 2:19:51 pm Trever wrote: > Does anyone know what the thinking is behind the default value of NKTP in /usr/src/sys/i386/include/pmap.h? > > It seems to me that it's too small, though I'm wondering if there are some considerations in changing it's value that I should know about. > > Too small because: making it a little more than twice as large (so you can get about a 300MB mfsroot to boot) means you can (by default) boot a standard FreeBSD system into memory, and I know I can't be the only one who would value that a great deal for many reasons. As it stands you have to ax things out (like depenguinator does, for example). Or you have to recompile the kernel. > > Does it have to be like this? > > Which leads me to two more questions: > - is it possible to change the NKTP value without recompiling the kernel? I think there isn't but I'll ask. > - is it possible to change the NKTP value without editing pmap.h (can I pass a variable into the kernel build process)? I keep meaning to make NKPT a kernel option for i386. Try this patch, it should let you add 'options NKPT=xxx' to your kernel config. Index: conf/options.i386 =================================================================== --- conf/options.i386 (revision 198997) +++ conf/options.i386 (working copy) @@ -12,6 +12,7 @@ MAXMEM MPTABLE_FORCE_HTT MP_WATCHDOG +NKPT opt_pmap.h PERFMON PMAP_SHPGPERPROC opt_pmap.h POWERFAIL_NMI opt_trap.h Index: i386/i386/mp_machdep.c =================================================================== --- i386/i386/mp_machdep.c (revision 198997) +++ i386/i386/mp_machdep.c (working copy) @@ -30,6 +30,7 @@ #include "opt_cpu.h" #include "opt_kstack_pages.h" #include "opt_mp_watchdog.h" +#include "opt_pmap.h" #include "opt_sched.h" #include "opt_smp.h" Index: i386/xen/mp_machdep.c =================================================================== --- i386/xen/mp_machdep.c (revision 198997) +++ i386/xen/mp_machdep.c (working copy) @@ -31,6 +31,7 @@ #include "opt_cpu.h" #include "opt_kstack_pages.h" #include "opt_mp_watchdog.h" +#include "opt_pmap.h" #include "opt_sched.h" #include "opt_smp.h" -- John Baldwin From jhb at freebsd.org Mon Nov 9 15:50:21 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 9 15:50:39 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: References: Message-ID: <200911090931.12494.jhb@freebsd.org> On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote: > no problem. i've sent the final patch as followup to kern/71258 and also > attached it to this message. to make it short. what's being changed by the > patch: > > 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL > 2) if MAP_STACK is defined and offset !=0 ====> offset = 0 > > would be great if you could have a look at the patch if you've got a spare > minute. I didn't think 2) changed? I.e. both the old and new code do this, so only 1) is changing? -- John Baldwin From alexbestms at wwu.de Mon Nov 9 15:57:54 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 15:58:04 2009 Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't In-Reply-To: <200911090931.12494.jhb@freebsd.org> Message-ID: John Baldwin schrieb am 2009-11-09: > On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote: > > no problem. i've sent the final patch as followup to kern/71258 and > > also > > attached it to this message. to make it short. what's being changed > > by the > > patch: > > 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL > > 2) if MAP_STACK is defined and offset !=0 ====> offset = 0 > > would be great if you could have a look at the patch if you've got > > a spare > > minute. > I didn't think 2) changed? I.e. both the old and new code do this, > so only 1) > is changing? you're right sorry about that mistake. so the only aspect of mmap() the patch changes is: if MAP_ANON is defined and offset !=0 ====> return EINVAL cheers. alex From alexbestms at wwu.de Mon Nov 9 18:01:52 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 18:01:59 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <87hbt3hht2.fsf@kobe.laptop> Message-ID: Giorgos Keramidas schrieb am 2009-11-09: > On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best > wrote: > > Giorgos Keramidas schrieb am 2009-11-09: > >> Hi Alexander, > >> The idea seems very good, but since the value of SPEED is user > >> supplied data, I would rather see a bit of validation code after > >> getenv(). With this version of the patch, burncd would happily > >> accept and try to use values that are quite absurd, i.e.: > >> env SPEED=12234567890 burncd ... > >> It may also be sensible to do the translation from "human > >> readable" > >> speed values and the multiplication with 177 _after_ the value has > >> been parsed from getenv(), so that e.g. one can write: > >> env SPEED=4 burncd > >> and get behavior similar to the current default. > > i don't quite get why the value supplied with the envar has to be > > validated. if the user supplies a speed value using the -s switch > > no > > validation (except <= 0) is being performed either. > This is probably me being paranoid. I'd prefer *both* places to > check > the supplied value for invalid values, even if the check is something > like "negative numbers are not ok". > > also i think there's a speed check in the atapi code. if the speed > > requested is > the maximum driver speed it gets set to the maximum > > driver speed automatically. > If the capping happens automatically we're fine. From a cursory look > at > the kernel sources this morning, I didn't manage to find a > speed-range > check in sys/dev/ata. The acd_set_speed() code is a small function: > : static int > : acd_set_speed(device_t dev, int rdspeed, int wrspeed) > : { > : int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed >> 8, rdspeed, > : wrspeed >> 8, wrspeed, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0 }; > : int error; > : > : error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30); > : if (!error) > : acd_get_cap(dev); > : return error; > : } > and that's all. It probably relies on the hardware to cap the speed, > but I am not very familiar with the rest of the ATA code to be sure. > Your patch is fine, but as a followup commit I'd probably like seeing > atoi() go away. AFAICT, it currently allows invalid speed values, > defaulting to speed=0 when a user types: > burncd -s foobar [options ...] > We can fix that later though :) ok. so do you think this patch is sufficient then? once committed i'll see if i can add some extra validation to the envar as well as the -s switch and will also have a look at the validation the ATA code is doing atm. alex -------------- next part -------------- Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -164,6 +164,12 @@ .Fl f flag. .El +.Bl -tag -width ".Ev BURNCD_SPEED" +.It Ev BURNCD_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. +.El .Sh FILES .Bl -tag -width ".Pa /dev/acd0" .It Pa /dev/acd0 Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,20 @@ int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; - const char *dev; + const char *dev, *env_speed; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { + if (strcasecmp("max", env_speed) == 0) + speed = CDR_MAX_SPEED; + else + speed = atoi(env_speed) * 177; + if (speed <= 0) + errx(EX_USAGE, "Invalid speed: %s", env_speed); + } + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': From keramida at freebsd.org Mon Nov 9 18:07:38 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Mon Nov 9 18:07:56 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 19:01:43 +0100 (CET)") References: Message-ID: <87k4xzbmhq.fsf@kobe.laptop> On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best wrote: >Giorgos Keramidas schrieb am 2009-11-09: >> > i don't quite get why the value supplied with the envar has to be >> > validated. if the user supplies a speed value using the -s switch >> > no validation (except <= 0) is being performed either. > >> This is probably me being paranoid. I'd prefer *both* places to >> check the supplied value for invalid values, even if the check is >> something like "negative numbers are not ok". > >> > also i think there's a speed check in the atapi code. if the speed >> > requested is > the maximum driver speed it gets set to the maximum >> > driver speed automatically. > >> Your patch is fine, but as a followup commit I'd probably like seeing >> atoi() go away. AFAICT, it currently allows invalid speed values, >> defaulting to speed=0 when a user types: > >> burncd -s foobar [options ...] > >> We can fix that later though :) > > ok. so do you think this patch is sufficient then? once committed i'll > see if i can add some extra validation to the envar as well as the -s > switch and will also have a look at the validation the ATA code is > doing atm. Yes, the patch attached below is fine, and IMO it would be ok to commit it, minus a couple of tiny details: sorting the BURNCD_SPEED environment variable before the current CDROM item in the manpage, and bumping the manpage modification date near .Dd to today. %%% Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -164,6 +164,12 @@ .Fl f flag. .El +.Bl -tag -width ".Ev BURNCD_SPEED" +.It Ev BURNCD_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. +.El .Sh FILES .Bl -tag -width ".Pa /dev/acd0" .It Pa /dev/acd0 Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,20 @@ int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; - const char *dev; + const char *dev, *env_speed; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { + if (strcasecmp("max", env_speed) == 0) + speed = CDR_MAX_SPEED; + else + speed = atoi(env_speed) * 177; + if (speed <= 0) + errx(EX_USAGE, "Invalid speed: %s", env_speed); + } + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': %%% -------------- 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-hackers/attachments/20091109/3531896a/attachment.pgp From alexbestms at wwu.de Mon Nov 9 19:03:16 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 19:03:23 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <87k4xzbmhq.fsf@kobe.laptop> Message-ID: Giorgos Keramidas schrieb am 2009-11-09: > On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best > wrote: > >Giorgos Keramidas schrieb am 2009-11-09: > >> > i don't quite get why the value supplied with the envar has to > >> > be > >> > validated. if the user supplies a speed value using the -s > >> > switch > >> > no validation (except <= 0) is being performed either. > >> This is probably me being paranoid. I'd prefer *both* places to > >> check the supplied value for invalid values, even if the check is > >> something like "negative numbers are not ok". > >> > also i think there's a speed check in the atapi code. if the > >> > speed > >> > requested is > the maximum driver speed it gets set to the > >> > maximum > >> > driver speed automatically. > >> Your patch is fine, but as a followup commit I'd probably like > >> seeing > >> atoi() go away. AFAICT, it currently allows invalid speed values, > >> defaulting to speed=0 when a user types: > >> burncd -s foobar [options ...] > >> We can fix that later though :) > > ok. so do you think this patch is sufficient then? once committed > > i'll > > see if i can add some extra validation to the envar as well as the > > -s > > switch and will also have a look at the validation the ATA code is > > doing atm. > Yes, the patch attached below is fine, and IMO it would be ok to > commit > it, minus a couple of tiny details: sorting the BURNCD_SPEED > environment > variable before the current CDROM item in the manpage, and bumping > the > manpage modification date near .Dd to today. > %%% > Index: usr.sbin/burncd/burncd.8 > =================================================================== > --- usr.sbin/burncd/burncd.8 (revision 199064) > +++ usr.sbin/burncd/burncd.8 (working copy) > @@ -164,6 +164,12 @@ > .Fl f > flag. > .El > +.Bl -tag -width ".Ev BURNCD_SPEED" > +.It Ev BURNCD_SPEED > +The write speed to use if one is not specified with the > +.Fl s > +flag. > +.El > .Sh FILES > .Bl -tag -width ".Pa /dev/acd0" > .It Pa /dev/acd0 > Index: usr.sbin/burncd/burncd.c > =================================================================== > --- usr.sbin/burncd/burncd.c (revision 199064) > +++ usr.sbin/burncd/burncd.c (working copy) > @@ -80,11 +80,20 @@ > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, > preemp = 0; > int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > - const char *dev; > + const char *dev, *env_speed; > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { > + if (strcasecmp("max", env_speed) == 0) > + speed = CDR_MAX_SPEED; > + else > + speed = atoi(env_speed) * 177; > + if (speed <= 0) > + errx(EX_USAGE, "Invalid speed: %s", > env_speed); > + } > + > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > switch (ch) { > case 'd': > %%% ok. thanks a lot. maybe somebody will step up and commit this. i'm not familiar with the man() syntax so i might need some time to add the changes you recommended. also it seems the ENVIREMENT section needs to be aligned differently now that it has more than > 1 entry. cheers. alex From alexbestms at wwu.de Mon Nov 9 19:25:05 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 19:25:12 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <87k4xzbmhq.fsf@kobe.laptop> Message-ID: here's the final patch. would be great if somebody could commit this one. the only thing i'm not 100% sure about are the burncd(8) changes. i'm not that familiar with the man syntax. thanks go out to keramida@ and des@ for their help. alex ...just realised the topic makes no sense. ;) what i meant to write was probably "[patch] burncd: honour envar SPEED". ;) -------------- next part -------------- Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 2, 2005 +.Dd Nov 9, 2009 .Os .Dt BURNCD 8 .Sh NAME @@ -158,7 +158,11 @@ .Sh ENVIRONMENT The following environment variables affect the execution of .Nm : -.Bl -tag -width ".Ev CDROM" +.Bl -tag -width ".Ev BURNCD_SPEED" +.It Ev BURNCD_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. .It Ev CDROM The CD device to use if one is not specified with the .Fl f Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,20 @@ int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; - const char *dev; + const char *dev, *env_speed; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { + if (strcasecmp("max", env_speed) == 0) + speed = CDR_MAX_SPEED; + else + speed = atoi(env_speed) * 177; + if (speed <= 0) + errx(EX_USAGE, "Invalid speed: %s", env_speed); + } + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': From alexbestms at wwu.de Mon Nov 9 20:24:49 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 20:24:56 2009 Subject: help needed to fix contrib/ee crash/exit when receiving SIGWINCH Message-ID: since you've tested the patch on 7-stable do think it's mature enough to be committed to that branch? alex From des at des.no Mon Nov 9 20:58:23 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 9 20:58:29 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 20:24:56 +0100 (CET)") References: Message-ID: <86aayvfmaa.fsf@ds4.des.no> Alexander Best writes: > > + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { > + if (strcasecmp("max", env_speed) == 0) > + speed = CDR_MAX_SPEED; > + else > + speed = atoi(env_speed) * 177; > + if (speed <= 0) > + errx(EX_USAGE, "Invalid speed: %s", env_speed); > + } > + > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > switch (ch) { > case 'd': You realize you're duplicating 6 lines of non-trivial code for no good reason? env_speed = getenv("BURNCD_SPEED"); while ((ch = getopt(...)) != -1) { switch (ch) { case 's': env_speed = optarg; break; ... } } if (env_speed != NULL) { if (strcasecmp...) { ... } } DES -- Dag-Erling Sm?rgrav - des@des.no From gavin at FreeBSD.org Mon Nov 9 21:05:19 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Nov 9 21:05:27 2009 Subject: heci: a new driver for review and testing In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> Message-ID: <20091109195045.Q13027@ury.york.ac.uk> On Wed, 14 Oct 2009, Andriy Gapon wrote: > Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > > I actually got around to implementing it (in initial/basic form): > http://people.freebsd.org/~avg/heci.tgz Nice! I've got the following device in my laptop: heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Management Engine Interface (Mobile 4 Series Chipset)' class = simple comms I've added this device to the code, and loaded it: heci0: mem 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x02: heci0: status = 0x00 heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 heci0: found ME client at address 0x06: heci0: status = 0x00 heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 heci0: found ME client at address 0x22: heci0: status = 0x00 heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 heci0: found ME client at address 0x23: heci0: status = 0x00 heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C heci0: found ME client at address 0x24: heci0: status = 0x00 heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB However, running the heci-qst.c program you supplied: psi# ./heci-qst ioctl HECI_CONNECT: No such file or directory And output to the console: heci0: could not find ME client with given guid: 6B5205B9-8185-4519-B889-D98724B58607 Other than seeing that it doesn't appear in the list above, I don't know if this is expected or not... Secondly, I get a panic on module unlaod. I haven't spent any time looking at this, if you haven't fixed it yet let me know and I'll look into it further. I'm not even sure how it's getting that far into the detach routine before panicing, if dev really does = 0xdeadc0dedeadc0de #8 0xffffffff808580d3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) at /usr/src/sys/kern/kern_mutex.c:827 #10 0xffffffff812221c6 in heci_detach () from /usr/src/sys/modules/heci/heci.ko #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) at device_if.h:212 #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, what=Variable "what" is not available. ) at /usr/src/sys/kern/subr_bus.c:1156 #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) at /usr/src/sys/kern/kern_module.c:266 #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, flags=0) at /usr/src/sys/kern/kern_linker.c:633 #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, fileid=Variable "fileid" is not available. ) at /usr/src/sys/kern/kern_linker.c:1092 Let me know if there's anything else I can test. Thanks, Gavin From alexbestms at wwu.de Mon Nov 9 21:11:35 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 21:11:46 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <86aayvfmaa.fsf@ds4.des.no> Message-ID: Dag-Erling Sm?rgrav schrieb am 2009-11-09: > Alexander Best writes: > > + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { > > + if (strcasecmp("max", env_speed) == 0) > > + speed = CDR_MAX_SPEED; > > + else > > + speed = atoi(env_speed) * 177; > > + if (speed <= 0) > > + errx(EX_USAGE, "Invalid speed: %s", > > env_speed); > > + } > > + > > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > > switch (ch) { > > case 'd': > You realize you're duplicating 6 lines of non-trivial code for no > good > reason? > env_speed = getenv("BURNCD_SPEED"); > while ((ch = getopt(...)) != -1) { > switch (ch) { > case 's': > env_speed = optarg; > break; > ... > } > } > if (env_speed != NULL) { > if (strcasecmp...) { > ... > } > } > DES good point. is this one better? alex -------------- next part -------------- Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 2, 2005 +.Dd Nov 9, 2009 .Os .Dt BURNCD 8 .Sh NAME @@ -158,7 +158,11 @@ .Sh ENVIRONMENT The following environment variables affect the execution of .Nm : -.Bl -tag -width ".Ev CDROM" +.Bl -tag -width ".Ev BURNCD_SPEED" +.It Ev BURNCD_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. .It Ev CDROM The CD device to use if one is not specified with the .Fl f Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,13 @@ int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; - const char *dev; + const char *dev, *env_speed; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + env_speed = getenv("BURNCD_SPEED"); + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': @@ -124,12 +126,7 @@ break; case 's': - if (strcasecmp("max", optarg) == 0) - speed = CDR_MAX_SPEED; - else - speed = atoi(optarg) * 177; - if (speed <= 0) - errx(EX_USAGE, "Invalid speed: %s", optarg); + env_speed = optarg; break; case 't': @@ -147,6 +144,13 @@ argc -= optind; argv += optind; + if (strcasecmp("max", env_speed) == 0) + speed = CDR_MAX_SPEED; + else + speed = atoi(env_speed) * 177; + if (speed <= 0) + errx(EX_USAGE, "Invalid speed: %s", optarg); + if (argc == 0) usage(); From des at des.no Tue Nov 10 08:00:31 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Nov 10 08:01:08 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 22:11:25 +0100 (CET)") References: Message-ID: <863a4mg676.fsf@ds4.des.no> Alexander Best writes: > good point. is this one better? Yes (modulo indentation - run your code through tabify) DES -- Dag-Erling Sm?rgrav - des@des.no From avg at icyb.net.ua Tue Nov 10 11:54:13 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 10 11:54:20 2009 Subject: heci: a new driver for review and testing In-Reply-To: <20091109195045.Q13027@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> Message-ID: <4AF95461.2030700@icyb.net.ua> on 09/11/2009 22:34 Gavin Atkinson said the following: > On Wed, 14 Oct 2009, Andriy Gapon wrote: >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 >> >> I actually got around to implementing it (in initial/basic form): >> http://people.freebsd.org/~avg/heci.tgz > > Nice! > > I've got the following device in my laptop: > > heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Management Engine Interface (Mobile 4 Series > Chipset)' > class = simple comms > > I've added this device to the code, and loaded it: > > heci0: mem > 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0 I will add this ID and name to the driver. > heci0: using MSI > heci0: [ITHREAD] > heci0: found ME client at address 0x02: > heci0: status = 0x00 > heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 > heci0: found ME client at address 0x06: > heci0: status = 0x00 > heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 > heci0: found ME client at address 0x07: > heci0: status = 0x00 > heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB > heci0: found ME client at address 0x20: > heci0: status = 0x00 > heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 > heci0: found ME client at address 0x21: > heci0: status = 0x00 > heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 > heci0: found ME client at address 0x22: > heci0: status = 0x00 > heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 > heci0: found ME client at address 0x23: > heci0: status = 0x00 > heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C > heci0: found ME client at address 0x24: > heci0: status = 0x00 > heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB Thanks a lot for testing! > However, running the heci-qst.c program you supplied: > > psi# ./heci-qst > ioctl HECI_CONNECT: No such file or directory > > And output to the console: > > heci0: could not find ME client with given guid: > 6B5205B9-8185-4519-B889-D98724B58607 > > Other than seeing that it doesn't appear in the list above, I don't know > if this is expected or not... Yes, this is expected if you don't have ME client with this GUID. Perhaps, there is no QST firmware in the ME or it is disabled. Also, I am not sure but I think that it could be possible that you have a newer version of QST and its GUID is different. If you feel adventurous, you could try substituting GUID value in heci-qst.c with values reported by the driver. Perhaps it would work, perhaps you'd get a crash or hang or just an ioctl error. > Secondly, I get a panic on module unlaod. I haven't spent any time > looking at this, if you haven't fixed it yet let me know and I'll look > into it further. To my shame I still haven't got around to testing the driver with head tree and diagnostics enabled. I do not see any problems on stable/7 without diagnostics. Robert Noland has reported that he had a lockup on module unload with head sources. I will investigate this. BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if debugger reports it correctly). This looks like the memory was already freed. > I'm not even sure how it's getting that far into the detach routine > before panicing, if dev really does = 0xdeadc0dedeadc0de > > #8 0xffffffff808580d3 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) > at /usr/src/sys/kern/kern_mutex.c:827 > #10 0xffffffff812221c6 in heci_detach () > from /usr/src/sys/modules/heci/heci.ko > #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) > at device_if.h:212 > #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, > what=Variable "what" is not available. > ) at /usr/src/sys/kern/subr_bus.c:1156 > #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) > at /usr/src/sys/kern/kern_module.c:266 > #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, > flags=0) at /usr/src/sys/kern/kern_linker.c:633 > #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, > fileid=Variable "fileid" is not available. > ) at /usr/src/sys/kern/kern_linker.c:1092 > > Let me know if there's anything else I can test. > > Thanks, Nothing else I can think of right now. Thanks again! -- Andriy Gapon From alexbestms at wwu.de Tue Nov 10 15:50:17 2009 From: alexbestms at wwu.de (Alexander Best) Date: Tue Nov 10 15:50:23 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <863a4mg676.fsf@ds4.des.no> Message-ID: Dag-Erling Sm?rgrav schrieb am 2009-11-10: > Alexander Best writes: > > good point. is this one better? > Yes (modulo indentation - run your code through tabify) > DES oops. found another problem. if BURNCD_SPEED and -s aren't defined strcasecmp segfaults because env_speed is NULL. does this patch take care of the problem? alex ps: would be nice if strcasecmp could protect itself from segfault with one or both of the args being NULL. -------------- next part -------------- Index: usr.sbin/burncd/burncd.8 =================================================================== --- usr.sbin/burncd/burncd.8 (revision 199125) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 2, 2005 +.Dd Nov 9, 2009 .Os .Dt BURNCD 8 .Sh NAME @@ -158,7 +158,11 @@ .Sh ENVIRONMENT The following environment variables affect the execution of .Nm : -.Bl -tag -width ".Ev CDROM" +.Bl -tag -width ".Ev BURNCD_SPEED" +.It Ev BURNCD_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. .It Ev CDROM The CD device to use if one is not specified with the .Fl f Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199125) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,13 @@ int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; - const char *dev; + const char *dev, *env_speed; if ((dev = getenv("CDROM")) == NULL) dev = "/dev/acd0"; + env_speed = getenv("BURNCD_SPEED"); + while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { switch (ch) { case 'd': @@ -124,12 +126,7 @@ break; case 's': - if (strcasecmp("max", optarg) == 0) - speed = CDR_MAX_SPEED; - else - speed = atoi(optarg) * 177; - if (speed <= 0) - errx(EX_USAGE, "Invalid speed: %s", optarg); + env_speed = optarg; break; case 't': @@ -147,6 +144,15 @@ argc -= optind; argv += optind; + if (env_speed == NULL) + ; + else if (strcasecmp("max", env_speed) == 0) + speed = CDR_MAX_SPEED; + else + speed = atoi(env_speed) * 177; + if (speed <= 0) + errx(EX_USAGE, "Invalid speed: %s", optarg); + if (argc == 0) usage(); From nate at thatsmathematics.com Tue Nov 10 16:03:28 2009 From: nate at thatsmathematics.com (Nate Eldredge) Date: Tue Nov 10 16:03:34 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: References: Message-ID: On Tue, 10 Nov 2009, Alexander Best wrote: > ps: would be nice if strcasecmp could protect itself from segfault with one or > both of the args being NULL. I disagree. What do you think it should do instead? Return 0? If it did, would you have found your bug? The same argument could be made for any of the string.h functions, but I don't think it actually holds water. Such checks add overhead, and only provide an illusion of safety. Sure, strcasecmp could avoid causing the segfault itself, but at the cost of letting a broken program continue and possibly cause more damage. It could call abort(), but then you'd just have the same result (program terminates) with a different signal, and doing your check in software rather than letting the MMU hardware do it. It could print a message, but that pollutes the program's output, and 15 seconds debugging the core dump will reveal the problem anyway. Having a library function "protect itself" in this manner is not actually helpful, IMHO. -- Nate Eldredge nate@thatsmathematics.com From alexbestms at wwu.de Tue Nov 10 16:17:41 2009 From: alexbestms at wwu.de (Alexander Best) Date: Tue Nov 10 16:17:48 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: Message-ID: Nate Eldredge schrieb am 2009-11-10: > On Tue, 10 Nov 2009, Alexander Best wrote: > >ps: would be nice if strcasecmp could protect itself from segfault > >with one or > >both of the args being NULL. > I disagree. What do you think it should do instead? Return 0? If > it did, would you have found your bug? > The same argument could be made for any of the string.h functions, > but I don't think it actually holds water. Such checks add > overhead, and only provide an illusion of safety. Sure, strcasecmp > could avoid causing the segfault itself, but at the cost of letting > a broken program continue and possibly cause more damage. It could > call abort(), but then you'd just have the same result (program > terminates) with a different signal, and doing your check in > software rather than letting the MMU hardware do it. It could print > a message, but that pollutes the program's output, and 15 seconds > debugging the core dump will reveal the problem anyway. > Having a library function "protect itself" in this manner is not > actually helpful, IMHO. > -- > Nate Eldredge > nate@thatsmathematics.com you're right. hundreds of functions cause segfaults when arg or args are NULL. either we add safety checks for all of them (massive overhead) or just leave them the way they are. also: these functions aren't being used by regular users, but developers and it's hard finding a developer who isn't experienced with dealing with NULL pointers. ;) so problems with NULL pointers are usually fixed very quickly. alex From kostikbel at gmail.com Tue Nov 10 16:59:43 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Nov 10 16:59:49 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: References: Message-ID: <20091110165936.GC2331@deviant.kiev.zoral.com.ua> On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote: > On Tue, 10 Nov 2009, Alexander Best wrote: > > >ps: would be nice if strcasecmp could protect itself from segfault with > >one or > >both of the args being NULL. > > I disagree. What do you think it should do instead? Return 0? If it > did, would you have found your bug? > > The same argument could be made for any of the string.h functions, but I > don't think it actually holds water. Such checks add overhead, and only > provide an illusion of safety. Sure, strcasecmp could avoid causing the > segfault itself, but at the cost of letting a broken program continue and > possibly cause more damage. It could call abort(), but then you'd just > have the same result (program terminates) with a different signal, and > doing your check in software rather than letting the MMU hardware do it. > It could print a message, but that pollutes the program's output, and 15 > seconds debugging the core dump will reveal the problem anyway. > > Having a library function "protect itself" in this manner is not actually > helpful, IMHO. I remember System V to actually map zero page at 0, thus causing all string functions to behave like it was supplied empty string when argument is NULL. I believe Solaris still provides the library that could be LD_PRELOADed for the same effect. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091110/d3aedcdb/attachment.pgp From avg at icyb.net.ua Tue Nov 10 17:12:51 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 10 17:13:06 2009 Subject: heci: a new driver for review and testing In-Reply-To: <4AF95461.2030700@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> Message-ID: <4AF99F10.8020703@icyb.net.ua> on 10/11/2009 13:54 Andriy Gapon said the following: > on 09/11/2009 22:34 Gavin Atkinson said the following: >> Secondly, I get a panic on module unlaod. I haven't spent any time >> looking at this, if you haven't fixed it yet let me know and I'll look >> into it further. > > To my shame I still haven't got around to testing the driver with head tree and > diagnostics enabled. I do not see any problems on stable/7 without diagnostics. > Robert Noland has reported that he had a lockup on module unload with head > sources. I will investigate this. > BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if > debugger reports it correctly). This looks like the memory was already freed. I think I've found one bug in the heci code that could cause this - SLIST element was first freed and then removed from the list. I've uploaded updated sources (that should include your PCI ID too), could you please re-test? >> I'm not even sure how it's getting that far into the detach routine >> before panicing, if dev really does = 0xdeadc0dedeadc0de >> >> #8 0xffffffff808580d3 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:224 >> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) >> at /usr/src/sys/kern/kern_mutex.c:827 >> #10 0xffffffff812221c6 in heci_detach () >> from /usr/src/sys/modules/heci/heci.ko >> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) >> at device_if.h:212 >> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, >> what=Variable "what" is not available. >> ) at /usr/src/sys/kern/subr_bus.c:1156 >> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) >> at /usr/src/sys/kern/kern_module.c:266 >> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, >> flags=0) at /usr/src/sys/kern/kern_linker.c:633 >> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, >> fileid=Variable "fileid" is not available. >> ) at /usr/src/sys/kern/kern_linker.c:1092 >> >> Let me know if there's anything else I can test. >> >> Thanks, > > Nothing else I can think of right now. OK, I came up with something :) Could you please send me verbose version of driver attachment messages (debug.bootverbose=1)? Thank you! BTW, Robert, you also promised me those :) -- Andriy Gapon From matthew.fleming at isilon.com Tue Nov 10 17:24:34 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Tue Nov 10 17:24:41 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <20091110165936.GC2331@deviant.kiev.zoral.com.ua> References: <20091110165936.GC2331@deviant.kiev.zoral.com.ua> Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E0338FCC2@seaxch09.desktop.isilon.com> > On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote: > > On Tue, 10 Nov 2009, Alexander Best wrote: > > > > >ps: would be nice if strcasecmp could protect itself from segfault > > >with one or both of the args being NULL. > > > > I disagree. What do you think it should do instead? Return 0? If it > > did, would you have found your bug? > > > > [snip] > > I remember System V to actually map zero page at 0, thus causing all > string functions to behave like it was supplied empty string when argument > is NULL. I believe Solaris still provides the library that could be > LD_PRELOADed for the same effect. Just an anecdote: My sophomore year of undergrad (1994), I was learning C for the first time. We had to write some little thing, and on the machines in the lab my C program ran great; I had debugged it (I thought) and turned it in. The instructor took my source, compiled it on Linux, and it segfaulted when run (I think trying to print a NULL string). If HP-UX hadn't been trying to be "friendly" I would have been able to fully debug my code. I am sure that if I'd known then what I know now I could have made it bug free. But my experience is that a lot of code is, by necessity, written by people who aren't experts in everything they're doing. So an early segfault would have helped me in that C programming class. OTOH, if instead it had been an application someone paid money for, and it segfaulted in an untested error case instead of being graceful, I'd be mad too. Probably at the app writer, but still... Cheers, matthew From gavin at FreeBSD.org Tue Nov 10 18:42:34 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 10 18:42:55 2009 Subject: heci: a new driver for review and testing In-Reply-To: <4AF99F10.8020703@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> Message-ID: <20091110184016.S61601@ury.york.ac.uk> On Tue, 10 Nov 2009, Andriy Gapon wrote: > on 10/11/2009 13:54 Andriy Gapon said the following: >> on 09/11/2009 22:34 Gavin Atkinson said the following: >>> Secondly, I get a panic on module unlaod. I haven't spent any time >>> looking at this, if you haven't fixed it yet let me know and I'll look >>> into it further. >> >> To my shame I still haven't got around to testing the driver with head tree and >> diagnostics enabled. I do not see any problems on stable/7 without diagnostics. >> Robert Noland has reported that he had a lockup on module unload with head >> sources. I will investigate this. >> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if >> debugger reports it correctly). This looks like the memory was already freed. > > I think I've found one bug in the heci code that could cause this - SLIST element > was first freed and then removed from the list. > I've uploaded updated sources (that should include your PCI ID too), could you > please re-test? That seems to have fixed it, thanks! It also fixes the malloc() calls with locks held. > Could you please send me verbose version of driver attachment messages > (debug.bootverbose=1)? > Thank you! Sure! http://people.freebsd.org/~gavin/heci-verbose.txt Gavin From des at des.no Tue Nov 10 20:13:45 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Nov 10 20:13:52 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: (Alexander Best's message of "Tue, 10 Nov 2009 17:17:38 +0100 (CET)") References: Message-ID: <86y6me2l54.fsf@ds4.des.no> Alexander Best writes: > you're right. hundreds of functions cause segfaults when arg or args > are NULL. either we add safety checks for all of them (massive > overhead) or just leave them the way they are. The consensus in the C community is that adding such checks does more harm than good, because a NULL pointer is usually a symptom of a bug somewhere else in the application, and checking for a NULL pointer will either hide that bug or trigger another error somewhere down the line, possibly making the real bug harder to find, rather than easier. (next week's topic: the return value of malloc(0)...) DES -- Dag-Erling Sm?rgrav - des@des.no From pluknet at gmail.com Tue Nov 10 20:24:30 2009 From: pluknet at gmail.com (pluknet) Date: Tue Nov 10 20:24:36 2009 Subject: [patch] burncd: honour for envar SPEED In-Reply-To: <86y6me2l54.fsf@ds4.des.no> References: <86y6me2l54.fsf@ds4.des.no> Message-ID: 2009/11/10 Dag-Erling Sm?rgrav : > Alexander Best writes: >> you're right. hundreds of functions cause segfaults when arg or args >> are NULL. ?either we add safety checks for all of them (massive >> overhead) or just leave them the way they are. > > The consensus in the C community is that adding such checks does more > harm than good, because a NULL pointer is usually a symptom of a bug > somewhere else in the application, and checking for a NULL pointer will > either hide that bug or trigger another error somewhere down the line, > possibly making the real bug harder to find, rather than easier. > And which is a way some well known OS' developers like to choose to fix sec.holes. No cookie. P.S. I apologize for flaming on this. > (next week's topic: the return value of malloc(0)...) > > DES > -- > Dag-Erling Sm?rgrav - des@des.no -- wbr, pluknet From demelier.david at gmail.com Tue Nov 10 21:10:57 2009 From: demelier.david at gmail.com (David DEMELIER) Date: Tue Nov 10 21:59:36 2009 Subject: Alps GlidePoint driver for synaptics. Message-ID: Hello there, I noticed that for the moment there is no support for alps based touchpads, is there anyone working on a driver for -CURRENT ? This is my touchpad : I: Bus=0011 Vendor=0002 Product=0008 Version=7321 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio4/input0 S: Sysfs=/devices/platform/i8042/serio4/input/input6 U: Uniq= H: Handlers=mouse2 event6 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003 Cheers, David. From psteele at maxiscale.com Wed Nov 11 00:14:07 2009 From: psteele at maxiscale.com (Peter Steele) Date: Wed Nov 11 00:14:13 2009 Subject: Converting a bootable USB stick in to bootable CD-ROM Message-ID: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394F75B@MBX03.exg5.exghost.com> I posted this on the -questions list but didn't get any replies. I have a FreeBSD image that I install on USB sticks to build new systems. When the stick boots it automatically clones itself on the system's hard drive, creating partitions and other configuration parameters that are programmed into the stick's cloning logic. I want to create a similar mechanism using a bootable CD-ROM. The biggest difference in the process of course is that the CD-ROM itself is read-only so clearly there needs to be an mfsroot involved in the process. I looked at how the FreeBSD Live CD is setup and the loader.conf file has these lines: mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" along with the file /boot/mfsroot.gz and no /etc/fstab. The fstab on my USB stick version has root mounted as /etc/da0s1a and clearly that isn't going to work. I changed my core BSD image accordingly, duplicating the mfsroot settings in my loader.conf. I used the command below to create the iso file from the BSD image I prepared. mkisofs -R -no-emul-boot -o /tmp/bsd.iso -b boot/cdboot /bsd When this iso is copied to a CD, it does boot. However, it doesn't seem to be picking up the mfsroot config and complains that the system is running from on a read-only file system, which of course is what I'm trying to avoid. I assume I simply have the boot config setup wrong. I essentially want the same kind of thing that's done for BSD Live. Can anyone point me to the right info for setting up this kind of bootable BSD CD? From avg at icyb.net.ua Wed Nov 11 13:17:39 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Nov 11 13:17:45 2009 Subject: heci: a new driver for review and testing In-Reply-To: <20091110184016.S61601@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> <20091110184016.S61601@ury.york.ac.uk> Message-ID: <4AFAB970.6060603@icyb.net.ua> on 10/11/2009 20:42 Gavin Atkinson said the following: > On Tue, 10 Nov 2009, Andriy Gapon wrote: >> on 10/11/2009 13:54 Andriy Gapon said the following: >>> on 09/11/2009 22:34 Gavin Atkinson said the following: >> I think I've found one bug in the heci code that could cause this - >> SLIST element >> was first freed and then removed from the list. >> I've uploaded updated sources (that should include your PCI ID too), >> could you >> please re-test? > > That seems to have fixed it, thanks! It also fixes the malloc() calls > with locks held. > >> Could you please send me verbose version of driver attachment messages >> (debug.bootverbose=1)? >> Thank you! > > Sure! > > http://people.freebsd.org/~gavin/heci-verbose.txt Thank you for the testing and data! -- Andriy Gapon From alexbestms at wwu.de Fri Nov 13 00:29:11 2009 From: alexbestms at wwu.de (Alexander Best) Date: Fri Nov 13 00:29:17 2009 Subject: [patch] add pwait utility Message-ID: thanks a lot. great little application. especially the -v switch is very useful to developers who need quick exit signal feedback from a closing/crashing app imo. would be great to see this committed to HEAD soon. cheers. alex From sh at bel.bc.ca Fri Nov 13 02:08:37 2009 From: sh at bel.bc.ca (Sean Hamilton) Date: Fri Nov 13 02:08:43 2009 Subject: NUMA support; tweaking TCP for GPRS Message-ID: <20091113020835.GE12442@visor.slugabed.org> Greetings -hackers, I have two unrelated questions. First, what is the status of NUMA support in FreeBSD? Is there a performance penalty on Nehalem-class systems, compared with Linux, which advertises NUMA awareness? Google seems to turn up very little on this subject. Second, I am using a FreeBSD server to talk to equipment which has a GPRS internet connection. This is fairly high latency (approximately one second RTT) and is prone to bursts of packet loss, or bursts of extremely high latency -- perhaps up to a minute. These intervals cause many retransmissions, which I presume is a good strategy over the internet, but not so good for GPRS. For my application, latency is mostly irrelevant. However, data over GPRS is very expensive, so I would like to reduce as much as possible the number of TCP retransmissions made on the FreeBSD side, possibly at the expense of latency. So, I am looking for suggestions on how to achieve this, via sysctl, setsockopt, etc. There seems to be a lot of literature regarding TCP tuning, but usually the focus is on improving performance, not reducing network traffic. The "rexmit_min" and "rexmit_sop" sysctls mentioned in tcp(4) seem interesting, but it's not clear to me exactly how they might be adjusted for this purpose. Thanks in advance, -- Sean Hamilton From gary.jennejohn at freenet.de Fri Nov 13 10:16:59 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri Nov 13 10:17:06 2009 Subject: NUMA support; tweaking TCP for GPRS In-Reply-To: <20091113020835.GE12442@visor.slugabed.org> References: <20091113020835.GE12442@visor.slugabed.org> Message-ID: <20091113111656.5dd3beaa@ernst.jennejohn.org> On Thu, 12 Nov 2009 18:08:35 -0800 Sean Hamilton wrote: > Second, I am using a FreeBSD server to talk to equipment > which has a GPRS internet connection. This is fairly high > latency (approximately one second RTT) and is prone to > bursts of packet loss, or bursts of extremely high latency > -- perhaps up to a minute. These intervals cause many > retransmissions, which I presume is a good strategy over the > internet, but not so good for GPRS. > > For my application, latency is mostly irrelevant. However, > data over GPRS is very expensive, so I would like to reduce > as much as possible the number of TCP retransmissions made > on the FreeBSD side, possibly at the expense of latency. > > So, I am looking for suggestions on how to achieve this, via > sysctl, setsockopt, etc. There seems to be a lot of > literature regarding TCP tuning, but usually the focus is on > improving performance, not reducing network traffic. The > "rexmit_min" and "rexmit_sop" sysctls mentioned in tcp(4) > seem interesting, but it's not clear to me exactly how they > might be adjusted for this purpose. > > Thanks in advance, > Highjacking this thread. This won't help you, but it would be interesting to have the new Delay Tolerant Networking protocol developed by Vint Cerf for NASA in FreeBSD. Supposedly it's already in Android. --- Gary Jennejohn From wollman at bimajority.org Fri Nov 13 05:39:16 2009 From: wollman at bimajority.org (Garrett Wollman) Date: Fri Nov 13 12:18:15 2009 Subject: CFR: Exceedingly minor fixes to libc Message-ID: <19196.60473.337121.565916@hergotha.csail.mit.edu> If you have a moment, please take a look at the following patch. It contains some very minor fixes to various parts of libc which were found by the clang static analyzer. They fall into a few categories: 1) Bug fixes in very rare situations (mostly error-handling code that has probably never been executed). 2) Dead store elimination. 3) Elimination of unused variables. (Or in a few cases, making use of them.) Some minor style problems were also fixed in the vicinity. There should be no functional changes except in very unusual conditions. -GAWollman -------------- next part -------------- Index: stdio/fvwrite.c =================================================================== --- stdio/fvwrite.c (revision 199242) +++ stdio/fvwrite.c (working copy) @@ -60,7 +60,7 @@ char *nl; int nlknown, nldist; - if ((len = uio->uio_resid) == 0) + if (uio->uio_resid == 0) return (0); /* make sure we can write */ if (prepwrite(fp) != 0) Index: stdio/vfwprintf.c =================================================================== --- stdio/vfwprintf.c (revision 199242) +++ stdio/vfwprintf.c (working copy) @@ -293,7 +293,7 @@ * number of characters to print. */ p = mbsarg; - insize = nchars = 0; + insize = nchars = nconv = 0; mbs = initial_mbs; while (nchars != (size_t)prec) { nconv = mbrlen(p, MB_CUR_MAX, &mbs); Index: stdio/xprintf_time.c =================================================================== --- stdio/xprintf_time.c (revision 199242) +++ stdio/xprintf_time.c (working copy) @@ -64,7 +64,6 @@ intmax_t t, tx; int i, prec, nsec; - prec = 0; if (pi->is_long) { tv = *((struct timeval **)arg[0]); t = tv->tv_sec; @@ -78,6 +77,8 @@ } else { tp = *((time_t **)arg[0]); t = *tp; + nsec = 0; + prec = 0; } p = buf; Index: stdio/fgetws.c =================================================================== --- stdio/fgetws.c (revision 199242) +++ stdio/fgetws.c (working copy) @@ -89,7 +89,7 @@ if (!__mbsinit(&fp->_mbstate)) /* Incomplete character */ goto error; - *wsp++ = L'\0'; + *wsp = L'\0'; FUNLOCKFILE(fp); return (ws); Index: rpc/getnetconfig.c =================================================================== --- rpc/getnetconfig.c (revision 199242) +++ rpc/getnetconfig.c (working copy) @@ -412,13 +412,13 @@ * Noone needs these entries anymore, then frees them. * Make sure all info in netconfig_info structure has been reinitialized. */ - q = p = ni.head; + q = ni.head; ni.eof = ni.ref = 0; ni.head = NULL; ni.tail = NULL; mutex_unlock(&ni_lock); - while (q) { + while (q != NULL) { p = q->next; if (q->ncp->nc_lookups != NULL) free(q->ncp->nc_lookups); free(q->ncp); Index: rpc/svc_raw.c =================================================================== --- rpc/svc_raw.c (revision 199242) +++ rpc/svc_raw.c (working copy) @@ -176,9 +176,8 @@ msg->acpted_rply.ar_results.proc = (xdrproc_t) xdr_void; msg->acpted_rply.ar_results.where = NULL; - if (!xdr_replymsg(xdrs, msg) || - !SVCAUTH_WRAP(&SVC_AUTH(xprt), xdrs, xdr_proc, xdr_where)) - stat = FALSE; + stat = xdr_replymsg(xdrs, msg) && + SVCAUTH_WRAP(&SVC_AUTH(xprt), xdrs, xdr_proc, xdr_where); } else { stat = xdr_replymsg(xdrs, msg); } Index: rpc/clnt_raw.c =================================================================== --- rpc/clnt_raw.c (revision 199242) +++ rpc/clnt_raw.c (working copy) @@ -92,13 +92,13 @@ rpcprog_t prog; rpcvers_t vers; { - struct clntraw_private *clp = clntraw_private; + struct clntraw_private *clp; struct rpc_msg call_msg; - XDR *xdrs = &clp->xdr_stream; - CLIENT *client = &clp->client_object; + XDR *xdrs; + CLIENT *client; mutex_lock(&clntraw_lock); - if (clp == NULL) { + if ((clp = clntraw_private) == NULL) { clp = (struct clntraw_private *)calloc(1, sizeof (*clp)); if (clp == NULL) { mutex_unlock(&clntraw_lock); @@ -110,6 +110,9 @@ clp->_raw_buf = __rpc_rawcombuf; clntraw_private = clp; } + xdrs = &clp->xdr_stream; + client = &clp->client_object; + /* * pre-serialize the static part of the call msg and stash it away */ Index: rpc/svc_vc.c =================================================================== --- rpc/svc_vc.c (revision 199242) +++ rpc/svc_vc.c (working copy) @@ -141,7 +141,7 @@ r = mem_alloc(sizeof(*r)); if (r == NULL) { warnx("svc_vc_create: out of memory"); - goto cleanup_svc_vc_create; + return NULL; } r->sendsize = __rpc_get_t_size(si.si_af, si.si_proto, (int)sendsize); r->recvsize = __rpc_get_t_size(si.si_af, si.si_proto, (int)recvsize); Index: rpc/getrpcent.c =================================================================== --- rpc/getrpcent.c (revision 199242) +++ rpc/getrpcent.c (working copy) @@ -698,7 +698,7 @@ return (NS_RETURN); } - memcpy(&new_rpc, rpc, sizeof(struct rpcent)); + new_rpc = *rpc; *buffer_size = desired_size; memset(buffer, 0, desired_size); Index: rpc/rpcb_st_xdr.c =================================================================== --- rpc/rpcb_st_xdr.c (revision 199242) +++ rpc/rpcb_st_xdr.c (working copy) @@ -89,7 +89,6 @@ rpcbs_rmtcalllist *objp; { int32_t *buf; - struct rpcbs_rmtcalllist **pnext; if (xdrs->x_op == XDR_ENCODE) { buf = XDR_INLINE(xdrs, 6 * BYTES_PER_XDR_UNIT); @@ -123,8 +122,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - pnext = &objp->next; - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); @@ -162,7 +160,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); @@ -190,7 +188,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); Index: rpc/key_call.c =================================================================== --- rpc/key_call.c (revision 199242) +++ rpc/key_call.c (working copy) @@ -302,7 +302,7 @@ void *localhandle; struct netconfig *nconf; struct netconfig *tpconf; - struct key_call_private *kcp = key_call_private_main; + struct key_call_private *kcp; struct timeval wait_time; struct utsname u; int main_thread; Index: yp/yplib.c =================================================================== --- yp/yplib.c (revision 199242) +++ yp/yplib.c (working copy) @@ -241,7 +241,7 @@ ypmatch_cache_lookup(struct dom_binding *ypdb, char *map, keydat *key, valdat *val) { - struct ypmatch_ent *c = ypdb->cache; + struct ypmatch_ent *c; ypmatch_cache_expire(ypdb); Index: gen/setmode.c =================================================================== --- gen/setmode.c (revision 199242) +++ gen/setmode.c (working copy) @@ -86,7 +86,7 @@ set = (const BITCMD *)bbox; newmode = omode; - for (value = 0;; set++) + for (;; set++) switch(set->cmd) { /* * When copying the user, group or other bits around, we "know" @@ -147,6 +147,7 @@ } #define ADDCMD(a, b, c, d) \ + do { \ if (set >= endset) { \ BITCMD *newset; \ setlen += SET_LEN_INCR; \ @@ -161,7 +162,8 @@ saveset = newset; \ endset = newset + (setlen - 2); \ } \ - set = addcmd(set, (a), (b), (c), (d)) + set = addcmd(set, (a), (b), (c), (d)); \ + } while (0) #define STANDARD_BITS (S_ISUID|S_ISGID|S_IRWXU|S_IRWXG|S_IRWXO) @@ -173,11 +175,12 @@ BITCMD *set, *saveset, *endset; sigset_t sigset, sigoset; mode_t mask; - int equalopdone=0, permXbits, setlen; + int equalopdone, permXbits, setlen; long perml; if (!*p) return (NULL); + equalopdone = 0; /* * Get a copy of the mask for the permissions that are mask relative. @@ -299,16 +302,10 @@ * Add any permissions that we haven't already * done. */ - if (perm || (op == '=' && !equalopdone)) { - if (op == '=') - equalopdone = 1; + if (perm || (op == '=' && !equalopdone)) ADDCMD(op, who, perm, mask); - perm = 0; - } - if (permXbits) { + if (permXbits) ADDCMD('X', who, permXbits, mask); - permXbits = 0; - } goto apply; } } Index: gen/wordexp.c =================================================================== --- gen/wordexp.c (revision 199242) +++ gen/wordexp.c (working copy) @@ -320,7 +320,7 @@ if (c == '\0' || level != 0) return (WRDE_SYNTAX); } else - c = *--words; + --words; break; default: break; Index: gen/getcap.c =================================================================== --- gen/getcap.c (revision 199242) +++ gen/getcap.c (working copy) @@ -647,7 +647,7 @@ cgetnext(char **bp, char **db_array) { size_t len; - int done, hadreaderr, i, savederrno, status; + int done, hadreaderr, savederrno, status; char *cp, *line, *rp, *np, buf[BSIZE], nbuf[BSIZE]; u_int dummy; @@ -658,7 +658,7 @@ (void)cgetclose(); return (-1); } - for(;;) { + for (;;) { if (toprec && !gottoprec) { gottoprec = 1; line = toprec; @@ -709,7 +709,6 @@ /* * Line points to a name line. */ - i = 0; done = 0; np = nbuf; for (;;) { Index: gen/getpwent.c =================================================================== --- gen/getpwent.c (revision 199242) +++ gen/getpwent.c (working copy) @@ -257,22 +257,19 @@ pwd_marshal_func(char *buffer, size_t *buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - uid_t uid; struct passwd *pwd; - char *orig_buf; - size_t orig_buf_size; struct passwd new_pwd; size_t desired_size, size; char *p; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - uid = va_arg(ap, uid_t); + va_arg(ap, uid_t); break; case nss_lt_all: break; @@ -282,8 +279,7 @@ } pwd = va_arg(ap, struct passwd *); - orig_buf = va_arg(ap, char *); - orig_buf_size = va_arg(ap, size_t); + va_end(ap); /* remaining args are unused */ desired_size = sizeof(struct passwd) + sizeof(char *) + strlen(pwd->pw_name) + 1; @@ -361,8 +357,6 @@ pwd_unmarshal_func(char *buffer, size_t buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - uid_t uid; struct passwd *pwd; char *orig_buf; size_t orig_buf_size; @@ -370,12 +364,13 @@ char *p; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - uid = va_arg(ap, uid_t); + va_arg(ap, uid_t); break; case nss_lt_all: break; @@ -921,7 +916,7 @@ errnop); } while (how == nss_lt_all && !(rv & NS_TERMINATE)); fin: - if (!stayopen && st->db != NULL) { + if (st->db != NULL && !stayopen) { (void)st->db->close(st->db); st->db = NULL; } @@ -1876,7 +1871,6 @@ syslog(LOG_ERR, "getpwent memory allocation failure"); *errnop = ENOMEM; - rv = NS_UNAVAIL; break; } st->compat = COMPAT_MODE_NAME; @@ -1940,7 +1934,7 @@ break; } fin: - if (!stayopen && st->db != NULL) { + if (st->db != NULL && !stayopen) { (void)st->db->close(st->db); st->db = NULL; } Index: gen/getgrent.c =================================================================== --- gen/getgrent.c (revision 199242) +++ gen/getgrent.c (working copy) @@ -207,22 +207,19 @@ grp_marshal_func(char *buffer, size_t *buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - gid_t gid; struct group *grp; - char *orig_buf; - size_t orig_buf_size; struct group new_grp; size_t desired_size, size, mem_size; char *p, **mem; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - gid = va_arg(ap, gid_t); + va_arg(ap, gid_t); break; case nss_lt_all: break; @@ -232,8 +229,7 @@ } grp = va_arg(ap, struct group *); - orig_buf = va_arg(ap, char *); - orig_buf_size = va_arg(ap, size_t); + va_end(ap); /* remaining args are unused */ desired_size = _ALIGNBYTES + sizeof(struct group) + sizeof(char *); @@ -302,8 +298,6 @@ grp_unmarshal_func(char *buffer, size_t buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - gid_t gid; struct group *grp; char *orig_buf; size_t orig_buf_size; @@ -314,10 +308,10 @@ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - gid = va_arg(ap, gid_t); + va_arg(ap, gid_t); break; case nss_lt_all: break; @@ -1100,6 +1094,9 @@ case nss_lt_all: map = "group.byname"; break; + default: + *errnop = EINVAL; + return (NS_UNAVAIL); } grp = va_arg(ap, struct group *); buffer = va_arg(ap, char *); @@ -1392,6 +1389,13 @@ } break; case NS_RETURN: + /* + * If _nsdispatch() sets *errnop to ERANGE (can it?) + * we need a valid file position. Assume it might + * close st->fp, too (can it?). + */ + if (st->fp != NULL) + pos = ftello(st->fp); goto fin; default: break; @@ -1450,7 +1454,7 @@ pos = ftello(st->fp); } fin: - if (!stayopen && st->fp != NULL) { + if (st->fp != NULL && !stayopen) { fclose(st->fp); st->fp = NULL; } Index: gen/getusershell.c =================================================================== --- gen/getusershell.c (revision 199242) +++ gen/getusershell.c (working copy) @@ -124,7 +124,7 @@ if ((fp = fopen(_PATH_SHELLS, "r")) == NULL) return NS_UNAVAIL; - sp = cp = line; + cp = line; while (fgets(cp, MAXPATHLEN + 1, fp) != NULL) { while (*cp != '#' && *cp != '/' && *cp != '\0') cp++; Index: gen/pw_scan.c =================================================================== --- gen/pw_scan.c (revision 199242) +++ gen/pw_scan.c (working copy) @@ -202,7 +202,7 @@ if (p[0]) pw->pw_fields |= _PWF_SHELL; - if ((p = strsep(&bp, ":"))) { /* too many */ + if (strsep(&bp, ":") != NULL) { /* too many */ fmt: if (flags & _PWSCAN_WARN) warnx("corrupted entry"); Index: net/sctp_sys_calls.c =================================================================== --- net/sctp_sys_calls.c (revision 199242) +++ net/sctp_sys_calls.c (working copy) @@ -242,7 +242,8 @@ struct sockaddr *sa; struct sockaddr_in *sin; struct sockaddr_in6 *sin6; - int i, sz, argsz; + int i, argsz; + size_t sz; uint16_t sport = 0; /* validate the flags */ @@ -268,7 +269,7 @@ for (i = 0; i < addrcnt; i++) { sz = sa->sa_len; if (sa->sa_family == AF_INET) { - if (sa->sa_len != sizeof(struct sockaddr_in)) + if (sz != sizeof(struct sockaddr_in)) goto out_error; sin = (struct sockaddr_in *)sa; if (sin->sin_port) { @@ -284,7 +285,7 @@ } } } else if (sa->sa_family == AF_INET6) { - if (sa->sa_len != sizeof(struct sockaddr_in6)) + if (sz != sizeof(struct sockaddr_in6)) goto out_error; sin6 = (struct sockaddr_in6 *)sa; if (sin6->sin6_port) { @@ -318,10 +319,10 @@ for (i = 0; i < addrcnt; i++) { sz = sa->sa_len; if (sa->sa_family == AF_INET) { - if (sa->sa_len != sizeof(struct sockaddr_in)) + if (sz != sizeof(struct sockaddr_in)) goto out_error; } else if (sa->sa_family == AF_INET6) { - if (sa->sa_len != sizeof(struct sockaddr_in6)) + if (sz != sizeof(struct sockaddr_in6)) goto out_error; } else { /* invalid address family specified */ Index: net/getservent.c =================================================================== --- net/getservent.c (revision 199242) +++ net/getservent.c (working copy) @@ -476,11 +476,11 @@ struct nis_state *st; int rv; - enum nss_lookup_type how; char *name; char *proto; int port; + enum nss_lookup_type how; struct servent *serv; char *buffer; size_t bufsize; @@ -491,7 +491,8 @@ name = NULL; proto = NULL; - how = (enum nss_lookup_type)mdata; + + how = (intptr_t)mdata; switch (how) { case nss_lt_name: name = va_arg(ap, char *); Index: posix1e/acl_delete_entry.c =================================================================== --- posix1e/acl_delete_entry.c (revision 199242) +++ posix1e/acl_delete_entry.c (working copy) @@ -89,20 +89,20 @@ return (-1); } - if ((acl->ats_acl.acl_cnt < 1) || - (acl->ats_acl.acl_cnt > ACL_MAX_ENTRIES)) { + if ((acl_int->acl_cnt < 1) || + (acl_int->acl_cnt > ACL_MAX_ENTRIES)) { errno = EINVAL; return (-1); } - for (i = 0; i < acl->ats_acl.acl_cnt;) { - if (_entry_matches(&(acl->ats_acl.acl_entry[i]), entry_d)) { + for (i = 0; i < acl_int->acl_cnt;) { + if (_entry_matches(&(acl_int->acl_entry[i]), entry_d)) { /* ...shift the remaining entries... */ - for (j = i; j < acl->ats_acl.acl_cnt - 1; ++j) - acl->ats_acl.acl_entry[j] = - acl->ats_acl.acl_entry[j+1]; + for (j = i; j < acl_int->acl_cnt - 1; ++j) + acl_int->acl_entry[j] = + acl_int->acl_entry[j+1]; /* ...drop the count and zero the unused entry... */ - acl->ats_acl.acl_cnt--; - bzero(&acl->ats_acl.acl_entry[j], + acl_int->acl_cnt--; + bzero(&acl_int->acl_entry[j], sizeof(struct acl_entry)); acl->ats_cur_entry = 0; Index: inet/inet_cidr_pton.c =================================================================== --- inet/inet_cidr_pton.c (revision 199242) +++ inet/inet_cidr_pton.c (working copy) @@ -236,7 +236,6 @@ endp[- i] = colonp[n - i]; colonp[n - i] = 0; } - tp = endp; } memcpy(dst, tmp, NS_IN6ADDRSZ); From jhb at freebsd.org Fri Nov 13 14:57:59 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 13 14:58:06 2009 Subject: NUMA support; tweaking TCP for GPRS In-Reply-To: <20091113020835.GE12442@visor.slugabed.org> References: <20091113020835.GE12442@visor.slugabed.org> Message-ID: <200911130934.55996.jhb@freebsd.org> On Thursday 12 November 2009 9:08:35 pm Sean Hamilton wrote: > Greetings -hackers, > > I have two unrelated questions. > > First, what is the status of NUMA support in FreeBSD? Is > there a performance penalty on Nehalem-class systems, > compared with Linux, which advertises NUMA awareness? Google > seems to turn up very little on this subject. Yes, there is a penalty. I have some very simplistic NUMA support in a p4 branch (//depot/user/jhb/numa/...) that just makes threads allocate memory close to the current CPU when requesting a free page. It's not very general purpose, but it can be useful if you pin all your tasks to specific packages. I haven't tested it with non-pinned workloads to see what effect it has. -- John Baldwin From jilles at stack.nl Fri Nov 13 15:37:12 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Nov 13 15:37:18 2009 Subject: CFR: Exceedingly minor fixes to libc In-Reply-To: <19196.60473.337121.565916@hergotha.csail.mit.edu> References: <19196.60473.337121.565916@hergotha.csail.mit.edu> Message-ID: <20091113153710.GA99645@stack.nl> On Fri, Nov 13, 2009 at 12:18:49AM -0500, Garrett Wollman wrote: > If you have a moment, please take a look at the following patch. It > contains some very minor fixes to various parts of libc which were > found by the clang static analyzer. They fall into a few categories: > 1) Bug fixes in very rare situations (mostly error-handling code that > has probably never been executed). > 2) Dead store elimination. > 3) Elimination of unused variables. (Or in a few cases, making use of > them.) > Some minor style problems were also fixed in the vicinity. There > should be no functional changes except in very unusual conditions. This looks mostly ok, with a few exceptions. > [...] > Index: gen/getpwent.c > =================================================================== > --- gen/getpwent.c (revision 199242) > +++ gen/getpwent.c (working copy) > @@ -257,22 +257,19 @@ > [...] > @@ -1876,7 +1871,6 @@ > syslog(LOG_ERR, > "getpwent memory allocation failure"); > *errnop = ENOMEM; > - rv = NS_UNAVAIL; > break; > } > st->compat = COMPAT_MODE_NAME; I think this change hides the wrongness in the handling of malloc errors while leaving it as broken as it is. > [...] > Index: net/getservent.c > =================================================================== > --- net/getservent.c (revision 199242) > +++ net/getservent.c (working copy) > @@ -476,11 +476,11 @@ > struct nis_state *st; > int rv; > > - enum nss_lookup_type how; > char *name; > char *proto; > int port; > > + enum nss_lookup_type how; > struct servent *serv; > char *buffer; > size_t bufsize; > @@ -491,7 +491,8 @@ > > name = NULL; > proto = NULL; > - how = (enum nss_lookup_type)mdata; > + > + how = (intptr_t)mdata; > switch (how) { > case nss_lt_name: > name = va_arg(ap, char *); In what way is this an improvement? > Index: posix1e/acl_delete_entry.c > =================================================================== > --- posix1e/acl_delete_entry.c (revision 199242) > +++ posix1e/acl_delete_entry.c (working copy) > @@ -89,20 +89,20 @@ > return (-1); > } > > - if ((acl->ats_acl.acl_cnt < 1) || > - (acl->ats_acl.acl_cnt > ACL_MAX_ENTRIES)) { > + if ((acl_int->acl_cnt < 1) || > + (acl_int->acl_cnt > ACL_MAX_ENTRIES)) { > errno = EINVAL; > return (-1); > } If you are changing this code anyway, consider fixing a style bug (extraneous parentheses) here. > - for (i = 0; i < acl->ats_acl.acl_cnt;) { > - if (_entry_matches(&(acl->ats_acl.acl_entry[i]), entry_d)) { > + for (i = 0; i < acl_int->acl_cnt;) { > + if (_entry_matches(&(acl_int->acl_entry[i]), entry_d)) { > /* ...shift the remaining entries... */ > - for (j = i; j < acl->ats_acl.acl_cnt - 1; ++j) > - acl->ats_acl.acl_entry[j] = > - acl->ats_acl.acl_entry[j+1]; > + for (j = i; j < acl_int->acl_cnt - 1; ++j) > + acl_int->acl_entry[j] = > + acl_int->acl_entry[j+1]; > /* ...drop the count and zero the unused entry... */ > - acl->ats_acl.acl_cnt--; > - bzero(&acl->ats_acl.acl_entry[j], > + acl_int->acl_cnt--; > + bzero(&acl_int->acl_entry[j], > sizeof(struct acl_entry)); > acl->ats_cur_entry = 0; > -- Jilles Tjoelker From ume at freebsd.org Fri Nov 13 16:15:37 2009 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Fri Nov 13 16:15:48 2009 Subject: CFR: Exceedingly minor fixes to libc In-Reply-To: <19196.60473.337121.565916@hergotha.csail.mit.edu> References: <19196.60473.337121.565916@hergotha.csail.mit.edu> Message-ID: Hi, >>>>> On Fri, 13 Nov 2009 00:18:49 -0500 >>>>> Garrett Wollman said: wollman> Index: inet/inet_cidr_pton.c wollman> =================================================================== wollman> --- inet/inet_cidr_pton.c (revision 199242) wollman> +++ inet/inet_cidr_pton.c (working copy) wollman> @@ -236,7 +236,6 @@ wollman> endp[- i] = colonp[n - i]; wollman> colonp[n - i] = 0; wollman> } wollman> - tp = endp; wollman> } wollman> wollman> memcpy(dst, tmp, NS_IN6ADDRSZ); Since this function is vendor import one from ISC, such cosmetic change may cause problem during further import. So, you should send this patch to ISC folks 1st. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From beckman at angryox.com Fri Nov 13 19:58:26 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri Nov 13 19:58:33 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot Message-ID: I've been scratching my head all day on an issue that's been frustrating. I've got two FreeBSD 6.2 instances installed on two M600 blades, and am moving to a new datacenter with M600 blades and trying to install FreeBSD 7.2 or 8. But as others on this list and elsewhere have mentioned, seemingly without resolution, is that it doesn't work. http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html http://forums.freebsd.org/showthread.php?t=486 I was able to install 6.4 on it today, but I'm still at a loss as to why 7.x and even 8.x will not. Did the architecture change in such a way that it could no longer support M600 blades? Did someone leave something out of the standard ISO kernel? Am I not doing it right? Happy to pass along my dmesg.boot; I'm not sure how to troubleshoot this, or where to look for documentation that says something in the M600 is no longer supported, or that what was supported in the M600 was changed that now causes FreeBSD to hang instead of booting. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From anti_spamsys at yahoo.com Fri Nov 13 22:53:49 2009 From: anti_spamsys at yahoo.com (Trever) Date: Fri Nov 13 22:53:56 2009 Subject: bad source in the distro iso's Message-ID: <801850.20206.qm@web113202.mail.gq1.yahoo.com> I noticed in 7.2 that the /usr/src installed from the ISO downloads would not build without first sup'ing for a few updates. (disc1.iso's) I notice in the 8.0RC2&3 that some of the source files are corrupted. Not a media issue, checksum's have always been confirmed good. Is this normal, for the packaged source to be "bad"? One of the nice things about BSD is that it comes with everything to build itself, but if the source won't build without first updating... Just curious. Trever From manolis at FreeBSD.org Sat Nov 14 06:51:40 2009 From: manolis at FreeBSD.org (Manolis Kiagias) Date: Sat Nov 14 06:52:19 2009 Subject: bad source in the distro iso's In-Reply-To: <801850.20206.qm@web113202.mail.gq1.yahoo.com> References: <801850.20206.qm@web113202.mail.gq1.yahoo.com> Message-ID: <4AFE4F17.6050007@FreeBSD.org> Trever wrote: > I noticed in 7.2 that the /usr/src installed from the ISO downloads would not build without first sup'ing for a few updates. (disc1.iso's) > > I notice in the 8.0RC2&3 that some of the source files are corrupted. > > Not a media issue, checksum's have always been confirmed good. > > Is this normal, for the packaged source to be "bad"? > > One of the nice things about BSD is that it comes with everything to build itself, but if the source won't build without first updating... > > Just curious. > > Trever > > There must be something wrong at your end. I routinely run make buildworld / make release using -RELEASE sources and never had any problems. Are you sure you are installing *all* the sources, both kernel and world? It could be that something goes wrong during decompression, though I suspect this would happen to other files as well leading to a non-working system. From rea-fbsd at codelabs.ru Sat Nov 14 07:57:56 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sat Nov 14 07:58:03 2009 Subject: bad source in the distro iso's Message-ID: Trever wrote: > I noticed in 7.2 that the /usr/src installed from the ISO downloads > would not build without first sup'ing for a few updates. > (disc1.iso's) > > I notice in the 8.0RC2&3 that some of the source files are corrupted. Can you be precise in what's going wrong? What objects can't be built, what are error messages, etc? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From thierry.herbelot at free.fr Sat Nov 14 11:45:38 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Sat Nov 14 12:50:05 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: References: Message-ID: <200911141245.20217.thierry.herbelot@free.fr> Le Friday 13 November 2009, Peter Beckman a ?crit : > I've been scratching my head all day on an issue that's been frustrating. > > I've got two FreeBSD 6.2 instances installed on two M600 blades, and am > moving to a new datacenter with M600 blades and trying to install FreeBSD > 7.2 or 8. But as others on this list and elsewhere have mentioned, > seemingly without resolution, is that it doesn't work. > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html > http://forums.freebsd.org/showthread.php?t=486 > > I was able to install 6.4 on it today, but I'm still at a loss as to why > 7.x and even 8.x will not. Did the architecture change in such a way that > it could no longer support M600 blades? Did someone leave something out of > the standard ISO kernel? Am I not doing it right? > > Happy to pass along my dmesg.boot; Hello, from the two URLs you provide, it seems that i386 is working (for all FreeBSD versions) and only amd64 is failing : can you confirm this ? then, one of the first steps would be a the dmesg of both a succeeding and a failing kernels (verbose !) TfH PS : is there any more recent version of the Dell BIOS ? > I'm not sure how to troubleshoot this, > or where to look for documentation that says something in the M600 is no > longer supported, or that what was supported in the M600 was changed that > now causes FreeBSD to hang instead of booting. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman@angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From killing at multiplay.co.uk Sat Nov 14 13:33:30 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Nov 14 13:33:37 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot References: <200911141245.20217.thierry.herbelot@free.fr> Message-ID: <1691ED1396D14B8CA5AB95152C3041E0@multiplay.co.uk> Yes I can confirm that. Regards Steve ----- Original Message ----- From: "Thierry Herbelot" > from the two URLs you provide, it seems that i386 is working (for all FreeBSD > versions) and only amd64 is failing : can you confirm this ? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From thierry.herbelot at laposte.net Sat Nov 14 15:31:33 2009 From: thierry.herbelot at laposte.net (Thierry Herbelot) Date: Sat Nov 14 15:31:41 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: <1691ED1396D14B8CA5AB95152C3041E0@multiplay.co.uk> References: <200911141245.20217.thierry.herbelot@free.fr> <1691ED1396D14B8CA5AB95152C3041E0@multiplay.co.uk> Message-ID: <200911141612.38908.thierry.herbelot@laposte.net> Le Saturday 14 November 2009, Steven Hartland a ?crit : > Yes I can confirm that. then, could you please provide the verbose dmesg for both working and non-working configurations ? TfH > > Regards > Steve > ----- Original Message ----- > From: "Thierry Herbelot" > > > from the two URLs you provide, it seems that i386 is working (for all > > FreeBSD versions) and only amd64 is failing : can you confirm this ? > From beckman at angryox.com Sat Nov 14 15:48:45 2009 From: beckman at angryox.com (Peter Beckman) Date: Sat Nov 14 15:48:52 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: <200911141245.20217.thierry.herbelot@free.fr> References: <200911141245.20217.thierry.herbelot@free.fr> Message-ID: On Sat, 14 Nov 2009, Thierry Herbelot wrote: > Le Friday 13 November 2009, Peter Beckman a ?crit : >> I've been scratching my head all day on an issue that's been frustrating. >> >> I've got two FreeBSD 6.2 instances installed on two M600 blades, and am >> moving to a new datacenter with M600 blades and trying to install FreeBSD >> 7.2 or 8. But as others on this list and elsewhere have mentioned, >> seemingly without resolution, is that it doesn't work. >> >> >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html >> http://forums.freebsd.org/showthread.php?t=486 >> >> I was able to install 6.4 on it today, but I'm still at a loss as to why >> 7.x and even 8.x will not. Did the architecture change in such a way that >> it could no longer support M600 blades? Did someone leave something out of >> the standard ISO kernel? Am I not doing it right? >> >> Happy to pass along my dmesg.boot; > > from the two URLs you provide, it seems that i386 is working (for all FreeBSD > versions) and only amd64 is failing : can you confirm this ? > > then, one of the first steps would be a the dmesg of both a succeeding and a > failing kernels (verbose !) I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of which fail to boot on the Dell M600. I was able to boot the bootonly 6.4 ISO, install via the net, and a friend suggested I try binary updating. I have been able to binary update to 7.0-RELEASE thus far. I'm trying to get to 8.0-RC3 via binary update now, and will report back. I believe the issue is not with FreeBSD but the bootonly ISO. It could also be a problem with the other ISOs, I'm not yet sure. > PS : is there any more recent version of the Dell BIOS ? According to the iDRAC, the firmware 2.2.3 reported as installed is what Dell reports as the latest version (August 2009). --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From thierry.herbelot at laposte.net Sat Nov 14 16:20:57 2009 From: thierry.herbelot at laposte.net (Thierry Herbelot) Date: Sat Nov 14 16:21:04 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: References: <200911141245.20217.thierry.herbelot@free.fr> Message-ID: <200911141720.38432.thierry.herbelot@laposte.net> Le Saturday 14 November 2009, Peter Beckman a ?crit : > On Sat, 14 Nov 2009, Thierry Herbelot wrote: > > Le Friday 13 November 2009, Peter Beckman a ?crit : > >> I've been scratching my head all day on an issue that's been > >> frustrating. > >> > >> I've got two FreeBSD 6.2 instances installed on two M600 blades, and am > >> moving to a new datacenter with M600 blades and trying to install > >> FreeBSD 7.2 or 8. But as others on this list and elsewhere have > >> mentioned, seemingly without resolution, is that it doesn't work. > >> > >> > >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html > >> http://forums.freebsd.org/showthread.php?t=486 > >> > >> I was able to install 6.4 on it today, but I'm still at a loss as to why > >> 7.x and even 8.x will not. Did the architecture change in such a way > >> that it could no longer support M600 blades? Did someone leave > >> something out of the standard ISO kernel? Am I not doing it right? > >> > >> Happy to pass along my dmesg.boot; > > > > from the two URLs you provide, it seems that i386 is working (for all > > FreeBSD versions) and only amd64 is failing : can you confirm this ? > > > > then, one of the first steps would be a the dmesg of both a succeeding > > and a failing kernels (verbose !) > > I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of > which fail to boot on the Dell M600. aha ! anyway, even with a CDROM, you can boot *verbose* and note where the boot stops (even if there won't be a serial console, write down the blocking device probe) TfH > > I was able to boot the bootonly 6.4 ISO, install via the net, and a > friend suggested I try binary updating. I have been able to binary update > to 7.0-RELEASE thus far. I'm trying to get to 8.0-RC3 via binary update > now, and will report back. (a more robust, and slower, way to upgrade is via make buildworld / make buildkernel) > > I believe the issue is not with FreeBSD but the bootonly ISO. It could > also be a problem with the other ISOs, I'm not yet sure. we may get a hint if/when someone sends some verbose dmesg ;-) > > > PS : is there any more recent version of the Dell BIOS ? > > According to the iDRAC, the firmware 2.2.3 reported as installed is what > Dell reports as the latest version (August 2009). fine > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman@angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- From thierry.herbelot at laposte.net Sat Nov 14 17:19:29 2009 From: thierry.herbelot at laposte.net (Thierry Herbelot) Date: Sat Nov 14 17:19:36 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: References: <200911141720.38432.thierry.herbelot@laposte.net> Message-ID: <200911141819.12000.thierry.herbelot@laposte.net> Le Saturday 14 November 2009, Peter Beckman a ?crit : [SNIP] > >>> > >>> then, one of the first steps would be a the dmesg of both a succeeding > >>> and a failing kernels (verbose !) > >> > >> I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of > >> which fail to boot on the Dell M600. > > > > aha ! > > > > anyway, even with a CDROM, you can boot *verbose* and note where the boot > > stops (even if there won't be a serial console, write down the blocking > > device probe) > > Can you shoot me a link to the docs on how to do this? I haven't been > able to find out how. speaking from memory : just before the kernel starts, you should have the *loader* menu (with the ASCII graphics depicting beastie), where you can choose between boot options, and option 5 is boot verbose (like 4 is boot single) TfH > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman@angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- From beckman at angryox.com Sun Nov 15 03:18:06 2009 From: beckman at angryox.com (Peter Beckman) Date: Sun Nov 15 03:18:12 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: <200911141819.12000.thierry.herbelot@laposte.net> References: <200911141720.38432.thierry.herbelot@laposte.net> <200911141819.12000.thierry.herbelot@laposte.net> Message-ID: On Sat, 14 Nov 2009, Thierry Herbelot wrote: > Le Saturday 14 November 2009, Peter Beckman a ?crit : > [SNIP] >>>>> >>>>> then, one of the first steps would be a the dmesg of both a succeeding >>>>> and a failing kernels (verbose !) >>>> >>>> I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of >>>> which fail to boot on the Dell M600. >>> >>> aha ! >>> >>> anyway, even with a CDROM, you can boot *verbose* and note where the boot >>> stops (even if there won't be a serial console, write down the blocking >>> device probe) >> >> Can you shoot me a link to the docs on how to do this? I haven't been >> able to find out how. > > speaking from memory : just before the kernel starts, you should have the > *loader* menu (with the ASCII graphics depicting beastie), where you can > choose between boot options, and option 5 is boot verbose (like 4 is boot > single) Not sure I have any more. Since I'm not in front of the console, and since the iDRAC only allows a "video" capture of the console, I made a video. http://drop.io/rk0eoap The Verbose option was selected, but it hung at the same place it did. I was using the 8.0-RC3 bootonly iso. It hung just after isab0, isa0 and atrtc0 loaded. The last line: atrtc0: registered as a time-of-day clock (resolution 1000000us) The machine is just fine, I installed NetBSD 5.0.1 on it, and I have FreeBSD 7.0-RELEASE running on another blade adjacent to it. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From beckman at angryox.com Sun Nov 15 03:42:10 2009 From: beckman at angryox.com (Peter Beckman) Date: Sun Nov 15 03:42:17 2009 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot In-Reply-To: <200911141819.12000.thierry.herbelot@laposte.net> References: <200911141720.38432.thierry.herbelot@laposte.net> <200911141819.12000.thierry.herbelot@laposte.net> Message-ID: On Sat, 14 Nov 2009, Thierry Herbelot wrote: > Le Saturday 14 November 2009, Peter Beckman a ?crit : > [SNIP] >>>>> >>>>> then, one of the first steps would be a the dmesg of both a succeeding >>>>> and a failing kernels (verbose !) >>>> >>>> I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of >>>> which fail to boot on the Dell M600. So I was able to binary update from 6.4 to 7.0-RELEASE, but when I tried freebsd-update -r 8.0-RC3 upgrade After installing after that I get the same hanging I saw with the bootonly ISO. The mpt0 device is loaded, pcib8, but after it hits atrtc0, it hangs. I'm trying what someone suggested previously -- install 8.0-RC3 using the 6.4 install disk via the net. I'm trying that now, but I'm not hopeful. I think I need to give up and move on that FreeBSD isn't going to work. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From anti_spamsys at yahoo.com Sun Nov 15 10:49:44 2009 From: anti_spamsys at yahoo.com (Trever) Date: Sun Nov 15 10:49:52 2009 Subject: bad source in the distro iso's In-Reply-To: Message-ID: <159670.52451.qm@web113214.mail.gq1.yahoo.com> The problem is on our end, not the release(s), though I had convinced myself otherwise. Sorry for my momentary loss of confidence in the releases! And, I'm not sure my original post should have gone to this list. What I can say is that whatever the heck it is we are doing wrong on our end is not obvious, but that's a different issue than the issue of knowing whether or not we can trust the release(s), which it seems we certainly can. That's a relief. With regard to 8.0 RC2&3, simply using the src/install.sh script for the src works without the errors and corrupted files. Our script does the same thing, but obviously not quite. Weird, but we'll figure it out. Re 7.2 iso sources, based on the responses that no one has had this type of problem, I assume this is our end again. Thanks all! Trever --- On Fri, 11/13/09, Eygene Ryabinkin wrote: > From: Eygene Ryabinkin > Subject: Re: bad source in the distro iso's > To: "Trever" > Cc: freebsd-hackers@FreeBSD.org > Date: Friday, November 13, 2009, 11:57 PM > Trever wrote: > > I noticed in 7.2 that the /usr/src installed from the > ISO downloads > > would not build without first sup'ing for a few > updates. > > (disc1.iso's) > > > > I notice in the 8.0RC2&3 that some of the source > files are corrupted. > > Can you be precise in what's going wrong?? What > objects can't be built, > what are error messages, etc? > > Thanks! > -- > Eygene > _? ? ? ? ? ? ? ? > ___? ? ???_.--.???# > > \`.|\..----...-'`???`-._.-'_.-'`???#? > Remember that it is hard > /? ' `? ? ? ???,? > ? ???__.--'? ? ? #? > to read the on-line manual > )/' _/? > ???\???`-_,???/? > ? ? ? ? ? #? while > single-stepping the kernel. > `-'" `"\_? ,_.-;_.-\_ ',? > fsc/as???# > ? > ???_.-'_./???{_.'???; > /? ? ? ? ???#? > ? -- FreeBSD Developers handbook > ? ? {_.-``-'? ? ? > ???{_/? ? ? ? ? > ? # > _______________________________________________ > freebsd-hackers@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From prirun at gmail.com Sun Nov 15 17:20:27 2009 From: prirun at gmail.com (Jim Wilcoxson) Date: Sun Nov 15 17:20:34 2009 Subject: acl_from_text leaking memory In-Reply-To: References: Message-ID: I've been working on a new backup program, HashBackup, and believe I have found a memory leak with ACLs in PCBSD/FreeBSD 7.1 and OSX (Leopard). acl_from_text is a function that takes a text string as input, and returns a pointer to a malloc'd acl. This acl is then freed with acl_free. I noticed that acl_from_text appears to leak memory. This is not used during the backup of a filesystem, but is needed to do a restore. After looking at the acl_from_text source in /usr/src/lib/libc/posix1e (from PCBSD7.1), I believe the problem is that the duplicate text string, mybuf_p, is not freed on normal return of this function. Here is the end of this function: } #if 0 /* XXX Should we only return ACLs valid according to acl_valid? */ /* Verify validity of the ACL we read in. */ if (acl_valid(acl) == -1) { errno = EINVAL; goto error_label; } #endif return(acl); error_label: acl_free(acl); free(mybuf_p); return(NULL); } I think there should be a free(mybuf_p) before return(acl). Here is a PCBSD/FreeBSD test program that causes the memory leak: #include #include #include main() { acl_t acl; char* acltext; acltext = "user::rw-\n group::r--\n mask::r--\n other::r--\n"; while (1) { acl = acl_from_text(acltext); if (acl == NULL) printf("acl_from_text failed\n"); if (acl_free(acl) != 0) printf("acl_free failed\n"); } } I've subscribed to the lists for a few days in case there are questions or I can help test something. Thanks, Jim -- HashBackup beta: http://sites.google.com/site/hashbackup From dougb at FreeBSD.org Mon Nov 16 02:56:39 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Nov 16 02:56:47 2009 Subject: Alps GlidePoint driver for synaptics. In-Reply-To: References: Message-ID: <4B00BF6E.8070606@FreeBSD.org> David DEMELIER wrote: > Hello there, > > I noticed that for the moment there is no support for alps based > touchpads, is there anyone working on a driver for -CURRENT ? By "no support" do you mean that it does not work at all, even with moused? Or do you mean no support for custom features of the touchpad? I have a similar model on my Dell laptop and it works fine with moused for basic features. It's old enough though that it doesn't have any features that are not basic. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From des at des.no Mon Nov 16 09:52:00 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 16 09:52:07 2009 Subject: bad source in the distro iso's In-Reply-To: <159670.52451.qm@web113214.mail.gq1.yahoo.com> (Trever's message of "Sun, 15 Nov 2009 02:49:43 -0800 (PST)") References: <159670.52451.qm@web113214.mail.gq1.yahoo.com> Message-ID: <86lji6pzk3.fsf@ds4.des.no> Trever writes: > With regard to 8.0 RC2&3, simply using the src/install.sh script for > the src works without the errors and corrupted files. I wonder why we still bother splitting the tarballs... it's not like anyone is going to try installing 8.0 from floppies. DES -- Dag-Erling Sm?rgrav - des@des.no From gary.jennejohn at freenet.de Mon Nov 16 12:26:44 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Nov 16 12:26:51 2009 Subject: acl_from_text leaking memory In-Reply-To: References: Message-ID: <20091116132641.6340432b@ernst.jennejohn.org> On Sun, 15 Nov 2009 11:47:28 -0500 Jim Wilcoxson wrote: > I've been working on a new backup program, HashBackup, and believe I > have found a memory leak with ACLs in PCBSD/FreeBSD 7.1 and OSX > (Leopard). > > acl_from_text is a function that takes a text string as input, and > returns a pointer to a malloc'd acl. This acl is then freed with > acl_free. I noticed that acl_from_text appears to leak memory. This > is not used during the backup of a filesystem, but is needed to do a > restore. > > After looking at the acl_from_text source in /usr/src/lib/libc/posix1e > (from PCBSD7.1), I believe the problem is that the duplicate text > string, mybuf_p, is not freed on normal return of this function. Here > is the end of this function: > [snip code] Looks to me like you're right. Have you tried applying the suggested change and testing it for regressions? Reporting that it works without side effects would definitely be convincing and increase the chances of getting it committed. --- Gary Jennejohn From lujiandong1001 at yahoo.com.cn Mon Nov 16 12:55:19 2009 From: lujiandong1001 at yahoo.com.cn (Jiandong Lu) Date: Mon Nov 16 12:55:26 2009 Subject: how to build libthr except other components of 'world' Message-ID: <900874.43629.qm@web15707.mail.cnb.yahoo.com> --- 09?11?16????, Jiandong Lu ??? ???: Jiandong Lu ??: how to build libthr except other components of 'world' ???: freebsd-threads@freebsd.org ??: 2009?11?16?,??,??6:48 Hi,everyone, ??? I checkout FreeBSD?s source codes to my /usr/src ??? I use command ??? make buildworld ??? int directory /usr/src to build a world.I want to do some debug to lib /usr/src/lib/libthr.If I modified some files in /usr/src/lib/libthr/thread, how could I build libthr except other components of world? ?? btw,I execute command ?? make ?? in /usr/src/lib/libthr get this : cc -O2 -fno-strict-aliasing -pipe? -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread? -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/arch/i386/i386/pthread_md.c In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:33: /usr/src/lib/libthr/../../include/string.h:86: warning: no previous prototype for 'strdup' /usr/src/lib/libthr/../../include/string.h: In function 'strdup': /usr/src/lib/libthr/../../include/string.h:86: error: expected declaration specifiers before '__malloc_like' /usr/src/lib/libthr/../../include/string.h:96: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:101: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:104: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__malloc_like' /usr/src/lib/libthr/../../include/string.h:105: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:108: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:110: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:111: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:118: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:119: warning: '__pure__' attribute ignored In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:34: /usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:60: error: storage class specified for parameter '_rtld_allocate_tls' /usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:67: error: storage class specified for parameter '_rtld_free_tls' In file included from /usr/src/lib/libthr/arch/i386/include/pthread_md.h:36, ???????????????? from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36: /usr/src/lib/libthr/../../include/stddef.h:45: error: storage class specified for parameter 'ptrdiff_t' /usr/src/lib/libthr/../../include/stddef.h:49: error: storage class specified for parameter 'rune_t' /usr/src/lib/libthr/../../include/stddef.h:61: error: storage class specified for parameter 'wchar_t' In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36: /usr/src/lib/libthr/arch/i386/include/pthread_md.h:52: warning: empty declaration /usr/src/lib/libthr/arch/i386/include/pthread_md.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/include/pthread_md.h:95: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/include/pthread_md.h:102: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: old-style parameter declarations in prototyped function definition /usr/src/lib/libthr/../../include/string.h:86: error: parameter name omitted /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: expected '{' at end of input *** Error code 1 Stop in /usr/src/lib/libthr. ---------------------------------- thanks. ? ????????????????? ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From bruce at cran.org.uk Mon Nov 16 12:57:10 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Mon Nov 16 12:57:17 2009 Subject: bad source in the distro iso's In-Reply-To: <86lji6pzk3.fsf@ds4.des.no> References: <159670.52451.qm@web113214.mail.gq1.yahoo.com> <86lji6pzk3.fsf@ds4.des.no> Message-ID: <20091116125625.000058a7@unknown> On Mon, 16 Nov 2009 10:51:56 +0100 Dag-Erling Sm?rgrav wrote: > Trever writes: > > With regard to 8.0 RC2&3, simply using the src/install.sh script for > > the src works without the errors and corrupted files. > > I wonder why we still bother splitting the tarballs... it's not like > anyone is going to try installing 8.0 from floppies. See http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052241.html - apparently people are still wanting to install from floppies. -- Bruce Cran From des at des.no Mon Nov 16 13:05:36 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 16 13:05:43 2009 Subject: bad source in the distro iso's In-Reply-To: <20091116125625.000058a7@unknown> (Bruce Cran's message of "Mon, 16 Nov 2009 12:56:25 +0000") References: <159670.52451.qm@web113214.mail.gq1.yahoo.com> <86lji6pzk3.fsf@ds4.des.no> <20091116125625.000058a7@unknown> Message-ID: <867htqoc0w.fsf@ds4.des.no> Bruce Cran writes: > See > http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052241.html > - apparently people are still wanting to install from floppies. The mind boggles. If you can't boot from CD-ROM, use a USB stick. If you can't boot from a USB stick, use PXE. If your NIC doesn't do PXE, you can get one that does for $20. If that is not an option either, move the disk to another machine, install, and move it back. If you really want to install 7.2 from floppies, you will need 76 disks just to get a bootable system. For 8.0, you will need 84. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Nov 16 13:08:46 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 16 13:08:52 2009 Subject: bad source in the distro iso's In-Reply-To: <867htqoc0w.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 16 Nov 2009 14:05:35 +0100") References: <159670.52451.qm@web113214.mail.gq1.yahoo.com> <86lji6pzk3.fsf@ds4.des.no> <20091116125625.000058a7@unknown> <867htqoc0w.fsf@ds4.des.no> Message-ID: <863a4eobvn.fsf@ds4.des.no> Dag-Erling Sm?rgrav writes: > If you really want to install 7.2 from floppies, you will need 76 disks > just to get a bootable system. For 8.0, you will need 84. That's for i386, btw. For amd64, the numbers are 83 for 7.2 and 93 for 8.0. DES -- Dag-Erling Sm?rgrav - des@des.no From julian at elischer.org Mon Nov 16 17:34:06 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Nov 16 17:34:14 2009 Subject: bad source in the distro iso's In-Reply-To: <867htqoc0w.fsf@ds4.des.no> References: <159670.52451.qm@web113214.mail.gq1.yahoo.com> <86lji6pzk3.fsf@ds4.des.no> <20091116125625.000058a7@unknown> <867htqoc0w.fsf@ds4.des.no> Message-ID: <4B018D0C.8060601@elischer.org> Dag-Erling Sm?rgrav wrote: > Bruce Cran writes: >> See >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052241.html >> - apparently people are still wanting to install from floppies. > > The mind boggles. > > If you can't boot from CD-ROM, use a USB stick. If you can't boot from > a USB stick, use PXE. If your NIC doesn't do PXE, you can get one that > does for $20. If that is not an option either, move the disk to another > machine, install, and move it back. > > If you really want to install 7.2 from floppies, you will need 76 disks > just to get a bootable system. For 8.0, you will need 84. > > DES I think the easiest answer would be: install 6.x or something, and upgrade. From volker at vwsoft.com Mon Nov 16 20:32:07 2009 From: volker at vwsoft.com (volker@vwsoft.com) Date: Mon Nov 16 20:32:28 2009 Subject: acl_from_text leaking memory In-Reply-To: References: Message-ID: <4B01B23F.8040002@vwsoft.com> On 01/-10/63 20:59, Jim Wilcoxson wrote: > I've been working on a new backup program, HashBackup, and believe I > have found a memory leak with ACLs in PCBSD/FreeBSD 7.1 and OSX > (Leopard). > > acl_from_text is a function that takes a text string as input, and > returns a pointer to a malloc'd acl. This acl is then freed with > acl_free. I noticed that acl_from_text appears to leak memory. This > is not used during the backup of a filesystem, but is needed to do a > restore. > > After looking at the acl_from_text source in /usr/src/lib/libc/posix1e > (from PCBSD7.1), I believe the problem is that the duplicate text > string, mybuf_p, is not freed on normal return of this function. Here > is the end of this function: > > } > > #if 0 > /* XXX Should we only return ACLs valid according to acl_valid? */ > /* Verify validity of the ACL we read in. */ > if (acl_valid(acl) == -1) { > errno = EINVAL; > goto error_label; > } > #endif > > return(acl); > > error_label: > acl_free(acl); > free(mybuf_p); > return(NULL); > } > > I think there should be a free(mybuf_p) before return(acl). > > Here is a PCBSD/FreeBSD test program that causes the memory leak: > > #include > #include > #include > > main() { > acl_t acl; > char* acltext; > > acltext = "user::rw-\n group::r--\n mask::r--\n other::r--\n"; > while (1) { > acl = acl_from_text(acltext); > if (acl == NULL) > printf("acl_from_text failed\n"); > if (acl_free(acl) != 0) > printf("acl_free failed\n"); > } > } > > I've subscribed to the lists for a few days in case there are > questions or I can help test something. > > Thanks, > Jim > -- > HashBackup beta: http://sites.google.com/site/hashbackup > Jim, you may want to have a look at the manpage acl_from_text(3): "...This function may cause memory to be allocated. The caller should free any releasable memory, when the new ACL is no longer required, by calling acl_free(3) with the (void *)acl_t as an argument." Please use an acl_free(void *obj_p) call afterwards to avoid leaking memory. Volker From gary.jennejohn at freenet.de Mon Nov 16 20:42:06 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Nov 16 20:42:12 2009 Subject: acl_from_text leaking memory In-Reply-To: <4B01B23F.8040002@vwsoft.com> References: <4B01B23F.8040002@vwsoft.com> Message-ID: <20091116214202.480a0aa7@ernst.jennejohn.org> On Mon, 16 Nov 2009 21:12:47 +0100 volker@vwsoft.com wrote: > you may want to have a look at the manpage acl_from_text(3): > > "...This function may cause memory to be allocated. The caller should > free any releasable memory, when the new ACL is no longer required, by > calling acl_free(3) with the (void *)acl_t as an argument." > > Please use an acl_free(void *obj_p) call afterwards to avoid leaking memory. > The suggested fix was appplied to HEAD today. Apparently, the man page should now be updated. --- Gary Jennejohn From prirun at gmail.com Mon Nov 16 21:21:02 2009 From: prirun at gmail.com (Jim Wilcoxson) Date: Mon Nov 16 21:21:23 2009 Subject: acl_from_text leaking memory In-Reply-To: <20091116214202.480a0aa7@ernst.jennejohn.org> References: <4B01B23F.8040002@vwsoft.com> <20091116214202.480a0aa7@ernst.jennejohn.org> Message-ID: The man page is correct and should not be changed. In the example program I submitted, it does call acl_free; this is not where the leak occurs. The leak occurs because of a temporary string that acl_from_text allocates to parse the text. Jim On 11/16/09, Gary Jennejohn wrote: > On Mon, 16 Nov 2009 21:12:47 +0100 > volker@vwsoft.com wrote: > >> you may want to have a look at the manpage acl_from_text(3): >> >> "...This function may cause memory to be allocated. The caller should >> free any releasable memory, when the new ACL is no longer required, by >> calling acl_free(3) with the (void *)acl_t as an argument." >> >> Please use an acl_free(void *obj_p) call afterwards to avoid leaking >> memory. >> > > The suggested fix was appplied to HEAD today. Apparently, the man page > should > now be updated. > > --- > Gary Jennejohn > From volker at vwsoft.com Mon Nov 16 22:01:30 2009 From: volker at vwsoft.com (volker@vwsoft.com) Date: Mon Nov 16 22:01:50 2009 Subject: acl_from_text leaking memory In-Reply-To: References: <4B01B23F.8040002@vwsoft.com> <20091116214202.480a0aa7@ernst.jennejohn.org> Message-ID: <4B01CBA7.8030308@vwsoft.com> On 11/16/09 22:21, Jim Wilcoxson wrote: > The man page is correct and should not be changed. > > In the example program I submitted, it does call acl_free; this is not > where the leak occurs. The leak occurs because of a temporary string > that acl_from_text allocates to parse the text. > > Jim > > On 11/16/09, Gary Jennejohn wrote: >> On Mon, 16 Nov 2009 21:12:47 +0100 >> volker@vwsoft.com wrote: >> >>> you may want to have a look at the manpage acl_from_text(3): >>> >>> "...This function may cause memory to be allocated. The caller should >>> free any releasable memory, when the new ACL is no longer required, by >>> calling acl_free(3) with the (void *)acl_t as an argument." >>> >>> Please use an acl_free(void *obj_p) call afterwards to avoid leaking >>> memory. >>> >> The suggested fix was appplied to HEAD today. Apparently, the man page >> should >> now be updated. >> >> --- >> Gary Jennejohn >> > Yes, I see and c199317 fixed that leak correctly. Jim is right - the manpage still should not be changed as the caller is still responsible for free'ing allocated memory. Volker From sharadc at in.niksun.com Tue Nov 17 10:20:23 2009 From: sharadc at in.niksun.com (Sharad Chandra) Date: Tue Nov 17 10:20:32 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. Message-ID: <200911171529.20098.sharadc@in.niksun.com> Hi, mportect clears the exec flag of whole page by which my program crashed. I am attaching sample code. It is performing below task 1) allocate memory1 2) allocate memory2 3) change permission of memory 1 and 2 to exec by mprotect. 4) clear the exec permission of memory 1 and free it. 5) execute the memory2 by mapping to pointer function. 6) clear the exec permission of memory 2 and free it. Program crashed at step 5 if memory 1 and 2 are in same page. $ uname -a FreeBSD app164.in.niksun.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 $ gcc -g -o test -Wall mprotect.c $ ./test mem1 at: 34369183888 mem2 at: 34369183892 address difference: 4 test_func1 function returned 0 test_func2 will crash here Segmentation fault (core dumped) Is it known bug or is there any workaround? How will a userland process make sure that process will not crash as malloc(3) can allocate where ever it get the memory free to use. -- Thanks, Sharad Chandra From kostikbel at gmail.com Tue Nov 17 12:29:00 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Nov 17 12:29:07 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. In-Reply-To: <200911171529.20098.sharadc@in.niksun.com> References: <200911171529.20098.sharadc@in.niksun.com> Message-ID: <20091117122854.GB2331@deviant.kiev.zoral.com.ua> On Tue, Nov 17, 2009 at 03:29:19PM +0530, Sharad Chandra wrote: > Hi, > > mportect clears the exec flag of whole page by which my program crashed. I am > attaching sample code. It is performing below task > > 1) allocate memory1 > 2) allocate memory2 > 3) change permission of memory 1 and 2 to exec by mprotect. > 4) clear the exec permission of memory 1 and free it. > 5) execute the memory2 by mapping to pointer function. > 6) clear the exec permission of memory 2 and free it. > > Program crashed at step 5 if memory 1 and 2 are in same page. > > $ uname -a > FreeBSD app164.in.niksun.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 > 07:18:07 UTC 2009 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > $ gcc -g -o test -Wall mprotect.c > $ ./test > mem1 at: 34369183888 > mem2 at: 34369183892 > address difference: 4 > test_func1 function returned 0 > test_func2 will crash here > Segmentation fault (core dumped) > > Is it known bug or is there any workaround? How will a userland process make > sure that process will not crash as malloc(3) can allocate where ever it get > the memory free to use. Attachment was stripped. Anyway, mprotect(2) works on the page granularity. The first sentence from the mprotect manpage says: The mprotect() system call changes the specified pages to have protection prot. By design, mprotect uses hardware capabilities of the processor' MMU to enforce the protection, and MMU works on the page granularity. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091117/70300224/attachment.pgp From aryeh.friedman at gmail.com Tue Nov 17 18:56:36 2009 From: aryeh.friedman at gmail.com (Aryeh Friedman) Date: Tue Nov 17 18:56:42 2009 Subject: unit testing automated password assignment Message-ID: I have a script that automatically creates a user and sets their password: echo $3 | sudo pw useradd $1 -m -c "$2" -s tcsh -h0 and by my employer's policy I need to unit test... my question is how... the checking for user existence and such is easy but how do I test that the password is correct? From spawk at acm.poly.edu Tue Nov 17 19:30:31 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Tue Nov 17 19:30:38 2009 Subject: unit testing automated password assignment In-Reply-To: References: Message-ID: <4B02F99E.2030205@acm.poly.edu> Aryeh Friedman wrote: > I have a script that automatically creates a user and sets their password: > > echo $3 | sudo pw useradd $1 -m -c "$2" -s tcsh -h0 > > and by my employer's policy I need to unit test... my question is > how... the checking for user existence and such is easy but how do I > test that the password is correct? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Have a look at http://cr.yp.to/checkpwd.html. A FreeBSD port is available in security/checkpassword. -Boris From uqs at spoerlein.net Wed Nov 18 10:18:29 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Wed Nov 18 10:18:36 2009 Subject: how to build libthr except other components of 'world' In-Reply-To: <900874.43629.qm@web15707.mail.cnb.yahoo.com> References: <900874.43629.qm@web15707.mail.cnb.yahoo.com> Message-ID: <20091118101827.GJ20980@acme.spoerlein.net> On Mon, 16.11.2009 at 20:28:35 +0800, Jiandong Lu wrote: > > > --- 09?11?16????, Jiandong Lu ??? > > ???: Jiandong Lu > ??: how to build libthr except other components of 'world' > ???: freebsd-threads@freebsd.org > ??: 2009?11?16?,??,??6:48 > > Hi,everyone, > ??? I checkout FreeBSD?s source codes to my /usr/src > ??? I use command > ??? make buildworld > ??? int directory /usr/src to build a world.I want to do some debug to lib /usr/src/lib/libthr.If I modified some files in /usr/src/lib/libthr/thread, how could I build libthr except other components of world? > ?? btw,I execute command > ?? make > ?? in /usr/src/lib/libthr get this : > cc -O2 -fno-strict-aliasing -pipe? -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread? -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db > -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/arch/i386/i386/pthread_md.c > In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:33: > /usr/src/lib/libthr/../../include/string.h:86: warning: no previous prototype for 'strdup' I have no strdup calls anywhere in libthr. If you have added this call, you need to make sure the right headers are included. Otherwise, this can be used to build only libthr and works fine on my system: cd /usr/src/lib/libthr make obj && make depend make Regards, Uli From lars.engels at 0x20.net Wed Nov 18 12:29:48 2009 From: lars.engels at 0x20.net (Lars Engels) Date: Wed Nov 18 12:45:19 2009 Subject: unit testing automated password assignment In-Reply-To: <4B02F99E.2030205@acm.poly.edu> References: <4B02F99E.2030205@acm.poly.edu> Message-ID: <20091118132946.w7k3l8bm8c4gkook@0x20.net> Quoting Boris Kochergin : > Aryeh Friedman wrote: >> I have a script that automatically creates a user and sets their password: >> >> echo $3 | sudo pw useradd $1 -m -c "$2" -s tcsh -h0 >> >> and by my employer's policy I need to unit test... my question is >> how... the checking for user existence and such is easy but how do I >> test that the password is correct? And if you want to enforce strong passwords, take a look at pam_passwdqc(8). -- Lars Engels E-Mail: lars.engels@0x20.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: PGP Digital Signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091118/8b7c8d1d/attachment.pgp From des at des.no Wed Nov 18 12:48:15 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 18 12:48:22 2009 Subject: unit testing automated password assignment In-Reply-To: <20091118132946.w7k3l8bm8c4gkook@0x20.net> (Lars Engels's message of "Wed, 18 Nov 2009 13:29:46 +0100") References: <4B02F99E.2030205@acm.poly.edu> <20091118132946.w7k3l8bm8c4gkook@0x20.net> Message-ID: <86fx8cuhgy.fsf@ds4.des.no> Lars Engels writes: > And if you want to enforce strong passwords, take a look at pam_passwdqc(8). Or don't, it's waaay out of date. I should import a newer version, just never got around to it. Patches are welcome. DES -- Dag-Erling Sm?rgrav - des@des.no From lars.engels at 0x20.net Wed Nov 18 15:02:22 2009 From: lars.engels at 0x20.net (Lars Engels) Date: Wed Nov 18 16:34:26 2009 Subject: unit testing automated password assignment In-Reply-To: <86fx8cuhgy.fsf@ds4.des.no> References: <4B02F99E.2030205@acm.poly.edu> <20091118132946.w7k3l8bm8c4gkook@0x20.net> <86fx8cuhgy.fsf@ds4.des.no> Message-ID: <20091118160221.r4ofxiculcgo0gcc@0x20.net> Quoting Dag-Erling Sm?rgrav : > Lars Engels writes: >> And if you want to enforce strong passwords, take a look at pam_passwdqc(8). > > Or don't, it's waaay out of date. I should import a newer version, just > never got around to it. Patches are welcome. Yes, today I was looking for the sources to use on Solaris and I saw that there was some activity in during the last months. OTOH the module in our base is still working. I successfully it last week. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: PGP Digital Signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091118/64a66695/attachment.pgp From rwatson at FreeBSD.org Wed Nov 18 18:52:02 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Nov 18 18:52:09 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. In-Reply-To: <200911171529.20098.sharadc@in.niksun.com> References: <200911171529.20098.sharadc@in.niksun.com> Message-ID: On Tue, 17 Nov 2009, Sharad Chandra wrote: > Is it known bug or is there any workaround? How will a userland process make > sure that process will not crash as malloc(3) can allocate where ever it get > the memory free to use. mprotect(2) operates on pages, so you'll want to use mmap(2) and munmap(2) to allocate and free pages directly rather than mallac(3), which manages byte ranges from pages managed using those same interfaces. Robert N M Watson Computer Laboratory University of Cambridge From jkim at FreeBSD.org Wed Nov 18 19:34:03 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Nov 18 19:34:09 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. In-Reply-To: References: <200911171529.20098.sharadc@in.niksun.com> Message-ID: <200911181433.52557.jkim@FreeBSD.org> On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote: > On Tue, 17 Nov 2009, Sharad Chandra wrote: > > Is it known bug or is there any workaround? How will a userland > > process make sure that process will not crash as malloc(3) can > > allocate where ever it get the memory free to use. > > mprotect(2) operates on pages, so you'll want to use mmap(2) and > munmap(2) to allocate and free pages directly rather than > mallac(3), which manages byte ranges from pages managed using those > same interfaces. For example: http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471 Jung-uk Kim From xorquewasp at googlemail.com Thu Nov 19 06:57:46 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Thu Nov 19 06:57:52 2009 Subject: Wine on amd64 in 32 bit jail Message-ID: <20091119065742.GA28159@logik.internal.network> Hello. I've done a lot of reading on this problem and don't understand why what I have doesn't work. http://wiki.freebsd.org/Wine I have an entirely 32 bit jail, created by cross-compiling the world with TARGET=i386 and creating a jail from DESTDIR. The jail appears to be fully functional - all programs appear to work and the compiler produces i386 binaries. 'uname' has been configured to identify itself as 'i386', so even compiling programs from source works (autoconf correctly recognises the jail system as i386, etc). However, installing the wine port and attempting to do anything with it results in: $ wine hello.exe Bus error: 10 (core dumped) The program will immediately crash in all cases. $ winecfg Bus error: 10 (core dumped) According to every bit of documentation I can find online, this should work fine. Any idea what's gone wrong here? xw From julian at elischer.org Thu Nov 19 07:19:15 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 19 07:19:22 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119065742.GA28159@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network> Message-ID: <4B04F172.7070803@elischer.org> xorquewasp@googlemail.com wrote: > Hello. > > I've done a lot of reading on this problem and don't understand why what I have > doesn't work. > > http://wiki.freebsd.org/Wine > > I have an entirely 32 bit jail, created by cross-compiling the world with > TARGET=i386 and creating a jail from DESTDIR. > > The jail appears to be fully functional - all programs appear to work and > the compiler produces i386 binaries. > > 'uname' has been configured to identify itself as 'i386', so even compiling > programs from source works (autoconf correctly recognises the jail system > as i386, etc). > > However, installing the wine port and attempting to do anything with it > results in: > > $ wine hello.exe > Bus error: 10 (core dumped) > > The program will immediately crash in all cases. > > $ winecfg > Bus error: 10 (core dumped) > > According to every bit of documentation I can find online, this should > work fine. Any idea what's gone wrong here? Wine is an exceptional bit of software, in many ways. One way it is exceptional is that it uses the system in a number of ways that nothing else does. For example it sets various special segment register settings and defines several different segments on the LDT. This is something that is different to some extent between i386 and amd64 and it is possible that the code for 386 LDT syscalls under amd64 may not work correctly. nothing else would test this. > > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From xorquewasp at googlemail.com Thu Nov 19 07:38:22 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Thu Nov 19 07:38:29 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <4B04F172.7070803@elischer.org> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> Message-ID: <20091119073818.GA81272@logik.internal.network> On 2009-11-18 23:19:14, Julian Elischer wrote: > > Wine is an exceptional bit of software, in many ways. > One way it is exceptional is that it uses the system in a number of > ways that nothing else does. For example it sets various special > segment register settings and defines several different > segments on the LDT. This is something that is different to some > extent between i386 and amd64 and it is possible that > the code for 386 LDT syscalls under amd64 may not work correctly. > nothing else would test this. > I agree and would also have likely not even tried if it wasn't for reading on FreeBSD's own wiki (amonst other places) that it should actually work fine. I've tried various versions and always get the same result: http://wiki.freebsd.org/Wine "FreeBSD currently lacks support for 32bit ports on a 64bit system. However, with a little bit of effort you can build and use the 32 bit wine executable on an amd64 system (Diablo 2 works just fine)." His instructions show an essentially identical setup to mine (apart from the fact that he's running a chroot and I'm running a jail). Even any ideas on how to debug this would help. xw From kostikbel at gmail.com Thu Nov 19 09:05:10 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 19 09:05:16 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119073818.GA81272@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> Message-ID: <20091119090340.GY2331@deviant.kiev.zoral.com.ua> On Thu, Nov 19, 2009 at 07:38:18AM +0000, xorquewasp@googlemail.com wrote: > On 2009-11-18 23:19:14, Julian Elischer wrote: > > > > Wine is an exceptional bit of software, in many ways. > > One way it is exceptional is that it uses the system in a number of > > ways that nothing else does. For example it sets various special > > segment register settings and defines several different > > segments on the LDT. This is something that is different to some > > extent between i386 and amd64 and it is possible that > > the code for 386 LDT syscalls under amd64 may not work correctly. > > nothing else would test this. > > > > I agree and would also have likely not even tried if it wasn't for > reading on FreeBSD's own wiki (amonst other places) that it should > actually work fine. I've tried various versions and always get the > same result: > > http://wiki.freebsd.org/Wine > > "FreeBSD currently lacks support for 32bit ports on a 64bit system. > However, with a little bit of effort you can build and use the 32 bit > wine executable on an amd64 system (Diablo 2 works just fine)." > > His instructions show an essentially identical setup to mine (apart > from the fact that he's running a chroot and I'm running a jail). > > Even any ideas on how to debug this would help. You forgot to note the version of the kernel you use. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091119/8022f7cf/attachment.pgp From xorquewasp at googlemail.com Thu Nov 19 09:22:18 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Thu Nov 19 09:22:25 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119090340.GY2331@deviant.kiev.zoral.com.ua> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <20091119090340.GY2331@deviant.kiev.zoral.com.ua> Message-ID: <20091119092214.GA53950@logik.internal.network> On 2009-11-19 11:03:41, Kostik Belousov wrote: > > You forgot to note the version of the kernel you use. I'm using 7.2-RELEASE-p4 here. xw From kostikbel at gmail.com Thu Nov 19 09:27:03 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 19 09:27:09 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119092214.GA53950@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <20091119090340.GY2331@deviant.kiev.zoral.com.ua> <20091119092214.GA53950@logik.internal.network> Message-ID: <20091119092548.GZ2331@deviant.kiev.zoral.com.ua> On Thu, Nov 19, 2009 at 09:22:14AM +0000, xorquewasp@googlemail.com wrote: > On 2009-11-19 11:03:41, Kostik Belousov wrote: > > > > You forgot to note the version of the kernel you use. > > I'm using 7.2-RELEASE-p4 here. Required syscalls only implemented in 8/HEAD. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091119/5371091d/attachment.pgp From xorquewasp at googlemail.com Thu Nov 19 09:36:58 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Thu Nov 19 09:37:05 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119092548.GZ2331@deviant.kiev.zoral.com.ua> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <20091119090340.GY2331@deviant.kiev.zoral.com.ua> <20091119092214.GA53950@logik.internal.network> <20091119092548.GZ2331@deviant.kiev.zoral.com.ua> Message-ID: <20091119093654.GA30714@logik.internal.network> On 2009-11-19 11:25:48, Kostik Belousov wrote: > > I'm using 7.2-RELEASE-p4 here. > > Required syscalls only implemented in 8/HEAD. Ah, thanks. I assume they won't have made it into 8.0-RELEASE when it shows up? xw From matthias.andree at gmx.de Thu Nov 19 09:54:24 2009 From: matthias.andree at gmx.de (Matthias Andree) Date: Thu Nov 19 09:54:31 2009 Subject: header file bug sys/types.h sys/file.h vs. _XOPEN_SOURCE standard Message-ID: Greetings, this little C program (which is actual a minimum excerpt from sysutils/e2fsprogs) fails to compile on - among others - 8.0-PRERELEASE: $ cat fail.c #define _XOPEN_SOURCE 600 #include $ gcc -W -Wall -O -c fail.c In file included from fail.c:2: /usr/include/sys/file.h:161: error: expected specifier-qualifier-list before 'u_int' I can get the code to compile by removing the "#define _XOPEN_SOURCE 600". This happens here: 146 /* 147 * Userland version of struct file, for sysctl 148 */ 149 struct xfile { 150 size_t xf_size; /* size of struct xfile */ 151 pid_t xf_pid; /* owning process */ 152 uid_t xf_uid; /* effective uid of owning process */ 153 int xf_fd; /* descriptor number */ 154 void *xf_file; /* address of struct file */ 155 short xf_type; /* descriptor type */ 156 int xf_count; /* reference count */ 157 int xf_msgcount; /* references from message queue */ 158 off_t xf_offset; /* file offset */ 159 void *xf_data; /* file descriptor specific data */ 160 void *xf_vnode; /* vnode pointer */ !! 161 u_int xf_flag; /* flags (see fcntl.h) */ 162 }; The flow here is as follows: 1. sys/file.h (non-standard header) includes sys/types.h (POSIX/XSI standard header) and implictly sys/cdefs.h 2. since _XOPEN_SOURCE is defined, nonstandard symbols such as u_int aren't defined by the standard headers (this is in line with IEEE Std 1003.1-2008) 3. sys/file.h uses this non-standard and undefined u_int and breaks. I've talked to Theodore Y. Ts'o, who is the sysutils/e2fsprogs upstream maintainer and proposed to remove the _XOPEN_SOURCE definition (my idea was that the code shouldn't be claiming standards compliance while it uses non-standard headers), but he refused that (since it would break the e2fsprogs build on Solaris). Should non-standard system headers break if an application defines one of the standard feature test macros? Or could sys/file.h be changed (for instance by replacing u_int by unsigned int) to tolerate POSIX and XSI feature test macros? TIA. Cheers -- Matthias Andree mandree freebsd org From kostikbel at gmail.com Thu Nov 19 10:16:10 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 19 10:16:16 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119093654.GA30714@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <20091119090340.GY2331@deviant.kiev.zoral.com.ua> <20091119092214.GA53950@logik.internal.network> <20091119092548.GZ2331@deviant.kiev.zoral.com.ua> <20091119093654.GA30714@logik.internal.network> Message-ID: <20091119101518.GA2331@deviant.kiev.zoral.com.ua> On Thu, Nov 19, 2009 at 09:36:54AM +0000, xorquewasp@googlemail.com wrote: > On 2009-11-19 11:25:48, Kostik Belousov wrote: > > > I'm using 7.2-RELEASE-p4 here. > > > > Required syscalls only implemented in 8/HEAD. > > Ah, thanks. > > I assume they won't have made it into 8.0-RELEASE when it shows up? It is in 8.0. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091119/e1b18f93/attachment.pgp From xorquewasp at googlemail.com Thu Nov 19 10:23:13 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Thu Nov 19 10:23:19 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119101518.GA2331@deviant.kiev.zoral.com.ua> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <20091119090340.GY2331@deviant.kiev.zoral.com.ua> <20091119092214.GA53950@logik.internal.network> <20091119092548.GZ2331@deviant.kiev.zoral.com.ua> <20091119093654.GA30714@logik.internal.network> <20091119101518.GA2331@deviant.kiev.zoral.com.ua> Message-ID: <20091119102309.GB30714@logik.internal.network> On 2009-11-19 12:15:18, Kostik Belousov wrote: > On Thu, Nov 19, 2009 at 09:36:54AM +0000, xorquewasp@googlemail.com wrote: > > It is in 8.0. Excellent, thanks. From koffieyahoo at gmail.com Thu Nov 19 10:46:15 2009 From: koffieyahoo at gmail.com (Koffie Yahoo) Date: Thu Nov 19 10:46:22 2009 Subject: Getting running time of child Message-ID: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> Dear all, I've looked but not found (and I hope I'm in the right group here): Is there a way to get the user time and system time of a /running/ child from its parent (without having to mount procfs)? As far as I was able to tell, I can get the total of user and system time using kvm_getprocs, but it doesn't seem possible to get both values separately. Regards, Jay From sharadc at in.niksun.com Thu Nov 19 10:59:15 2009 From: sharadc at in.niksun.com (Sharad Chandra) Date: Thu Nov 19 10:59:22 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. In-Reply-To: <200911181433.52557.jkim@FreeBSD.org> References: <200911171529.20098.sharadc@in.niksun.com> <200911181433.52557.jkim@FreeBSD.org> Message-ID: <200911191627.34076.sharadc@in.niksun.com> ,---- [Jung-uk Kim wrote:] | On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote: | > On Tue, 17 Nov 2009, Sharad Chandra wrote: | > > Is it known bug or is there any workaround? How will a userland | > > process make sure that process will not crash as malloc(3) can | > > allocate where ever it get the memory free to use. | > | > mprotect(2) operates on pages, so you'll want to use mmap(2) and | > munmap(2) to allocate and free pages directly rather than | > mallac(3), which manages byte ranges from pages managed using those | > same interfaces. | | For example: | | http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471 | Thanks everyone. mmap(2) worked and program did not crash. Only problem with it I use only fraction of allocated memory (each request alocate minimum of one page and my request is in hundreds), rest is waste of it so no one else will get this memory to use. And if a process runs as daemon and makes many request, It can hold a lot of it. Just a question floated in mind. Many thanks, Sharad Chandra From rwatson at freebsd.org Thu Nov 19 11:42:35 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Thu Nov 19 11:42:41 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. In-Reply-To: <200911191627.34076.sharadc@in.niksun.com> References: <200911171529.20098.sharadc@in.niksun.com> <200911181433.52557.jkim@FreeBSD.org> <200911191627.34076.sharadc@in.niksun.com> Message-ID: <80FAFE47-C19C-4666-A279-6AF6DA8B6127@freebsd.org> On 19 Nov 2009, at 10:57, Sharad Chandra wrote: > Thanks everyone. mmap(2) worked and program did not crash. Only problem with > it I use only fraction of allocated memory (each request alocate minimum of > one page and my request is in hundreds), rest is waste of it so no one else > will get this memory to use. And if a process runs as daemon and makes many > request, It can hold a lot of it. Just a question floated in mind. One of the defining properties of pages is that they are the granularity at which access protections are controlled in hardware, so your choices are a minimum of one page per object, or having multiple objects that share the same protection properties. However, it could be that you could accomplish whatever your goals may be using techniques other than paging; for example, using ptrace(2) to instrument individual accesses, binary rewriting, a virtual machine, source code instrumentation, or other methods along those lines that have been used for debugging and security over the years. Robert From des at des.no Thu Nov 19 13:25:12 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 19 13:25:18 2009 Subject: header file bug sys/types.h sys/file.h vs. _XOPEN_SOURCE standard In-Reply-To: (Matthias Andree's message of "Thu, 19 Nov 2009 10:27:41 +0100") References: Message-ID: <86skca6409.fsf@ds4.des.no> "Matthias Andree" writes: > I've talked to Theodore Y. Ts'o, who is the sysutils/e2fsprogs > upstream maintainer and proposed to remove the _XOPEN_SOURCE > definition (my idea was that the code shouldn't be claiming standards > compliance while it uses non-standard headers), but he refused that > (since it would break the e2fsprogs build on Solaris). He's right. You misunderstand _XOPEN_SOURCE; it does not mean "my program complies with X/Open blah", it means "my program requires the facilities provided by X/Open blah". The problem lies in FreeBSD's headers, which don't implement namespace separation correctly. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Thu Nov 19 13:27:12 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 19 13:27:19 2009 Subject: Getting running time of child In-Reply-To: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> (Koffie Yahoo's message of "Thu, 19 Nov 2009 11:14:47 +0100") References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> Message-ID: <86ocmy63ww.fsf@ds4.des.no> Koffie Yahoo writes: > I've looked but not found (and I hope I'm in the right group here): Is > there a way to get the user time and system time of a /running/ child > from its parent (without having to mount procfs)? If you have only one child, there's getrusage(2). DES -- Dag-Erling Sm?rgrav - des@des.no From julian at elischer.org Thu Nov 19 14:27:19 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 19 14:27:27 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119073818.GA81272@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> Message-ID: <4B0555C6.8020105@elischer.org> xorquewasp@googlemail.com wrote: > On 2009-11-18 23:19:14, Julian Elischer wrote: >> Wine is an exceptional bit of software, in many ways. >> One way it is exceptional is that it uses the system in a number of >> ways that nothing else does. For example it sets various special >> segment register settings and defines several different >> segments on the LDT. This is something that is different to some >> extent between i386 and amd64 and it is possible that >> the code for 386 LDT syscalls under amd64 may not work correctly. >> nothing else would test this. >> > > I agree and would also have likely not even tried if it wasn't for > reading on FreeBSD's own wiki (amonst other places) that it should > actually work fine. I've tried various versions and always get the > same result: > > http://wiki.freebsd.org/Wine > > "FreeBSD currently lacks support for 32bit ports on a 64bit system. > However, with a little bit of effort you can build and use the 32 bit > wine executable on an amd64 system (Diablo 2 works just fine)." > > His instructions show an essentially identical setup to mine (apart > from the fact that he's running a chroot and I'm running a jail). jail may not alow you to do the LDT system calls. have you tried a chroot? > > Even any ideas on how to debug this would help. > > xw From julian at elischer.org Thu Nov 19 14:32:28 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 19 14:32:34 2009 Subject: mprotect(2) clears the flag for whole page which causes program crash. In-Reply-To: <200911191627.34076.sharadc@in.niksun.com> References: <200911171529.20098.sharadc@in.niksun.com> <200911181433.52557.jkim@FreeBSD.org> <200911191627.34076.sharadc@in.niksun.com> Message-ID: <4B0556FA.1080709@elischer.org> Sharad Chandra wrote: > ,---- [Jung-uk Kim wrote:] > | On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote: > | > On Tue, 17 Nov 2009, Sharad Chandra wrote: > | > > Is it known bug or is there any workaround? How will a userland > | > > process make sure that process will not crash as malloc(3) can > | > > allocate where ever it get the memory free to use. > | > > | > mprotect(2) operates on pages, so you'll want to use mmap(2) and > | > munmap(2) to allocate and free pages directly rather than > | > mallac(3), which manages byte ranges from pages managed using those > | > same interfaces. > | > | For example: > | > | http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471 > | > > Thanks everyone. mmap(2) worked and program did not crash. Only problem with > it I use only fraction of allocated memory (each request alocate minimum of > one page and my request is in hundreds), rest is waste of it so no one else > will get this memory to use. And if a process runs as daemon and makes many > request, It can hold a lot of it. Just a question floated in mind. write your own allocator that efficiently divides up the mmapped pages among several requests? > > Many thanks, > Sharad Chandra > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From kostikbel at gmail.com Thu Nov 19 14:33:07 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 19 14:33:22 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <4B0555C6.8020105@elischer.org> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <4B0555C6.8020105@elischer.org> Message-ID: <20091119143259.GC2331@deviant.kiev.zoral.com.ua> On Thu, Nov 19, 2009 at 06:27:18AM -0800, Julian Elischer wrote: > xorquewasp@googlemail.com wrote: > >On 2009-11-18 23:19:14, Julian Elischer wrote: > >>Wine is an exceptional bit of software, in many ways. > >>One way it is exceptional is that it uses the system in a number of > >>ways that nothing else does. For example it sets various special > >>segment register settings and defines several different > >>segments on the LDT. This is something that is different to some > >>extent between i386 and amd64 and it is possible that > >>the code for 386 LDT syscalls under amd64 may not work correctly. > >>nothing else would test this. > >> > > > >I agree and would also have likely not even tried if it wasn't for > >reading on FreeBSD's own wiki (amonst other places) that it should > >actually work fine. I've tried various versions and always get the > >same result: > > > > http://wiki.freebsd.org/Wine > > > > "FreeBSD currently lacks support for 32bit ports on a 64bit system. > > However, with a little bit of effort you can build and use the 32 bit > > wine executable on an amd64 system (Diablo 2 works just fine)." > > > >His instructions show an essentially identical setup to mine (apart > >from the fact that he's running a chroot and I'm running a jail). > > jail may not alow you to do the LDT system calls. There are no restrictions for the sysarch(I386_GET/SET_LDT), neither for root-only, nor for inside the jail. > > have you tried a chroot? > > > > >Even any ideas on how to debug this would help. > > > >xw > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091119/cb37eb91/attachment.pgp From koffieyahoo at gmail.com Thu Nov 19 14:52:33 2009 From: koffieyahoo at gmail.com (Koffie Yahoo) Date: Thu Nov 19 14:52:40 2009 Subject: Getting running time of child In-Reply-To: <86ocmy63ww.fsf@ds4.des.no> References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> Message-ID: <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> >> I've looked but not found (and I hope I'm in the right group here): Is >> there a way to get the user time and system time of a /running/ child >> from its parent (without having to mount procfs)? > > If you have only one child, there's getrusage(2). Unfortunately, that only works for children that have terminated, not for active children. I'm interested in active children. Jay From des at des.no Thu Nov 19 15:07:52 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 19 15:08:04 2009 Subject: Getting running time of child In-Reply-To: <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> (Koffie Yahoo's message of "Thu, 19 Nov 2009 15:52:27 +0100") References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> Message-ID: <86r5ru3649.fsf@ds4.des.no> Koffie Yahoo writes: > Unfortunately, that only works for children that have terminated, not > for active children. I'm interested in active children. Hmm, we could probably add a ptrace(2) operation, but ptrace(2) is inherently evil. DES -- Dag-Erling Sm?rgrav - des@des.no From spawk at acm.poly.edu Thu Nov 19 15:12:54 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Thu Nov 19 15:13:01 2009 Subject: Getting running time of child In-Reply-To: <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> Message-ID: <4B056039.4040802@acm.poly.edu> Koffie Yahoo wrote: >>> I've looked but not found (and I hope I'm in the right group here): Is >>> there a way to get the user time and system time of a /running/ child >>> from its parent (without having to mount procfs)? >>> >> If you have only one child, there's getrusage(2). >> > > Unfortunately, that only works for children that have terminated, not > for active children. I'm interested in active children. > > Jay > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > It's not as portable as getrusage(2), but you could probably get the information you want using libkvm's kvm_getprocs(3) function. The information available is defined in the kinfo_proc structure in /usr/include/sys/user.h. -Boris From des at des.no Thu Nov 19 15:20:15 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 19 15:20:22 2009 Subject: Getting running time of child In-Reply-To: <4B056039.4040802@acm.poly.edu> (Boris Kochergin's message of "Thu, 19 Nov 2009 10:11:53 -0500") References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> <4B056039.4040802@acm.poly.edu> Message-ID: <86einu35jl.fsf@ds4.des.no> Boris Kochergin writes: > It's not as portable as getrusage(2), but you could probably get the > information you want using libkvm's kvm_getprocs(3) function. The > information available is defined in the kinfo_proc structure in > /usr/include/sys/user.h. Read the original post. DES -- Dag-Erling Sm?rgrav - des@des.no From koffieyahoo at gmail.com Thu Nov 19 15:23:28 2009 From: koffieyahoo at gmail.com (Koffie Yahoo) Date: Thu Nov 19 15:23:34 2009 Subject: Getting running time of child In-Reply-To: <4B056039.4040802@acm.poly.edu> References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> <4B056039.4040802@acm.poly.edu> Message-ID: <9cb658f10911190715p404da03er9446b5dc5c31cb78@mail.gmail.com> > It's not as portable as getrusage(2), but you could probably get the > information you want using libkvm's kvm_getprocs(3) function. The > information available is defined in the kinfo_proc structure in > /usr/include/sys/user.h. Unfortunately, as far as I can see the kinfo_proc structure only contains the sum of user time and system time and not the two values separately, or have I missed something? Jay From guy.helmer at gmail.com Thu Nov 19 15:09:03 2009 From: guy.helmer at gmail.com (Guy Helmer) Date: Thu Nov 19 16:07:36 2009 Subject: Self-encrypting hard drives Message-ID: <96c81adf0911190648x7a0ba6aeode654a89e1003e27@mail.gmail.com> I'm looking into using self-encrypting hard drives (TCG Opal standard) with FreeBSD. In particular I want to use the auto-lock mode. I can't seem to find the details regarding how the authentication key is provided to the drive, and where there is any support in FreeBSD to enable unlocking the drive for use. Any pointers would be appreciated. Thanks, Guy From dnelson at allantgroup.com Thu Nov 19 16:53:38 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Thu Nov 19 16:53:45 2009 Subject: Getting running time of child In-Reply-To: <9cb658f10911190715p404da03er9446b5dc5c31cb78@mail.gmail.com> References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> <4B056039.4040802@acm.poly.edu> <9cb658f10911190715p404da03er9446b5dc5c31cb78@mail.gmail.com> Message-ID: <20091119163437.GE89004@dan.emsphone.com> In the last episode (Nov 19), Koffie Yahoo said: > > It's not as portable as getrusage(2), but you could probably get the > > information you want using libkvm's kvm_getprocs(3) function. The > > information available is defined in the kinfo_proc structure in > > /usr/include/sys/user.h. > > Unfortunately, as far as I can see the kinfo_proc structure only contains > the sum of user time and system time and not the two values separately, > or have I missed something? Take a look at the the ki_rusage struct inside kinfo_proc. -- Dan Nelson dnelson@allantgroup.com From koffieyahoo at gmail.com Thu Nov 19 20:15:37 2009 From: koffieyahoo at gmail.com (Koffie Yahoo) Date: Thu Nov 19 20:15:43 2009 Subject: Getting running time of child In-Reply-To: <20091119163437.GE89004@dan.emsphone.com> References: <9cb658f10911190214j5a6bc17fq200a82ea0b4acaa8@mail.gmail.com> <86ocmy63ww.fsf@ds4.des.no> <9cb658f10911190652j555e4484u2427d2bed87871f8@mail.gmail.com> <4B056039.4040802@acm.poly.edu> <9cb658f10911190715p404da03er9446b5dc5c31cb78@mail.gmail.com> <20091119163437.GE89004@dan.emsphone.com> Message-ID: <9cb658f10911191215w783c6406j5aca01ba92e6ad4d@mail.gmail.com> That's it! Thanks! Problem solved :-) Jay On Thu, Nov 19, 2009 at 5:34 PM, Dan Nelson wrote: > In the last episode (Nov 19), Koffie Yahoo said: >> > It's not as portable as getrusage(2), but you could probably get the >> > information you want using libkvm's kvm_getprocs(3) function. The >> > information available is defined in the kinfo_proc structure in >> > /usr/include/sys/user.h. >> >> Unfortunately, as far as I can see the kinfo_proc structure only contains >> the sum of user time and system time and not the two values separately, >> or have I missed something? > > Take a look at the the ki_rusage struct inside kinfo_proc. > > -- > ? ? ? ?Dan Nelson > ? ? ? ?dnelson@allantgroup.com > From sfourman at gmail.com Thu Nov 19 23:12:21 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Nov 19 23:12:32 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091119065742.GA28159@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network> Message-ID: <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> On Thu, Nov 19, 2009 at 12:57 AM, wrote: > Hello. > > I've done a lot of reading on this problem and don't understand why what I have > doesn't work. > > ?http://wiki.freebsd.org/Wine > > I have an entirely 32 bit jail, created by cross-compiling the world with > TARGET=i386 and creating a jail from DESTDIR. > > The jail appears to be fully functional - all programs appear to work and > the compiler produces i386 binaries. > > 'uname' has been configured to identify itself as 'i386', so even compiling > programs from source works (autoconf correctly recognises the jail system > as i386, etc). I would like to help get this working.. is there a howto somewhere to setup a i386 jail on amd64? I used teh instructions on http://wiki.freebsd.org/Wine (and pointed the jail to /compat/i386) Inside teh jail uname -a still produces this: FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18 22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64 so trying to compile mesa-demos produces this /../../src/mesa/x86-64/glapi_x86-64.S:29003: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29004: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29005: Error: `6128(%rax)' is not a valid 32 bit base/index expression ../../../src/mesa/x86-64/glapi_x86-64.S:29006: Error: bad register name `%r11' ../../../src/mesa/x86-64/glapi_x86-64.S:29040: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29041: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29042: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29043: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29044: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29046: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29047: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29048: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29049: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29050: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29051: Error: `6136(%rax)' is not a valid 32 bit base/index expression ../../../src/mesa/x86-64/glapi_x86-64.S:29052: Error: bad register name `%r11' ../../../src/mesa/x86-64/glapi_x86-64.S:29086: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29087: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29088: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29090: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29091: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29092: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29093: Error: `6144(%rax)' is not a valid 32 bit base/index expression ../../../src/mesa/x86-64/glapi_x86-64.S:29094: Error: bad register name `%r11' ../../../src/mesa/x86-64/glapi_x86-64.S:29124: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29125: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29126: Error: suffix or operands invalid for `push' ../../../src/mesa/x86-64/glapi_x86-64.S:29128: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29129: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29130: Error: suffix or operands invalid for `pop' ../../../src/mesa/x86-64/glapi_x86-64.S:29131: Error: `6152(%rax)' is not a valid 32 bit base/index expression ../../../src/mesa/x86-64/glapi_x86-64.S:29132: Error: bad register name `%r11' gmake[2]: *** [../../../src/mesa/x86-64/glapi_x86-64.o] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/mesa-demos/work/Mesa-7.4.4/src/glx/x11' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/mesa-demos/work/Mesa-7.4.4/src' gmake: *** [default] Error 1 *** Error code 1 Sam Fourman Jr. From xorquewasp at googlemail.com Fri Nov 20 03:30:01 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Nov 20 03:30:08 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> References: <20091119065742.GA28159@logik.internal.network> <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> Message-ID: <20091120032955.GA27847@logik.internal.network> On 2009-11-19 17:12:19, Sam Fourman Jr. wrote: > > I would like to help get this working.. is there a howto somewhere to > setup a i386 jail on amd64? > I used teh instructions on http://wiki.freebsd.org/Wine (and pointed > the jail to /compat/i386) > Inside teh jail uname -a still produces this: > FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18 > 22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64 Hello. Not sure about the mesa problem at the moment, but I made uname identify itself as i386 by just setting UNAME_m=i386 in the environment. You could put this in the shell environment of the user you run as inside the jail. xw From gatinhodosseussonhos at hotmail.com Fri Nov 20 13:43:19 2009 From: gatinhodosseussonhos at hotmail.com (Fulano Tal) Date: Fri Nov 20 13:43:26 2009 Subject: Wine on amd64 in 32 bit jail - for stupid peaple only In-Reply-To: <20091120032955.GA27847@logik.internal.network> References: <20091119065742.GA28159@logik.internal.network>, <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com>, <20091120032955.GA27847@logik.internal.network> Message-ID: Use IPMI to read architecture information is easy, but a nice ploy is to sed-out i386 and amd64 related #ifdefs, and have nightmares with chains... sorry, I mean You will have a bi-archtecture system after some work with a cool new personalized tables compatible with 32 and 64 images. You will have the honorable scout's ribbon of scratch a file system in your chest after stark in short, something like an homunculus with AB positive blood type. good luck. ps.: Do I waste time sending replies that maybe will not help anybody, with idiot thoughs like: "hey guys, what about we taylor an prototype of an a.i. managed not human operating system, that is not so simple to be handled by any simple person except for a few seconds at every century by prodigy minds more exceptional than any existing mythological wisdom, and without any crt and hack objects or strange acpi boring dependencies that nobody want to explain, just to perform the simple task of running other two kernels, like a freebsd code at cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel force balancing shared jobs of an world wide clustered extensible system?" nevermind. > Date: Fri, 20 Nov 2009 03:29:56 +0000 > From: xorquewasp@googlemail.com > To: sfourman@gmail.com > CC: freebsd-hackers@freebsd.org > Subject: Re: Wine on amd64 in 32 bit jail > > On 2009-11-19 17:12:19, Sam Fourman Jr. wrote: > > > > I would like to help get this working.. is there a howto somewhere to > > setup a i386 jail on amd64? > > I used teh instructions on http://wiki.freebsd.org/Wine (and pointed > > the jail to /compat/i386) > > Inside teh jail uname -a still produces this: > > FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18 > > 22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64 > > Hello. > > Not sure about the mesa problem at the moment, but I made uname identify > itself as i386 by just setting UNAME_m=i386 in the environment. > > You could put this in the shell environment of the user you run as inside > the jail. > > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _________________________________________________________________ Novo windowslive.com.br. Descubra como juntar a galera com os produtos Windows Live. http://www.windowslive.com.br/?ocid=WindowsLive09_MSN_Hotmail_Tagline_out09 From julian at elischer.org Fri Nov 20 18:43:19 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 20 18:43:26 2009 Subject: Wine on amd64 in 32 bit jail - for stupid peaple only In-Reply-To: References: <20091119065742.GA28159@logik.internal.network>, <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com>, <20091120032955.GA27847@logik.internal.network> Message-ID: <4B06E345.4030603@elischer.org> Fulano Tal wrote: > Use IPMI to read architecture information is easy, but a nice ploy is to sed-out i386 and amd64 related #ifdefs, and have nightmares with chains... sorry, I mean You will have a bi-archtecture system after some work with a cool new personalized tables compatible with 32 and 64 images. You will have the honorable scout's ribbon of scratch a file system in your chest after stark in short, something like an homunculus with AB positive blood type. > > > > > good luck. > > > > > ps.: Do I waste time sending replies that maybe will not help anybody, with idiot thoughs like: "hey guys, what about we taylor an prototype of an a.i. managed not human operating system, that is not so simple to be handled by any simple person except for a few seconds at every century by prodigy minds more exceptional than any existing mythological wisdom, and without any crt and hack objects or strange acpi boring dependencies that nobody want to explain, just to perform the simple task of running other two kernels, like a freebsd code at cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel force balancing shared jobs of an world wide clustered extensible system?" > > > nevermind. > Didn't your mother tell you to not eat other people's medications? :-) Julian From gatinhodosseussonhos at hotmail.com Fri Nov 20 19:08:26 2009 From: gatinhodosseussonhos at hotmail.com (Fulano Tal) Date: Fri Nov 20 19:08:33 2009 Subject: Wine on amd64 in 32 bit jail - for stupid peaple only In-Reply-To: <4B06E345.4030603@elischer.org> References: <20091119065742.GA28159@logik.internal.network>, , <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com>, , <20091120032955.GA27847@logik.internal.network>, , <4B06E345.4030603@elischer.org> Message-ID: neither I believe I was sober, bleh :P Underdog - planning to write a book now > Date: Fri, 20 Nov 2009 10:43:17 -0800 > From: julian@elischer.org > To: gatinhodosseussonhos@hotmail.com > CC: freebsd-hackers@freebsd.org > Subject: Re: Wine on amd64 in 32 bit jail - for stupid peaple only > > Fulano Tal wrote: > > Use IPMI to read architecture information is easy, but a nice ploy > is to sed-out i386 and amd64 related #ifdefs, and have nightmares with > chains... sorry, I mean You will have a bi-archtecture system after > some work with a cool new personalized tables compatible with 32 and > 64 images. You will have the honorable scout's ribbon of scratch a > file system in your chest after stark in short, something like an > homunculus with AB positive blood type. > > > > > > > > > > good luck. > > > > > > > > > > ps.: Do I waste time sending replies that maybe will not help > anybody, with idiot thoughs like: "hey guys, what about we taylor an > prototype of an a.i. managed not human operating system, that is not > so simple to be handled by any simple person except for a few seconds > at every century by prodigy minds more exceptional than any existing > mythological wisdom, and without any crt and hack objects or strange > acpi boring dependencies that nobody want to explain, just to perform > the simple task of running other two kernels, like a freebsd code at > cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel > force balancing shared jobs of an world wide clustered extensible system?" > > > > > > nevermind. > > > > Didn't your mother tell you to not eat other people's medications? > > > :-) > > Julian > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _________________________________________________________________ Agora a pressa ? amiga da perfei??o. Chegou o Windows 7. Conhe?a! http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539 From kayve at sfsu.edu Fri Nov 20 23:17:51 2009 From: kayve at sfsu.edu (KAYVEN RIESE) Date: Fri Nov 20 23:17:57 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <4B0555C6.8020105@elischer.org> References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <4B0555C6.8020105@elischer.org> Message-ID: On Thu, 19 Nov 2009, Julian Elischer wrote: > xorquewasp@googlemail.com wrote: >> On 2009-11-18 23:19:14, Julian Elischer wrote: >>> Wine is an exceptional bit of software, in many ways. >> http://wiki.freebsd.org/Wine >> >> "FreeBSD currently lacks support for 32bit ports on a 64bit system. >> However, with a little bit of effort you can build and use the 32 bit >> wine executable on an amd64 system (Diablo 2 works just fine)." >> >> His instructions show an essentially identical setup to mine (apart >> from the fact that he's running a chroot and I'm running a jail). > > jail may not alow you to do the LDT system calls. > > have you tried a chroot? Is there any reason to fear Microsoft viruses infecting Wine programs? Is that why he is using a jail? Would there be a greater danger of virus infection with chroot? > >> >> Even any ideas on how to debug this would help. >> >> xw > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From kayve at sfsu.edu Fri Nov 20 23:51:19 2009 From: kayve at sfsu.edu (KAYVEN RIESE) Date: Fri Nov 20 23:51:26 2009 Subject: Wine on amd64 in 32 bit jail - for stupid peaple only In-Reply-To: References: <20091119065742.GA28159@logik.internal.network>, , <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com>, , <20091120032955.GA27847@logik.internal.network>, , <4B06E345.4030603@elischer.org> Message-ID: On Fri, 20 Nov 2009, Fulano Tal wrote: > > neither I believe I was sober, bleh :P > > > > Underdog - planning to write a book now S00per! {:D what's it gonna be called? > > > >> Date: Fri, 20 Nov 2009 10:43:17 -0800 >> From: julian@elischer.org >> To: gatinhodosseussonhos@hotmail.com >> CC: freebsd-hackers@freebsd.org >> Subject: Re: Wine on amd64 in 32 bit jail - for stupid peaple only >> >> Fulano Tal wrote: >>> Use IPMI to read architecture information is easy, but a nice ploy >> is to sed-out i386 and amd64 related #ifdefs, and have nightmares with >> chains... sorry, I mean You will have a bi-archtecture system after >> some work with a cool new personalized tables compatible with 32 and >> 64 images. You will have the honorable scout's ribbon of scratch a >> file system in your chest after stark in short, something like an >> homunculus with AB positive blood type. >>> >>> >>> >>> >>> good luck. >>> >>> >>> >>> >>> ps.: Do I waste time sending replies that maybe will not help >> anybody, with idiot thoughs like: "hey guys, what about we taylor an >> prototype of an a.i. managed not human operating system, that is not >> so simple to be handled by any simple person except for a few seconds >> at every century by prodigy minds more exceptional than any existing >> mythological wisdom, and without any crt and hack objects or strange >> acpi boring dependencies that nobody want to explain, just to perform >> the simple task of running other two kernels, like a freebsd code at >> cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel >> force balancing shared jobs of an world wide clustered extensible system?" >>> >>> >>> nevermind. >>> >> >> Didn't your mother tell you to not eat other people's medications? >> >> >> :-) >> >> Julian >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _________________________________________________________________ > Agora a pressa ? amiga da perfei??o. Chegou o Windows 7. Conhe?a! > http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From julian at elischer.org Sat Nov 21 00:27:50 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Nov 21 00:27:57 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <4B0555C6.8020105@elischer.org> Message-ID: <4B073404.407@elischer.org> KAYVEN RIESE wrote: > > On Thu, 19 Nov 2009, Julian Elischer wrote: >> xorquewasp@googlemail.com wrote: >>> On 2009-11-18 23:19:14, Julian Elischer wrote: > >>>> Wine is an exceptional bit of software, in many ways. > >>> http://wiki.freebsd.org/Wine >>> >>> "FreeBSD currently lacks support for 32bit ports on a 64bit system. >>> However, with a little bit of effort you can build and use the 32 bit >>> wine executable on an amd64 system (Diablo 2 works just fine)." >>> >>> His instructions show an essentially identical setup to mine (apart >>> from the fact that he's running a chroot and I'm running a jail). >> >> jail may not alow you to do the LDT system calls. >> >> have you tried a chroot? > > Is there any reason to fear Microsoft viruses infecting Wine programs? > Is that why he is using a jail? Would there be a greater danger of > virus infection with chroot? I was thinking just as a test, but others have answered the question I believe. > > >> >>> >>> Even any ideas on how to debug this would help. >>> >>> xw >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > > *----------------------------------------------------------* > Kayven Riese, BSCS, MS (Physiology and Biophysics) > (415) 902 5513 cellular > http://kayve.net > Webmaster http://ChessYoga.org > *----------------------------------------------------------* > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From perryh at pluto.rain.com Sat Nov 21 09:10:56 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Nov 21 09:11:08 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: References: <20091119065742.GA28159@logik.internal.network> <4B04F172.7070803@elischer.org> <20091119073818.GA81272@logik.internal.network> <4B0555C6.8020105@elischer.org> Message-ID: <4b07ac87.h6ReR06qiwiC2CTM%perryh@pluto.rain.com> KAYVEN RIESE wrote: > Is there any reason to fear Microsoft viruses infecting Wine programs? In principle, yes, because Wine is supposed to be a complete reimplementation of the win32 API, thus any program that runs differently on Wine than on Windows demonstrates a bug in Wine. (IIRC there are a few Windows viruses that do run on wine.) In practice, any Wine bug that impairs only viruses will probably not be a high priority to get fixed :) From peterjeremy at acm.org Sat Nov 21 13:21:19 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Sat Nov 21 13:21:25 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> References: <20091119065742.GA28159@logik.internal.network> <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> Message-ID: <20091121105244.GA35595@server.vk2pj.dyndns.org> On 2009-Nov-19 17:12:19 -0600, "Sam Fourman Jr." wrote: >I would like to help get this working.. is there a howto somewhere to >setup a i386 jail on amd64? >I used teh instructions on http://wiki.freebsd.org/Wine (and pointed >the jail to /compat/i386) I haven't tried wine, but I do have an i386 jail on my main amd64 server (primarily to build apps for my netbook) and have managed to build all the apps I want (including Firefox, OpenOffice.org and jdk15). I have a full i386 world installed in the jail and have the following overrides in my environment: MACHINE=i386 UNAME_p=i386 UNAME_m=i386 I did run into problems initially because my i386 userland wasn't aligned with my amd64 kernel but rebuilding both fixed that (I'm running 8.0-RC1 and a bit). Note that some tools that poke around in kernel innards won't work - ps and lsof are the most obvious. ktrace works but the resultant ktrace.out files need to read with an amd64 kdump. >Inside teh jail uname -a still produces this: >FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18 >22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64 You are missing the UNAME_x environment variables. >so trying to compile mesa-demos produces this It will compile and run with the above environment changes. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091121/9d9aa09f/attachment.pgp From fbsdlist at src.cx Sat Nov 21 18:22:28 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Sat Nov 21 18:22:35 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091121105244.GA35595@server.vk2pj.dyndns.org> References: <20091119065742.GA28159@logik.internal.network> <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> <20091121105244.GA35595@server.vk2pj.dyndns.org> Message-ID: > Note that some tools that poke around in kernel innards won't work - > ps and lsof are the most obvious. ?ktrace works but the resultant > ktrace.out files need to read with an amd64 kdump. Some of those issues can be solved by using within 32-bit jail statically linked 64-bit binaries. It does work for ps which is available in /rescue . --Artem From ivoras at freebsd.org Sat Nov 21 21:01:36 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 21 21:01:42 2009 Subject: PUFFS SoC project? Message-ID: <9bbcef730911211240n342d412dg21af8c76b4e1b429@mail.gmail.com> What is the status of this year's SoC projects? Specifically, does anyone know what happened to PUFFS? (http://wiki.freebsd.org/SOC2009TatsianaSeveryna) ? From gleb.kurtsou at gmail.com Sun Nov 22 00:41:00 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Sun Nov 22 00:41:06 2009 Subject: PUFFS SoC project? In-Reply-To: <9bbcef730911211240n342d412dg21af8c76b4e1b429@mail.gmail.com> References: <9bbcef730911211240n342d412dg21af8c76b4e1b429@mail.gmail.com> Message-ID: <20091122001422.GA17971@tops.skynet.lt> On (21/11/2009 21:40), Ivan Voras wrote: > What is the status of this year's SoC projects? Specifically, does > anyone know what happened to PUFFS? > (http://wiki.freebsd.org/SOC2009TatsianaSeveryna) ? As far as I know it is in a pretty good shape. Tatsiana is busy with real job, and has "passed" maintainership to me. ntfs-3g, puffs-ssh and some other filesystems work, but are largely untested, some fuse filesystems are broken as their support of inode numbers is to weak (take a look at fuse-sshfs). There are some issues regarding cache. Original NetBSD puffs code tends to mmap data to cache it in vm, puffs port doesn't. Besides mmaped pages can go out of sync. If you are interested in working on it, do not hesitate contacting me, I'm interested in finishing the port. Thanks, Gleb. From obrien654j at gmail.com Sun Nov 22 22:11:37 2009 From: obrien654j at gmail.com (Jeremy O'Brien) Date: Sun Nov 22 22:11:43 2009 Subject: Cisco Aironet MPI350 Fix Message-ID: <20091122214846.GA24357@minifree.wright.edu> Hello, I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31, and on a fresh install of FreeBSD 8.0-RC3, the card did not work. Also, it caused my system to freeze up for a few seconds about once a minute as the driver spit out "an0: device timeout" messages so long as the interface was up. I researched the issue, and found the following fix already in dragonflybsd's tree: http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db883ae3eb5e4ebf2ece9 I modified the patch and applied it to FreeBSD's kernel (trivial), and am happy to report that my card is now working flawlessly. Could someone possibly review this patch and integrate it into the source tree so that others may benefit from it as well? The patch is based off of 8.0-RC3's code, but applies to the latest code as well without modification. Thank you, Jeremy O'Brien -------------- next part -------------- A non-text attachment was scrubbed... Name: mpi350_fix.diff Type: text/x-diff Size: 3141 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20091122/c4a60d19/mpi350_fix.bin From gatinhodosseussonhos at hotmail.com Mon Nov 23 04:17:31 2009 From: gatinhodosseussonhos at hotmail.com (Fulano Tal) Date: Mon Nov 23 04:17:40 2009 Subject: Cisco Aironet MPI350 Fix In-Reply-To: <20091122214846.GA24357@minifree.wright.edu> References: <20091122214846.GA24357@minifree.wright.edu> Message-ID: Mr O'Brien, I gave up of 8.0-RC3 a few days ago because I was unable of fix a missing /dev/agp, but I got better after reading "freeze up a few seconds about once a minute", just after restart a frozen pc. I start to storm again but the only thing I know is: a) slackware agp nod makes no sense b) obscure halts during lilo are happening c) frost login prompts broke with my freebsd zippy cowsay fortune fun I need some clues or better, a breakpoint hint. > Date: Sun, 22 Nov 2009 16:48:46 -0500 > From: obrien654j@gmail.com > To: freebsd-hackers@freebsd.org > Subject: Cisco Aironet MPI350 Fix > > Hello, > > I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31, and on a > fresh install of FreeBSD 8.0-RC3, the card did not work. Also, it caused > my system to freeze up for a few seconds about once a minute as the > driver spit out "an0: device timeout" messages so long as the interface > was up. I researched the issue, and found the following fix already in > dragonflybsd's tree: > > http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db883ae3eb5e4ebf2ece9 > > I modified the patch and applied it to FreeBSD's kernel (trivial), and > am happy to report that my card is now working flawlessly. Could someone > possibly review this patch and integrate it into the source tree so that > others may benefit from it as well? > > The patch is based off of 8.0-RC3's code, but applies to the latest code > as well without modification. > > Thank you, > Jeremy O'Brien _________________________________________________________________ Agora a pressa ? amiga da perfei??o. Chegou o Windows 7. Conhe?a! http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539 From a134qaed at gmail.com Mon Nov 23 05:37:19 2009 From: a134qaed at gmail.com (Dylan Cochran) Date: Mon Nov 23 05:37:54 2009 Subject: Wine on amd64 in 32 bit jail In-Reply-To: <20091121105244.GA35595@server.vk2pj.dyndns.org> References: <20091119065742.GA28159@logik.internal.network> <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> <20091121105244.GA35595@server.vk2pj.dyndns.org> Message-ID: On Sat, Nov 21, 2009 at 5:52 AM, Peter Jeremy wrote: > I did run into problems initially because my i386 userland wasn't > aligned with my amd64 kernel but rebuilding both fixed that (I'm > running 8.0-RC1 and a bit). > > Note that some tools that poke around in kernel innards won't work - > ps and lsof are the most obvious. ?ktrace works but the resultant > ktrace.out files need to read with an amd64 kdump. A word of caution: not all the ioctl's and setsockopt's have the proper glue code under COMBAT_FREEBSD32. For example, running ifconfig on 7.2 i386-on-amd64 is unable to set an ip address, and syscons ioctls are completely broken. The program will build properly, but will be unreliable at runtime (seemingly out of the blue segfaults, a few cases of sigbus). Especially if they do a blind cast without sanity checking and confinue forward on error. While this may not seem that relevant on a build machine, remember that autoconf generates tiny stub binaries and runs them to determine 'compatibility' for the binary it intends to build. It may feed information that will lead it to making incorrect guesses about the target environment. It's not very common, but it has happened, and can fly under the radar. From gatinhodosseussonhos at hotmail.com Mon Nov 23 07:45:48 2009 From: gatinhodosseussonhos at hotmail.com (Fulano Tal) Date: Mon Nov 23 07:45:55 2009 Subject: Cisco Aironet MPI350 Fix In-Reply-To: <20091122214846.GA24357@minifree.wright.edu> References: <20091122214846.GA24357@minifree.wright.edu> Message-ID: ignore that, I just discovered watson.org.., sorry. computers are not for me, really :/ Felipe. From: gatinhodosseussonhos@hotmail.com To: obrien654j@gmail.com; freebsd-hackers@freebsd.org Subject: RE: Cisco Aironet MPI350 Fix Date: Mon, 23 Nov 2009 05:17:30 +0100 Mr O'Brien, I gave up of 8.0-RC3 a few days ago because I was unable of fix a missing /dev/agp, but I got better after reading "freeze up a few seconds about once a minute", just after restart a frozen pc. I start to storm again but the only thing I know is: a) slackware agp nod makes no sense b) obscure halts during lilo are happening c) frost login prompts broke with my freebsd zippy cowsay fortune fun I need some clues or better, a breakpoint hint. > Date: Sun, 22 Nov 2009 16:48:46 -0500 > From: obrien654j@gmail.com > To: freebsd-hackers@freebsd.org > Subject: Cisco Aironet MPI350 Fix > > Hello, > > I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31, and on a > fresh install of FreeBSD 8.0-RC3, the card did not work. Also, it caused > my system to freeze up for a few seconds about once a minute as the > driver spit out "an0: device timeout" messages so long as the interface > was up. I researched the issue, and found the following fix already in > dragonflybsd's tree: > > http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db883ae3eb5e4ebf2ece9 > > I modified the patch and applied it to FreeBSD's kernel (trivial), and > am happy to report that my card is now working flawlessly. Could someone > possibly review this patch and integrate it into the source tree so that > others may benefit from it as well? > > The patch is based off of 8.0-RC3's code, but applies to the latest code > as well without modification. > > Thank you, > Jeremy O'Brien A vida na frente do computador ficou mais simples: Chegou Windows 7! Clique e Conhe?a _________________________________________________________________ Agora a pressa ? amiga da perfei??o. Chegou o Windows 7. Conhe?a! http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539 From lgj at usenix.org Tue Nov 24 18:03:56 2009 From: lgj at usenix.org (Lionel Garth Jones) Date: Tue Nov 24 18:19:30 2009 Subject: IPTPS '10 CFP Message-ID: <66C615B4-3A6C-4D6F-A294-F3B026780853@usenix.org> On behalf of the 9th International Workshop on Peer-to-Peer Systems (IPTPS '10) program committee, we are inviting you to submit engaging position papers on the current and future trends in peer-to-peer systems. Co-located with NSDI '10 in San Jose, CA, this one-day workshop provides a venue in which to present and discuss peer-to-peer technologies, applications, and systems and to identify key research issues and challenges that lie ahead. This year, the workshop's charter will be expanded to include topics relating to self-organizing and self-managing distributed systems. This is in response to recent trends where self-organizing techniques proposed in early peer-to-peer systems have found their way into more managed settings such as datacenters, enterprises, and ISPs to help deal with growing scale, complexity, and heterogeneity. In the context of this year's workshop, peer-to-peer systems are defined to be large-scale distributed systems that are mostly decentralized, are self-organizing, and might or might not include resources from multiple administrative domains. Papers will be selected based on originality, likelihood of spawning insightful discussion, and technical merit. The program will include presentations of position papers along with plenty of time for lively discussion among the participants, as well as a demo session for working systems. Topics of interest include but are not limited to: * Network and system support for peer-to-peer systems * Self-organizing and self-managing distributed systems * Adaptive algorithms and architectures for large-scale distributed systems * New applications and protocols for peer-to-peer systems * Availability, robustness, performance, and scaling * Security, privacy, anonymity, anti-censorship, and incentives * Lessons drawn from experience with deployed peer-to-peer systems * Measurement, modeling, and workload characterization Complete paper submissions are due Friday, December 18, 2009, 11:59 p.m. EST. For more details on the submission process, please see the complete Call for Papers at: http://www.usenix.org/iptps10/cfpa/ We look forward to receiving your submissions! Michael J. Freedman, Princeton University Arvind Krishnamurthy, University of Washington IPTPS '10 Program Co-Chairs iptps10chairs@usenix.org --------------------------------- Call for Papers 9th International Workshop on Peer-to-Peer Systems (IPTPS '10) April 27, 2010 San Jose, CA http://www.usenix.org/iptps10/cfpa/ Submissions Deadline: December 18, 2009, 11:59 p.m. EST --------------------------------- From nparhar at gmail.com Tue Nov 24 18:53:11 2009 From: nparhar at gmail.com (Navdeep Parhar) Date: Tue Nov 24 18:53:17 2009 Subject: zero size set_pcpu linker sets Message-ID: objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" section of size 0. Why? What is the difference between having a 0 sized set_pcpu vs. not having it at all? The kernel linker considers the alignment requirements of these empty sections and advances mapsize/mapbase. This bothers my kgdb (which is slightly modified to deal with amd64 KLDs). I'm using the patch shown here as a stopgap measure. I think the correct fix is to not have these empty sections in the KLD to begin with. Regards, Navdeep diff -r 09b877bb00f2 sys/kern/link_elf_obj.c --- a/sys/kern/link_elf_obj.c Mon Nov 23 12:42:09 2009 -0800 +++ b/sys/kern/link_elf_obj.c Tue Nov 24 10:13:02 2009 -0800 @@ -680,10 +680,12 @@ switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: - alignmask = shdr[i].sh_addralign - 1; - mapsize += alignmask; - mapsize &= ~alignmask; - mapsize += shdr[i].sh_size; + if (shdr[i].sh_size) { + alignmask = shdr[i].sh_addralign - 1; + mapsize += alignmask; + mapsize &= ~alignmask; + mapsize += shdr[i].sh_size; + } break; } } @@ -740,9 +742,15 @@ switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: - alignmask = shdr[i].sh_addralign - 1; - mapbase += alignmask; - mapbase &= ~alignmask; + if (shdr[i].sh_size) { + alignmask = shdr[i].sh_addralign - 1; + mapbase += alignmask; + mapbase &= ~alignmask; + } if (ef->shstrtab && shdr[i].sh_name != 0) ef->progtab[pb].name = ef->shstrtab + shdr[i].sh_name;