From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 1 00:41:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080F2106566B for ; Sun, 1 Nov 2009 00:41:57 +0000 (UTC) (envelope-from remodeler@alentogroup.org) Received: from courriel.marmotmail.com (courriel.marmotmail.com [85.17.36.172]) by mx1.freebsd.org (Postfix) with ESMTP id BF3788FC08 for ; Sun, 1 Nov 2009 00:41:56 +0000 (UTC) Received: from bruce.epifora.com (localhost.local [127.0.0.1]) by courriel.marmotmail.com (Postfix) with ESMTP id 82BA1239497 for ; Sun, 1 Nov 2009 02:45:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by bruce.epifora.com (Postfix) with ESMTP id E60D54761F9 for ; Sat, 31 Oct 2009 19:59:58 -0500 (EST) Received: from bruce.epifora.com ([127.0.0.1]) by localhost (bruce.epifora.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01558-08 for ; Sat, 31 Oct 2009 19:59:57 -0500 (EST) Received: from alentogroup.org (localhost [127.0.0.1]) by bruce.epifora.com (Postfix) with ESMTP id 132554761F8 for ; Sat, 31 Oct 2009 19:59:57 -0500 (EST) From: "remodeler" To: freebsd-hackers@freebsd.org Date: Sat, 31 Oct 2009 19:59:57 -0500 Message-Id: <20091101004815.M83360@alentogroup.org> X-OriginatingIP: 127.0.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: dumpon to an encrypted swap partition? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 00:41:57 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sun Nov 1 09:00:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 775281065679 for ; Sun, 1 Nov 2009 09:00:22 +0000 (UTC) (envelope-from pirat@tint.or.th) Received: from mail.tint.or.th (ns2.tint.or.th [122.154.13.210]) by mx1.freebsd.org (Postfix) with SMTP id ECA4F8FC15 for ; Sun, 1 Nov 2009 09:00:21 +0000 (UTC) Received: (qmail 18286 invoked from network); 1 Nov 2009 08:54:07 -0000 Received: from www.tint.or.th (HELO alpha.nst.or.th) (122.154.13.80) by mail.tint.or.th with SMTP; 1 Nov 2009 08:54:07 -0000 Received: from 10.3.1.28 (10.3.1.28 [10.3.1.28]) by webmail.tint.or.th (Horde Framework) with HTTP; Sun, 01 Nov 2009 15:33:01 +0700 Message-ID: <20091101153301.687649jdv7towzi5@webmail.tint.or.th> X-Priority: 3 (Normal) Date: Sun, 01 Nov 2009 15:33:01 +0700 From: =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= =?utf-8?b?4Lio4Lij4Li14LmC4Lii4LiY4Liy?= To: freebsd-hackers@freebsd.org References: <20091026143639.13895c34kml7gmmf@webmail.tint.or.th> <20091026095317.GA72492@ei.bzerk.org> <20091026163950.56716v4m76bon23q@webmail.tint.or.th> In-Reply-To: <20091026163950.56716v4m76bon23q@webmail.tint.or.th> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) Subject: Re: make release stop at Creating ISO imagess (success) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 09:00:22 -0000 Quoting =E0=B9=84=E0=B8=9E=E0=B8=A3=E0=B8=B1=E0=B8=8A =E0=B8=A8=E0=B8=A3=E0= =B8=B5=E0=B9=82=E0=B8=A2=E0=B8=98=E0=B8=B2 : > Quoting Ruben de Groot : > >> On Mon, Oct 26, 2009 at 02:36:39PM +0700, ??????????????? =20 >> ????????????????????? 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=3D/kaitag/KAITAG BUILDNAME=3D7.2-RELEASE \ >>> CVSROOT=3D/var/ftp/pub/ncvs RELEASETAG=3DRELENG_7_2_0_RELEASE \ >>> EXTSRCDIR=3D/usr/src EXTPORTSDIR=3D/usr/ports \ >>> DOC_LANG=3Den_US.ISO8859-1 NODOC=3DNO NOPORTS=3DNO \ >>> MAKE_DVD=3DYES MAKE_ISOS=3DYES CDROM=3DYES >>> RELEASEDISTFILES=3D/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 =20 > is source files for making cdrtools. i keep all packages in a =20 > separate location, /usr/ports/packages/. > >> >> Ruben >> >> from previous errors without any reasons, my instinct tell me that i =20 need to specify EXTLOCALDIR=3D/usr/local in command line as shown below =3D=3D=3D=3D>> begin wmc# time make CHROOTDIR=3D/kaitag/KAITAG BUILDNAME=3D7.2-RELEASE =20 CVSROOT=3D/var/ftp/p ub/ncvs RELEASETAG=3DRELENG_7_2_0_RELEASE EXTSRCDIR=3D/usr/src =20 DOC_LANG=3Den_US.ISO885 9-1 NODOC=3DNO NOPORTS=3DNO MAKE_ISOS=3DYES EXTLOCALDIR=3D/usr/local =20 RELEASEDISTFILES=3D/v ar/ftp/pub/distfiles NOCDROM=3DNO NO_PREFETCHDISTFILES=3DYES release =3D=3D=3D=3D>> 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=3DC TZ=3DGMT 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=3DNO in command =20 line but where is did change to CDROM=3DYES and change target to =20 rerelease, i get cdrom as desire. upto this point, release(7) need to be changed a bit. so also i need =20 to experiment further for including packages into disc[123].iso with best regards, --=20 psr =E0=B8=A1=E0=B8=B0=E0=B8=83=E0=B8=B2=E0=B8=A1 =E0=B8=85=E0=B8=B4=E0=B8=99=E0= =B9=80=E0=B8=94=E0=B8=B4=E0=B8=99=E0=B8=94=E0=B8=99 =E0=B8=A1=E0=B8=B0=E0=B9=84=E0=B8=9F =E0=B8=85=E0=B8=99=E0=B9=80=E0=B8=AB=E0= =B8=A5=E0=B8=B4=E0=B8=87=E0=B8=9F=E0=B9=89=E0=B8=B2 http://makham.blogspot.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 1 15:14:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64A1B1065692 for ; Sun, 1 Nov 2009 15:14:58 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id E59F88FC1A for ; Sun, 1 Nov 2009 15:14:57 +0000 (UTC) Received: by bwz5 with SMTP id 5so5460760bwz.3 for ; Sun, 01 Nov 2009 07:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Tn4Hkj2tr78ITRg8EV+4ulTjYWXHny0K/PC5T/jJTjY=; b=pMiWFUWYtQuDbiXUj0YeraDKlVTWAwNlGMsZY3WIjKK1BQbg9bvDO0VjuFrfmU3rl2 M+A9t4/trxzsvvyzM4MGD3Y1E+Z7wSocqOSNx15QTc/NX49XRKve/fWto+0zytOryWKy ZrderGugrLe6+pJytPGV3lOCggItctrDoHNyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=nBE02SMTLhjCLO33HIvLWQYUf4u9jG8c4PmReLv0Szki8qOFYvHodnsLUt0pquWkft wXwYP35w3JuRb4EExNL5zAUvTzTVJ2CzAeW+lBaV2wHOaLuwRyYaRzpWQrbKT5CSJRw6 h1GOsTAp3tfKZxm57IvfWFa+NrH+Vobg0hvrI= Received: by 10.204.15.3 with SMTP id i3mr3078630bka.71.1257088496403; Sun, 01 Nov 2009 07:14:56 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 2sm4295975fks.18.2009.11.01.07.14.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Nov 2009 07:14:55 -0800 (PST) Date: Sun, 1 Nov 2009 17:14:27 +0200 From: Gleb Kurtsou To: remodeler Message-ID: <20091101151427.GA2846@tops> References: <20091101004815.M83360@alentogroup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20091101004815.M83360@alentogroup.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: dumpon to an encrypted swap partition? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 15:14:58 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sun Nov 1 16:36:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E3D106568B; Sun, 1 Nov 2009 16:36:40 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E78B68FC0A; Sun, 1 Nov 2009 16:36:39 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DA2AF6D41B; Sun, 1 Nov 2009 16:36:37 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id ACDA184503; Sun, 1 Nov 2009 17:36:37 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: Date: Sun, 01 Nov 2009 17:36:37 +0100 In-Reply-To: (Alexander Best's message of "Sat, 31 Oct 2009 14:30:47 +0100 (CET)") Message-ID: <86bpjmkxre.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , freebsd-hackers@freebsd.org, pluknet , Antony Mawer , rafan@freebsd.org Subject: Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 16:36:40 -0000 Alexander Best writes: > great news. so should the PR be closed or should it remain in patched sta= te 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 b= etter > 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 14:25:07 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A9A1065695 for ; Mon, 2 Nov 2009 14:25:07 +0000 (UTC) (envelope-from m.boyarov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id D05AE8FC18 for ; Mon, 2 Nov 2009 14:25:06 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so644709eyd.9 for ; Mon, 02 Nov 2009 06:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=CyFrmHq29JqELuFcMJx6Jd7PBCxQK+lXfk8dF65U6y4=; b=Cz6VyZbH4sKjUPitpzFrB+GYeF2VM+Cq/D2SS92YWPsg3djG2y8F34P3k/ZOCFbxmh P4SgS1RpvA81F8657381ShfYmKWDXSguy3ypktfevNl03JUxoPtSY0yrTOy4pCkm3sWz 0tpVvZzRjEjVhO3zrUNyWdeyQjRx6RPoDCPWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uFJkgGt4FSi2MjHWXXqx0pmLnhWqaQ/Qvo+vCwN/na/7Co+D10M6P19K4WcoabF5Xe l4EGl+bvmG86TW9UimONywSAb/SS0hZmGCDT5bAPFZ2GpIf87ZZhcBqg6zY1Ya4kzABO 4RiH0zVmIAMF+2qFjMNBHks1KO8y1tDrgTAvM= MIME-Version: 1.0 Received: by 10.216.86.80 with SMTP id v58mr4556568wee.40.1257169953638; Mon, 02 Nov 2009 05:52:33 -0800 (PST) Date: Mon, 2 Nov 2009 15:52:33 +0200 Message-ID: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> From: Max Boyarov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: strange gdb behavior X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:25:07 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 15:42:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6273E106566C for ; Mon, 2 Nov 2009 15:42:19 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 170A38FC1C for ; Mon, 2 Nov 2009 15:42:18 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4B3385B028; Mon, 2 Nov 2009 16:42:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 47CE45AFFD; Mon, 2 Nov 2009 16:42:14 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1FD0F5CCA1; Mon, 2 Nov 2009 16:42:14 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009110216421269-245767 ; Mon, 2 Nov 2009 16:42:12 +0100 Received: by wep4035 (sSMTP sendmail emulation); Mon, 2 Nov 2009 16:42:12 +0100 Date: Mon, 2 Nov 2009 16:42:12 +0100 From: Alexey Shuvaev To: Max Boyarov Message-ID: <20091102154212.GA30365@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: Max Boyarov , freebsd-hackers@freebsd.org References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 11/02/2009 04:42:12 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 11/02/2009 04:42:13 PM, Serialize complete at 11/02/2009 04:42:13 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: strange gdb behavior X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:42:19 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 15:51:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C97F106566C for ; Mon, 2 Nov 2009 15:51:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF018FC25 for ; Mon, 2 Nov 2009 15:51:48 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nA2FpimK002921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:51:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nA2Fpi78031162; Mon, 2 Nov 2009 17:51:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nA2Fpibd031161; Mon, 2 Nov 2009 17:51:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Nov 2009 17:51:44 +0200 From: Kostik Belousov To: Max Boyarov Message-ID: <20091102155144.GU2147@deviant.kiev.zoral.com.ua> References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0iexB5Bk8cF8G6DP" Content-Disposition: inline In-Reply-To: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: strange gdb behavior X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:51:50 -0000 --0iexB5Bk8cF8G6DP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 02, 2009 at 03:52:33PM +0200, Max Boyarov wrote: > Hi, >=20 > Who could help understand this: >=20 > `--> cat 1.c > int > main(int argc, char **argv) > { > return 0; > } >=20 >=20 > `--> cc -ggdb -o 1 1.c >=20 >=20 > `--> 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 detail= s. > 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 >=20 > 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 } >=20 > 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=3D1, argv=3D0xbfbfe53c) at hello.c:8 8 for (i =3D 0; i < argc; i++) while in-tree gdb shows me the same behaviour as yours. --0iexB5Bk8cF8G6DP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrvABAACgkQC3+MBN1Mb4ge4gCglNNRTE3Awcjtr6+hXM0nIOcX JM0AoIiUFoGtGiNRh25Mj/uWJ5rb2k6R =il0e -----END PGP SIGNATURE----- --0iexB5Bk8cF8G6DP-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 18:24:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1406F106566C for ; Mon, 2 Nov 2009 18:24:15 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9C12C8FC08 for ; Mon, 2 Nov 2009 18:24:14 +0000 (UTC) Received: by ewy5 with SMTP id 5so1674212ewy.36 for ; Mon, 02 Nov 2009 10:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZJg4d6ku3JJMN1KPsjnHdu+dTc5TMpN+duDXfa/B+Rk=; b=j472v+ozbk27HMHGRt4Tb6LLuIqE1NaOkiwEo9jIQBvSj/UqmT7bzyUQLIsjoAB116 rBXa1WjKhYiHVx1p+ZsYaB8QoibNv1kTprMJLzbvXJb8/asVmNfDcWVn6WR0AXTGXKFK 7Nmt3XUOS8YrsFQ3Y/bQYoSy2YDZjJR5AAj1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uZsAJJp15UEN0rkCGUZ96iis8fK3z1YUkfAM0Qn6UJzLI5EBs22WluBuIQOX5vFyze /mtDvrIOpSUN0ySIA+dCVQqlNeEttsyZ3dhxz2BCauWNV3PdCI4sVbwbU3s9OZ3BTKBd DziKH2UoWFwFhIDUY0T4KJd5bIKcK10UxYfj4= MIME-Version: 1.0 Received: by 10.216.89.146 with SMTP id c18mr5085275wef.84.1257186253147; Mon, 02 Nov 2009 10:24:13 -0800 (PST) In-Reply-To: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> References: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> Date: Mon, 2 Nov 2009 13:24:13 -0500 Message-ID: From: Ryan Stone To: Jason Harmening Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, gonzo@bluezbox.com Subject: Re: MIPS: bus_dma(9) and cache problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:24:15 -0000 > What sync operation are you doing? =A0At least for PREREAD or PREWRITE, > I'd expect any dirty cache lines to be flushed to RAM. =A0If 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 19:33:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826F81065694 for ; Mon, 2 Nov 2009 19:33:10 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 1158D8FC13 for ; Mon, 2 Nov 2009 19:33:09 +0000 (UTC) Received: by bwz5 with SMTP id 5so6853430bwz.3 for ; Mon, 02 Nov 2009 11:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=aBsG+cwyqhvimAiXmypQAjmF3qUsg8ZcQOa9bz3Ad7A=; b=NjdOEH7XdHDXDSoLJTYKnWLiHIBDsfVkXfj0f/EfNDdhTMCFo4A9N+C/ioxf/tkc/F xxAZ6pqn/lAVIpOTwp5r30wImGrIZFQCu2sosSVIsJyFm2UTAJ1eKic3TyZPsK6jewCu 2SpQ+qTKaM2rVfC3B0f1FsxYvTMdsSccorpXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Tx7xyc3znhlYPrIU+0oZdgJFBFx9+Db45zHdGbPU6qwBX9tO/rfnPpT58BGQC9jTeR ubYL+viRY8lbJzv0H9m6n3gvPa99DIzTvEpqe/QIul128Jvt4Cv6gb6lslCmFKY1K0ri zznApMCFzwlz+JoEwd/H6nu/GD5zNl7XN5Dag= MIME-Version: 1.0 Received: by 10.223.7.21 with SMTP id b21mr855445fab.104.1257190388854; Mon, 02 Nov 2009 11:33:08 -0800 (PST) In-Reply-To: References: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> Date: Mon, 2 Nov 2009 13:33:08 -0600 Message-ID: <2d1264630911021133uf3033deu20b41adfe54f62c2@mail.gmail.com> From: Jason Harmening To: gonzo@bluezbox.com, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 02 Nov 2009 19:53:13 +0000 Cc: Subject: Re: MIPS: bus_dma(9) and cache problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 19:33:10 -0000 On Mon, Nov 2, 2009 at 12:24 PM, Ryan Stone wrote: >> What sync operation are you doing? =A0At least for PREREAD or PREWRITE, >> I'd expect any dirty cache lines to be flushed to RAM. =A0If 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. =A0That 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 20:46:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23D4810656A5 for ; Mon, 2 Nov 2009 20:46:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E27B68FC19 for ; Mon, 2 Nov 2009 20:46:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9C69546B06; Mon, 2 Nov 2009 15:46:30 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AFDB28A01F; Mon, 2 Nov 2009 15:46:29 -0500 (EST) From: John Baldwin To: Alexander Best Date: Mon, 2 Nov 2009 10:28:42 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911021028.43044.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 02 Nov 2009 15:46:29 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 20:46:31 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 21:05:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8755F106566C; Mon, 2 Nov 2009 21:05:59 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id CF7F68FC17; Mon, 2 Nov 2009 21:05:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,670,1249250400"; d="scan'208";a="287178683" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 02 Nov 2009 22:05:57 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0E0431B0751; Mon, 2 Nov 2009 22:05:56 +0100 (CET) Date: Mon, 02 Nov 2009 22:05:56 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Alexander Best Message-ID: In-Reply-To: <200911021028.43044.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:05:59 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 21:32:32 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A98A51065672; Mon, 2 Nov 2009 21:32:32 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0880A8FC08; Mon, 2 Nov 2009 21:32:31 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,670,1249250400"; d="scan'208";a="227901242" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 02 Nov 2009 22:32:30 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 2C9041B07BE; Mon, 2 Nov 2009 22:32:30 +0100 (CET) Date: Mon, 02 Nov 2009 22:32:29 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Alexander Best Message-ID: In-Reply-To: <86bpjmkxre.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , freebsd-hackers@freebsd.org, pluknet , Antony Mawer , rafan@freebsd.org Subject: Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:32:32 -0000 Dag-Erling Sm=F8rgrav 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 22:02:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28681065679 for ; Mon, 2 Nov 2009 22:02:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5F6F8FC08 for ; Mon, 2 Nov 2009 22:02:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5D69146B03; Mon, 2 Nov 2009 17:02:13 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9D5C98A01D; Mon, 2 Nov 2009 17:02:12 -0500 (EST) From: John Baldwin To: Alexander Best Date: Mon, 2 Nov 2009 17:02:07 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911021702.07938.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 02 Nov 2009 17:02:12 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:02:14 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Mon Nov 2 22:14:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41795106566B; Mon, 2 Nov 2009 22:14:29 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4FC8FC17; Mon, 2 Nov 2009 22:14:28 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,670,1249250400"; d="scan'208";a="287182124" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 02 Nov 2009 23:14:27 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 82C7A1B07BE; Mon, 2 Nov 2009 23:14:27 +0100 (CET) Date: Mon, 02 Nov 2009 23:14:27 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Alexander Best Message-ID: In-Reply-To: <200911021702.07938.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:14:29 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 07:26:20 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32AE3106566B; Tue, 3 Nov 2009 07:26:20 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id D77198FC14; Tue, 3 Nov 2009 07:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Date:From:To:Cc:Subject:Message-ID: Reply-To:References:MIME-Version:Content-Type:In-Reply-To: Sender; bh=QPgcj/kYW2RPidaKdsYUhCmxL9cQRMAfl6VW9Tefu0U=; b=EDjew JztQMrgKNFqnPvUWxVn4AYS2eRuUNCmAVp4Ly37/Rsx1ImcyKdKgCYur90NJHCUn e1ZM1B3ODgMzqdy7Em8P8GSDlcUyzQA7ZGUIt99yxzE97rX3YxUFytRO+TqerQp6 c71X67NcFApb6cqd9xrf7TQpGF8wNnmfN5yU1EKy6xQJKTeUs7jKlMGlhpmWkZos yKejC6txuV9p5K8oA9++DyiBa5dWPIgC4N/5LDKq64hS8z4B9ijSe7MMcWGOM2v8 iaF7GBkaD5ZMJ4dajVP+Eu/qk89D130yGMNQq9bd37xc+Hb8xvnpmZ+mhA5iXwAY BloCxgAAPSyyh1mrA== Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1N5DmS-0009uC-0G; Tue, 03 Nov 2009 10:26:16 +0300 Date: Tue, 3 Nov 2009 10:26:12 +0300 From: Eygene Ryabinkin To: Alexander Best Message-ID: References: <86bpjmkxre.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Ed Schouten , freebsd-hackers@freebsd.org, pluknet , Antony Mawer , Dag-Erling Sm?rgrav , rafan@freebsd.org Subject: Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 07:26:20 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 10:52:55 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E5B1065670 for ; Tue, 3 Nov 2009 10:52:55 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from baranao.anywi.com (baranao.anywi.com [213.207.101.176]) by mx1.freebsd.org (Postfix) with ESMTP id BDC2A8FC18 for ; Tue, 3 Nov 2009 10:52:54 +0000 (UTC) Received: from hillary.anywi.com.van-laarhoven.org (ip51cfcfde.direct-adsl.nl [81.207.207.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by baranao.anywi.com (Postfix) with ESMTPSA id 1863E3F470 for ; Tue, 3 Nov 2009 11:52:51 +0100 (CET) Message-Id: From: Nick Hibma To: FreeBSD Hackers Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 11:52:50 +0100 X-Mailer: Apple Mail (2.936) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on baranao.anywi.com Cc: Subject: Mesh networking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 10:52:55 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 11:19:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49CF106568F for ; Tue, 3 Nov 2009 11:19:42 +0000 (UTC) (envelope-from m.boyarov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id C8A858FC15 for ; Tue, 3 Nov 2009 11:19:41 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so1006581fga.13 for ; Tue, 03 Nov 2009 03:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:to:cc:subject :references:x-comment-to:date:in-reply-to:message-id:x-mailer :mime-version:content-type; bh=IsSBUgz5N19kzPhavJGJTqNeAKPrgXRlkSDAhYKmDwI=; b=m5Pu1UaX45/NON0uvqGjBX4WeZZfZ9VFwxK5kV9oGZ6bdat1I2s/lpe8sOYob54264 TC0kOfAhITTnu97ZhzqteODiWu8+FPOJJw+q0NLBuiLXzTyTpjQffbPAzZ6JykYSfMjh 8kwlzzxAr5WIm5knXtqEw7v7kVCSsaVRHjsLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:x-mailer:mime-version:content-type; b=GIsNe7pkDUkfK4N3hxmJF/3ruO+mGQnNiPaietH6M/QUKo8/64pzrc4YzKR33YvaDw 3jObMIyLslXz5y4Q0Ly+3nhfTJthGGuMNZQNc+b3dovbp4e7wJXq6S6FSaYgsrZ85oj6 I6qwlHXXXPWrMZtahQqJv5EkAkTPJ+3uU/jCc= Received: by 10.87.38.33 with SMTP id q33mr3076550fgj.3.1257247180862; Tue, 03 Nov 2009 03:19:40 -0800 (PST) Received: from deimos.bsd.by (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id d6sm6657443fga.0.2009.11.03.03.19.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 03:19:40 -0800 (PST) Received: by deimos.bsd.by (Postfix, from userid 1024) id A229095917; Tue, 3 Nov 2009 13:19:37 +0200 (EET) From: m.boyarov@gmail.com (Max N. Boyarov) To: Kostik Belousov References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> <20091102155144.GU2147@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Date: Tue, 03 Nov 2009 13:19:37 +0200 In-Reply-To: <20091102155144.GU2147@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 2 Nov 2009 17:51:44 +0200") Message-ID: <7jws274zzq.fsf@bsd.by> X-Mailer: Gnus v5.13/GNU Emacs 23.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org Subject: Re: strange gdb behavior X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 11:19:42 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 11:35:34 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86957106566C for ; Tue, 3 Nov 2009 11:35:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 47CFA8FC15 for ; Tue, 3 Nov 2009 11:35:34 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 48ACE6D41B; Tue, 3 Nov 2009 11:35:33 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1295C84503; Tue, 3 Nov 2009 12:35:33 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: m.boyarov@gmail.com (Max N. Boyarov) References: <87c7bb540911020552x4a602732pd2caecb17c8c4535@mail.gmail.com> <20091102155144.GU2147@deviant.kiev.zoral.com.ua> <7jws274zzq.fsf@bsd.by> Date: Tue, 03 Nov 2009 12:35:32 +0100 In-Reply-To: <7jws274zzq.fsf@bsd.by> (Max N. Boyarov's message of "Tue, 03 Nov 2009 13:19:37 +0200") Message-ID: <86zl73n8mz.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: strange gdb behavior X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 11:35:34 -0000 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 13:07:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91FA6106568D for ; Tue, 3 Nov 2009 13:07:56 +0000 (UTC) (envelope-from awmdpt@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 621A98FC26 for ; Tue, 3 Nov 2009 13:07:56 +0000 (UTC) Received: by pwj8 with SMTP id 8so2669380pwj.3 for ; Tue, 03 Nov 2009 05:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=VjBVLGh+cx4QWGnn8I8GIqdUquVezZb6biqe/fS3PsE=; b=R5gK5biNjYunWqQA86X+2y2oMiDi+0zy+Sr0ZKrq/2WB3pP0OEyCYIopUjwN/WdoBl KdbBj/XDr2bM5zLpmizyfhH1+I+TdsVBEII2tX9w20UHlvzW6Cj+pTrqxTPRFUfLOitX 9Pur3JPlLylCuL3HG5l0zMc9lsdwytc3BaN+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=ONHMqUbBsAJHvFZEIF4szusJ4YiThe100uiL93OMsit3TP2mDHvJs53y4hEMxVZRKn HgXbVnQIolBVzGYQFb0UvCrSwsOg1c2AzfEAqCVHYhwaFOPE3NR+m7zBzWP02i+sICn/ lnDp1PcJmUL9WeA0/bX7htiZ9JVcHDBrGkZS8= Received: by 10.114.215.14 with SMTP id n14mr4527171wag.99.1257251743653; Tue, 03 Nov 2009 04:35:43 -0800 (PST) Received: from ?192.168.10.117? (114-33-76-31.HINET-IP.hinet.net [114.33.76.31]) by mx.google.com with ESMTPS id 22sm22460pxi.10.2009.11.03.04.35.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 04:35:43 -0800 (PST) Sender: Eric From: Eric To: Nick Hibma In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 03 Nov 2009 20:35:38 +0800 Message-ID: <1257251738.2188.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Mailing List Subject: Re: Mesh networking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 13:07:56 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 13:24:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29DBC10656A7 for ; Tue, 3 Nov 2009 13:24:54 +0000 (UTC) (envelope-from awmdpt@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id EDC408FC21 for ; Tue, 3 Nov 2009 13:24:53 +0000 (UTC) Received: by pzk40 with SMTP id 40so3884453pzk.7 for ; Tue, 03 Nov 2009 05:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Uq2RGAnFK2zwsdE62D5rc570bzHaD1RCGWY/81McUg0=; b=Dtt86z5pcWEWskcicybP46pfYI4G2uwbsfq+9tzQt12tifWARnnJX60akacfH4O6Gv VewgMddlUSm9IVNjMQ0livdVAEcqTBtsTbP054/yG5dN06MkgaIsoCwxIbob01QSdwyy HBKb7JzwTtLfH+Alz1MNHRenYdJKj13zaH2cY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=po8WiSoUietGCm4qdJFdK5Ik6zV95FTaH9tVL6710SIQNwJnUxzQpTc81WrRbEdwgU r+qdm5QKLwxFhUtEHj44fanScjZWYWWNP508PVBGqVGQIe49+LIZj2roLgfcs/D19xMu t8xqSTCL6CTjv3sikQZkrPiUGlOSIl55eR/Zk= Received: by 10.114.237.37 with SMTP id k37mr10851738wah.31.1257254693433; Tue, 03 Nov 2009 05:24:53 -0800 (PST) Received: from ?192.168.10.117? (114-33-76-31.HINET-IP.hinet.net [114.33.76.31]) by mx.google.com with ESMTPS id 22sm38967pxi.14.2009.11.03.05.24.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 05:24:52 -0800 (PST) Sender: Eric From: Eric To: Nick Hibma In-Reply-To: <1257251738.2188.4.camel@localhost> References: <1257251738.2188.4.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Tue, 03 Nov 2009 21:24:47 +0800 Message-ID: <1257254687.2188.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Mailing List Subject: Re: Mesh networking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 13:24:54 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 14:13:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310D2106566B for ; Tue, 3 Nov 2009 14:13:29 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from baranao.anywi.com (baranao.anywi.com [213.207.101.176]) by mx1.freebsd.org (Postfix) with ESMTP id E5B488FC22 for ; Tue, 3 Nov 2009 14:13:28 +0000 (UTC) Received: from hillary.anywi.com.van-laarhoven.org (ip51cfcfde.direct-adsl.nl [81.207.207.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by baranao.anywi.com (Postfix) with ESMTPSA id 04B3D3F41B; Tue, 3 Nov 2009 15:13:24 +0100 (CET) Message-Id: <5D1658C3-537E-4A97-B6E2-FFE9AF3E87D6@van-laarhoven.org> From: Nick Hibma To: Eric In-Reply-To: <1257251738.2188.4.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 15:13:24 +0100 References: <1257251738.2188.4.camel@localhost> X-Mailer: Apple Mail (2.936) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on baranao.anywi.com Cc: FreeBSD Hackers Mailing List Subject: Re: Mesh networking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:13:29 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 14:32:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F3E71065670 for ; Tue, 3 Nov 2009 14:32:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E014F8FC29 for ; Tue, 3 Nov 2009 14:32:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 561A446B1A; Tue, 3 Nov 2009 09:32:37 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 472CE8A01F; Tue, 3 Nov 2009 09:32:36 -0500 (EST) From: John Baldwin To: Alexander Best Date: Tue, 3 Nov 2009 09:32:24 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911030932.24583.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 03 Nov 2009 09:32:36 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:32:38 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 15:50:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78B641065670; Tue, 3 Nov 2009 15:50:40 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id CFEBC8FC13; Tue, 3 Nov 2009 15:50:39 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,674,1249250400"; d="scan'208";a="17514856" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 03 Nov 2009 16:50:38 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 303111B0766; Tue, 3 Nov 2009 16:50:38 +0100 (CET) Date: Tue, 03 Nov 2009 16:50:36 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Alexander Best Message-ID: In-Reply-To: <200911030932.24583.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:50:40 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 17:18:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0134710656A3; Tue, 3 Nov 2009 17:18:15 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id 134A48FC08; Tue, 3 Nov 2009 17:18:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,675,1249250400"; d="scan'208";a="227984190" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 03 Nov 2009 18:18:13 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 076891B0766; Tue, 3 Nov 2009 18:18:12 +0100 (CET) Date: Tue, 03 Nov 2009 18:18:12 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alexander Best , John Baldwin , Alexander Best Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:18:15 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 17:24:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0409D106566B; Tue, 3 Nov 2009 17:24:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 96F0E8FC18; Tue, 3 Nov 2009 17:24:53 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 828761CF71; Tue, 3 Nov 2009 18:24:52 +0100 (CET) Date: Tue, 3 Nov 2009 18:24:52 +0100 From: Ed Schouten To: alc@freebsd.org Message-ID: <20091103172452.GU1293@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QU0xYvH/CPhunj+E" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:24:54 -0000 --QU0xYvH/CPhunj+E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alan, * Alan Cox wrote: > The standards for mmap(2) actually disallow values of "off" that are not a > multiple of the page size. >=20 > 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 --=20 Ed Schouten WWW: http://80386.nl/ --QU0xYvH/CPhunj+E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrwZ2QACgkQ52SDGA2eCwUcLQCdHKgsqlj9Os02xLoBxGLYB3NJ bIsAnR1aU8d47nSwDpMeVWJZraH+5PI0 =+88j -----END PGP SIGNATURE----- --QU0xYvH/CPhunj+E-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 17:40:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388D81065676; Tue, 3 Nov 2009 17:40:54 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 34F048FC12; Tue, 3 Nov 2009 17:40:52 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,675,1249250400"; d="scan'208";a="17524067" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 03 Nov 2009 18:40:51 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id EB12E1B07BE; Tue, 3 Nov 2009 18:40:51 +0100 (CET) Date: Tue, 03 Nov 2009 18:40:51 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alexander Best , Alexander Best , John Baldwin , Alexander Best Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:40:54 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 17:50:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4D0B1065672; Tue, 3 Nov 2009 17:50:39 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 28E548FC27; Tue, 3 Nov 2009 17:50:38 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,675,1249250400"; d="scan'208";a="287266192" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 03 Nov 2009 18:50:38 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 1C89A1B07BE; Tue, 3 Nov 2009 18:50:38 +0100 (CET) Date: Tue, 03 Nov 2009 18:50:37 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: , Alexander Best Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Ed Schouten , freebsd-hackers@freebsd.org, pluknet , Antony Mawer , Dag-Erling Sm?rgrav , rafan@freebsd.org Subject: Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:50:39 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 20:22:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A5E810656A5 for ; Tue, 3 Nov 2009 20:22:33 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0310A8FC2D for ; Tue, 3 Nov 2009 20:22:32 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id E5D8A7E853 for ; Tue, 3 Nov 2009 11:22:30 -0900 (AKST) From: Mel Flynn To: freebsd-hackers@freebsd.org Date: Tue, 3 Nov 2009 21:22:28 +0100 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; i386; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_EEJ8Ksjl4Ao5+OM" Message-Id: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Subject: Issue with grep -i (on i386 only?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:22:33 -0000 --Boundary-00=_EEJ8Ksjl4Ao5+OM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 --Boundary-00=_EEJ8Ksjl4Ao5+OM Content-Type: text/plain; charset="UTF-8"; name="test.sh.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.sh.txt" #!/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 --Boundary-00=_EEJ8Ksjl4Ao5+OM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 21:19:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446461065670 for ; Tue, 3 Nov 2009 21:19:14 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id C08288FC15 for ; Tue, 3 Nov 2009 21:19:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 9940214D9ADA; Tue, 3 Nov 2009 22:19:10 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VQ18u9CgEE4r; Tue, 3 Nov 2009 22:19:07 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id D34A214D9ACB; Tue, 3 Nov 2009 22:19:07 +0100 (CET) Message-ID: <4AF09E49.3010705@FreeBSD.org> Date: Tue, 03 Nov 2009 22:19:05 +0100 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mel Flynn References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> In-Reply-To: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: Issue with grep -i (on i386 only?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:19:14 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Tue Nov 3 22:14:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6691D106566B for ; Tue, 3 Nov 2009 22:14:50 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 000FC8FC13 for ; Tue, 3 Nov 2009 22:14:49 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 0B6F17E854; Tue, 3 Nov 2009 13:14:48 -0900 (AKST) From: Mel Flynn To: freebsd-hackers@freebsd.org Date: Tue, 3 Nov 2009 23:14:45 +0100 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; i386; ; ) References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4AF09E49.3010705@FreeBSD.org> In-Reply-To: <4AF09E49.3010705@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200911032314.45247.mel.flynn+fbsd.hackers@mailing.thruhere.net> Cc: Gabor Kovesdan Subject: Re: Issue with grep -i (on i386 only?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:14:50 -0000 On Tuesday 03 November 2009 22:19:05 Gabor Kovesdan wrote: > Mel Flynn escribi=F3: > > 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. >=20 > 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=20 'regexes' should do the same in PCRE and POSIX. I provided the comparison t= o=20 show that the 'problem of case insensitive comparison' is solvable, at the= =20 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: > > =3D>>> 16777216 > > =3D>>> fgrep > > 0.04 real 0.02 user 0.01 sys > > 0.04 real 0.03 user 0.01 sys > > =3D>>> pcregrep > > 0.21 real 0.19 user 0.02 sys > > 0.21 real 0.20 user 0.00 sys > > =3D>>> grep > > 0.04 real 0.02 user 0.01 sys << not -i > > 3.64 real 3.61 user 0.01 sys << -i >=20 > It's an interesting observation, I have never heard of this. >=20 > > 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 probl= em > > 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]: > > =3D>>> 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. >=20 > 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=20 optimization, but it seems that multiple options at the same character spot= is=20 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, bu= t=20 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. =2D-=20 Mel From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 03:05:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E35A4106566B for ; Wed, 4 Nov 2009 03:05:42 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7511F8FC1C for ; Wed, 4 Nov 2009 03:05:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Date:From:To:Cc:Subject:Message-ID: Reply-To:References:MIME-Version:Content-Type:In-Reply-To: Sender; bh=bhmq4U+yU6sQ9Dc1HBSV/sLZid0whwpxj4tsVN+2rMk=; b=lwi9b w33sbHupAD2EZbqm/dGYWC3kh5dzzp85mpMs/8K6mSGdxNbh8g9pnCSXJhL6jGRi lpkaJZkusTYtpesjegU7upwwZInQ4vZRRdSWUAXQKnnSSXUuyUqY602NbOSG8ScT 8z9pRftNus1un+IVwZ2aN+tYifGQD1xQA5waPpG7ldenUOP3/JYsIE06norxNu1T HBACi4PPo+YP15374RrSbpNFGJCa/1ExTKjNQeBLbTdT4sVcKvEkWlI92zH6laSn 3FtO+zGqmOcJboLkXYPX1AqUMQRsjKClIiHW9S+8ueMfBm3teSKx3Wck6Xi7twzD FcZGwBWQyd51dP3fw== Received: from amnesiac.at.no.dns (ppp83-237-104-5.pppoe.mtu-net.ru [83.237.104.5]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1N5WBo-000EiL-21; Wed, 04 Nov 2009 06:05:40 +0300 Date: Wed, 4 Nov 2009 06:05:44 +0300 From: Eygene Ryabinkin To: Mel Flynn Message-ID: References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/3yNEOqWowh/8j+e" Content-Disposition: inline In-Reply-To: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Sender: rea-fbsd@codelabs.ru X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Issue with grep -i (on i386 only?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 03:05:43 -0000 --/3yNEOqWowh/8j+e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 {_.-``-' {_/ # --/3yNEOqWowh/8j+e-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 08:31:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C88106566B for ; Wed, 4 Nov 2009 08:31:35 +0000 (UTC) (envelope-from olivermahmoudi@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDD78FC1F for ; Wed, 4 Nov 2009 08:31:34 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so728831fgb.13 for ; Wed, 04 Nov 2009 00:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gBMLAlj3yzG1V3oNDlVcyp8FJW1fY3UulSKWBIMPUT8=; b=fkv2HuKsAtbufjYHadfvUxrsKTdMyF5eHIBb2WgrBpA2Q9d7npmIRLTKtNJJox1/A8 ZBik5bLQm4Qq4aT3LPO3fUCEB1LTPIyVdutRGt2uTp2EOIOoawmj/V6LELyah2CjvwhV zqx4Ix2pqkqttQMwqc26EaZ/jh7PAaUMO01iU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=On6XqDAkSWH3Tcs8ZAqtPwP1laQNeL3LyY4pgJ7yWq1XCAfGQ/n1iFdph/GVa2993P iDpqhg2bLyw034FYl1Mh5kA42zta5PRNa/8+Fw+FE2Mp/wX5M28HWrhCGnJlhqZPuMud N9iCXpoEMBAPmaek45InBnvtZYcW8ltI74KNU= MIME-Version: 1.0 Received: by 10.239.182.164 with SMTP id q36mr125737hbg.87.1257323493868; Wed, 04 Nov 2009 00:31:33 -0800 (PST) In-Reply-To: <4AE60F70.9070808@FreeBSD.org> References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> Date: Wed, 4 Nov 2009 09:31:33 +0100 Message-ID: <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> From: Oliver Mahmoudi To: Gabor Kovesdan , f.loeber@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: writing a FreeBSD C library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 08:31:35 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 08:43:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6547D106568B for ; Wed, 4 Nov 2009 08:43:38 +0000 (UTC) (envelope-from alexjeffburke@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id DD81A8FC21 for ; Wed, 4 Nov 2009 08:43:37 +0000 (UTC) Received: by ewy18 with SMTP id 18so337088ewy.43 for ; Wed, 04 Nov 2009 00:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FLYeTzN7mTBu0Jlezs1nptiP+cO5zybcD2YJ2nDXMnQ=; b=jrgRPRZcbXW/8HSkslw5QwgSczp/Gl471QL/t8ANoyNm5E1bSKbz60Gaq3XwgJ0smA 4XowOV1uXKfaypGYNwqlSXprVfKBoXimdAOgdD/L/4BPj7611h5pHBV3B4jKtLJE/djw pUoEDQK2oX9faM790lVfNy+bCGCpnrJaEc0PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=veJOsOVWJLfCNo9q6TsRW1aTieutD7Q1meAHuWhB5+O7fFFVed3tiu9KWEcBGXqbAd wB+gyaSPhm5NluxmW1U5yGafhEfxOm6/xdQPgwd55+maRZppcXr4PnAOO/Z5fP0a9CWk bLwXfTakkrYHXcUIWt0u3uixakojoQ17AZL4I= MIME-Version: 1.0 Received: by 10.213.100.138 with SMTP id y10mr1213327ebn.96.1257322340182; Wed, 04 Nov 2009 00:12:20 -0800 (PST) In-Reply-To: References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> Date: Wed, 4 Nov 2009 08:12:20 +0000 Message-ID: From: Alex Burke To: rea-fbsd@codelabs.ru Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Mel Flynn Subject: Re: Issue with grep -i (on i386 only?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 08:43:38 -0000 On Wednesday, November 4, 2009, Eygene Ryabinkin wro= te: > 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: >> =3D>>> 16777216 >> =C2=A0 =C2=A0 =3D>>> fgrep >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.04 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.03 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.00 sys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.05 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.03 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.01 sys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.02 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.00 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.00 sys >> =C2=A0 =C2=A0 =3D>>> pcregrep >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.26 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.21 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.02 sys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.26 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.22 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.02 sys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.44 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.35 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.01 sys >> =C2=A0 =C2=A0 =3D>>> grep >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.04 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.04 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.00 sys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 4.45 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 4.15 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.01 sys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 2.00 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 1.81 u= ser =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.00 sys <-- [fF][Oo][Oo] > > Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor: > ----- > =3D>>> 16777216 > =C2=A0 =C2=A0=3D>>> fgrep > =C2=A0 =C2=A0 =C2=A0 =C2=A00,09 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,04 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,05 sys > =C2=A0 =C2=A0 =C2=A0 =C2=A00,18 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,06 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,03 sys > =C2=A0 =C2=A0 =C2=A0 =C2=A00,05 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,01 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,04 sys > =C2=A0 =C2=A0=3D>>> pcregrep > =C2=A0 =C2=A0 =C2=A0 =C2=A00,47 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,29 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,07 sys > =C2=A0 =C2=A0 =C2=A0 =C2=A00,52 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,33 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,07 sys > =C2=A0 =C2=A0 =C2=A0 =C2=A00,77 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,45 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,03 sys > =C2=A0 =C2=A0=3D>>> grep > =C2=A0 =C2=A0 =C2=A0 =C2=A00,09 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,08 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,01 sys > =C2=A0 =C2=A0 =C2=A0 =C2=A00,10 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,04 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,05 sys > =C2=A0 =C2=A0 =C2=A0 =C2=A00,23 real =C2=A0 =C2=A0 =C2=A0 =C2=A0 0,12 us= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 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. =C2=A0The same stuff fo= r > the amd64, so in my case I don't see the difference in behaviour. =C2=A0S= o, > 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=3D4 sw=3D4 noet tw=3D78 ai >> >> PCREGREP=3D`which pcregrep` >> BSDGREP=3D`which bsdgrep` >> [ -n ${PCREGREP} ] && PCREGREP=3D`basename ${PCREGREP}` >> [ -n ${BSDGREP} ] && BSDGREP=3D`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 >> =C2=A0 =C2=A0 =C2=A0 echo "Need jot" >> =C2=A0 =C2=A0 =C2=A0 exit 1 >> fi >> if [ ! -x /usr/bin/rs ]; then >> =C2=A0 =C2=A0 =C2=A0 echo "Need rs" >> =C2=A0 =C2=A0 =C2=A0 exit 1 >> fi > > Probably this is better be written as > ----- > for prog in jot rs; do > =C2=A0 =C2=A0 =C2=A0 =C2=A0if [ -z "`which "$prog"`" ]; then > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "Need $prog" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exit 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0fi > done > ----- > because the latter code uses unqualified 'jot' and 'rs'. > >> for b in ${BYTES}; do >> =C2=A0 =C2=A0 =C2=A0 TMPFILE=3D`mktemp -t ${me}` >> =C2=A0 =C2=A0 =C2=A0 if [ ! -f ${TMPFILE} ]; then >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 echo Can\'t create tmp = files in ${TMPDIR:=3D"/tmp"} >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 exit 2 >> =C2=A0 =C2=A0 =C2=A0 fi >> =C2=A0 =C2=A0 =C2=A0 jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE} >> =C2=A0 =C2=A0 =C2=A0 echo "=3D>>> ${b}" >> =C2=A0 =C2=A0 =C2=A0 for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 echo " =C2=A0 =C2=A0=3D= >>> ${prog}" >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/bin/time ${prog} f= oo ${TMPFILE} >/dev/null >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/bin/time ${prog} -= i foo ${TMPFILE} >/dev/null >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/bin/time ${prog} '= [fF][Oo][Oo]' ${TMPFILE} >/dev/null >> =C2=A0 =C2=A0 =C2=A0 done >> =C2=A0 =C2=A0 =C2=A0 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. =C2=A0The code is simple: > ----- > TMPFILE=3D`mktemp -t ${me}` > if [ ! -f ${TMPFILE} ]; then > =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "Can't create tmp file in ${TMPDIR:=3D/t= mp}" > =C2=A0 =C2=A0 =C2=A0 =C2=A0exit 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 > =C2=A0_ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0___ =C2=A0= =C2=A0 =C2=A0 _.--. =C2=A0 # > =C2=A0\`.|\..----...-'` =C2=A0 `-._.-'_.-'` =C2=A0 # =C2=A0Remember that = it is hard > =C2=A0/ =C2=A0' ` =C2=A0 =C2=A0 =C2=A0 =C2=A0 , =C2=A0 =C2=A0 =C2=A0 __.-= -' =C2=A0 =C2=A0 =C2=A0# =C2=A0to read the on-line manual > =C2=A0)/' _/ =C2=A0 =C2=A0 \ =C2=A0 `-_, =C2=A0 / =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0# =C2=A0while single-stepping the kernel. > =C2=A0`-'" `"\_ =C2=A0,_.-;_.-\_ ', =C2=A0fsc/as =C2=A0 # > =C2=A0 =C2=A0 _.-'_./ =C2=A0 {_.' =C2=A0 ; / =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 # =C2=A0 =C2=A0-- FreeBSD Developers handbook > =C2=A0 =C2=A0{_.-``-' =C2=A0 =C2=A0 =C2=A0 =C2=A0 {_/ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0# > From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 09:27:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D48031065670; Wed, 4 Nov 2009 09:27:31 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 281A58FC0C; Wed, 4 Nov 2009 09:27:30 +0000 (UTC) Received: by bwz5 with SMTP id 5so8821150bwz.3 for ; Wed, 04 Nov 2009 01:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cyFGNfqvkW8WokrWtU3aGFUVjTklc2LuAgIPlaovwzE=; b=oc4ZDnGC9kwhR/d3vsbjMZxnRuurng5qkreMZ8qfrK3+HmL4bKn8PbHvjmV/of4q1f Nxw0BK1tH93cq9XfItF9zxH02zVn/lgsKwQcF0cEwFQ52EBPCIR+EmjAf/RgCTeD7+Ie h9lw7Kt/xvKrJCOayoealMRj91FTicY5bLkcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r5MsOT1H6YvBHFI1YIxl7GiYU8yF+KcjoRjVGKDobAZpig6yxUCS2L1UnEtEbfRVuX JNO6oR0OGASsthUKobLS0b6m+VZOc/jU7lIqKhe+7E5WaW99vgSLY+BX8rgmR6hL5Nt3 7aJBSkRuZt7eeWzHL5k+vCplDs2+tebFwh04g= MIME-Version: 1.0 Received: by 10.204.34.3 with SMTP id j3mr1167924bkd.23.1257325345505; Wed, 04 Nov 2009 01:02:25 -0800 (PST) In-Reply-To: <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> Date: Wed, 4 Nov 2009 10:02:25 +0100 Message-ID: From: Harald Servat To: Oliver Mahmoudi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, f.loeber@googlemail.com, Gabor Kovesdan Subject: Re: writing a FreeBSD C library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:27:32 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 12:03:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEC991065672; Wed, 4 Nov 2009 12:03:57 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7CAD58FC1C; Wed, 4 Nov 2009 12:03:57 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AA2AA6D41B; Wed, 4 Nov 2009 12:03:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7061B844E9; Wed, 4 Nov 2009 13:03:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Harald Servat References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> Date: Wed, 04 Nov 2009 13:03:54 +0100 In-Reply-To: (Harald Servat's message of "Wed, 4 Nov 2009 10:02:25 +0100") Message-ID: <86bpjih4yd.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, f.loeber@googlemail.com, Oliver Mahmoudi , Gabor Kovesdan Subject: Re: writing a FreeBSD C library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 12:03:57 -0000 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 12:49:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEDE1106566B for ; Wed, 4 Nov 2009 12:49:58 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 882B58FC1C for ; Wed, 4 Nov 2009 12:49:58 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 93AAB7E853; Wed, 4 Nov 2009 03:49:56 -0900 (AKST) From: Mel Flynn To: freebsd-hackers@freebsd.org, rea-fbsd@codelabs.ru Date: Wed, 4 Nov 2009 13:49:54 +0100 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; i386; ; ) References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911041349.54943.mel.flynn+fbsd.hackers@mailing.thruhere.net> Cc: Subject: Re: Issue with grep -i (on i386 only?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 12:49:59 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 13:18:32 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2C48106568B; Wed, 4 Nov 2009 13:18:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A2AB78FC1B; Wed, 4 Nov 2009 13:18:32 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4F15E46B1A; Wed, 4 Nov 2009 08:18:32 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A970A8A01B; Wed, 4 Nov 2009 08:18:30 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 4 Nov 2009 08:12:18 -0500 User-Agent: KMail/1.9.7 References: <20091103172452.GU1293@hoeg.nl> In-Reply-To: <20091103172452.GU1293@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911040812.18712.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 04 Nov 2009 08:18:30 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: alc@freebsd.org, Ed Schouten , Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 13:18:32 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 13:52:53 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733C7106568D; Wed, 4 Nov 2009 13:52:53 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id C8A738FC23; Wed, 4 Nov 2009 13:52:52 +0000 (UTC) Received: by bwz5 with SMTP id 5so9112140bwz.3 for ; Wed, 04 Nov 2009 05:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KVpHlYV0vjDAzMFJSbuldvINAlKvTGfC8OOYY4CEivU=; b=OtTo2Rrq+wBbxg1IanZVAvfrGgVuFrGXrAuKOX7m4Sm+kMlh4xUKvcCdLNCptinlV1 aS4CgBwsUgTI75ey/Q3GJLAuGyiZ7Zk17LQ5/5kbDJcdCavQrkaERxJWzXaINU0JlPD0 DvXmHDmHgbW3K6OAqk4FpIxKvA43waD1Jyqg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uQEjbGRaxgaNII2spw7CJYGhsrBWY/dOMbc3bY7xgJAnWOteU6w95tyer2d3jet3hw kW3S38ptN0hMRNspDNuU9Jhyj1uMscduVJLks3toMWx+un/IkYjOt+6dOeyYsNvUcTLD G8y27JE58w/0x6TDcHlePGI+CAC1PEgj44jRM= MIME-Version: 1.0 Received: by 10.204.29.15 with SMTP id o15mr1457287bkc.145.1257342771742; Wed, 04 Nov 2009 05:52:51 -0800 (PST) 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> Date: Wed, 4 Nov 2009 14:52:51 +0100 Message-ID: From: Harald Servat To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, f.loeber@googlemail.com, Oliver Mahmoudi , Gabor Kovesdan Subject: Re: writing a FreeBSD C library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 13:52:53 -0000 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=F8rgrav > 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=F8rgrav - des@des.no > --=20 _________________________________________________________________ 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 16:26:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF94106566C; Wed, 4 Nov 2009 16:26:47 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 4D32C8FC1E; Wed, 4 Nov 2009 16:26:47 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 41CE31CC0C; Wed, 4 Nov 2009 17:26:46 +0100 (CET) Date: Wed, 4 Nov 2009 17:26:46 +0100 From: Ed Schouten To: John Baldwin Message-ID: <20091104162646.GZ1293@hoeg.nl> References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hgy5D1otryeNPdmY" Content-Disposition: inline In-Reply-To: <200911040812.18712.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:26:47 -0000 --hgy5D1otryeNPdmY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * 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. --=20 Ed Schouten WWW: http://80386.nl/ --hgy5D1otryeNPdmY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrxq0YACgkQ52SDGA2eCwWxPwCdFnFuM4q0CK4TqxukEbDQypj9 wxUAnjbJTX53au+a9mGWQVzcysP/eJ/8 =jpk9 -----END PGP SIGNATURE----- --hgy5D1otryeNPdmY-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 18:25:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C57E0106566B; Wed, 4 Nov 2009 18:25:21 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 994DE8FC22; Wed, 4 Nov 2009 18:25:21 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 1E5DB2C2DA2; Wed, 4 Nov 2009 12:25:21 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id caT3E3XXNiJW; Wed, 4 Nov 2009 12:25:13 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 1B0F52C2D9A; Wed, 4 Nov 2009 12:25:13 -0600 (CST) Message-ID: <4AF1C707.6000706@cs.rice.edu> Date: Wed, 04 Nov 2009 12:25:11 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Ed Schouten References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> <20091104162646.GZ1293@hoeg.nl> In-Reply-To: <20091104162646.GZ1293@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:25:21 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 18:34:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DFC10656A6; Wed, 4 Nov 2009 18:34:35 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 823B18FC30; Wed, 4 Nov 2009 18:34:35 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9176B1CCCB; Wed, 4 Nov 2009 19:34:34 +0100 (CET) Date: Wed, 4 Nov 2009 19:34:34 +0100 From: Ed Schouten To: Alan Cox Message-ID: <20091104183434.GB1293@hoeg.nl> References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> <20091104162646.GZ1293@hoeg.nl> <4AF1C707.6000706@cs.rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+31Goo6fsQAntfNs" Content-Disposition: inline In-Reply-To: <4AF1C707.6000706@cs.rice.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:34:36 -0000 --+31Goo6fsQAntfNs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 spac= e */ +#ifndef _KERNEL +#define MAP_ANONYMOUS MAP_ANON /* For compatibility. */ +#endif /* !_KERNEL */ =20 /* * Extended flags --=20 Ed Schouten WWW: http://80386.nl/ --+31Goo6fsQAntfNs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrxyToACgkQ52SDGA2eCwXB0QCfer7jg+fLcYA3wy0j1oTkTK5k EeAAn0jJHNJf+/wfrm+RlKqzZ9+9vtY4 =kWRu -----END PGP SIGNATURE----- --+31Goo6fsQAntfNs-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 18:42:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 265E51065672; Wed, 4 Nov 2009 18:42:37 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id ED72A8FC14; Wed, 4 Nov 2009 18:42:36 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 7D10F2C2D3C; Wed, 4 Nov 2009 12:42:36 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wczLjmLu-Mhp; Wed, 4 Nov 2009 12:42:28 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 6A3FA2C2D0A; Wed, 4 Nov 2009 12:42:28 -0600 (CST) Message-ID: <4AF1CB11.2090503@cs.rice.edu> Date: Wed, 04 Nov 2009 12:42:25 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Ed Schouten References: <20091103172452.GU1293@hoeg.nl> <200911040812.18712.jhb@freebsd.org> <20091104162646.GZ1293@hoeg.nl> <4AF1C707.6000706@cs.rice.edu> <20091104183434.GB1293@hoeg.nl> In-Reply-To: <20091104183434.GB1293@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:42:37 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 19:09:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 171231065670; Wed, 4 Nov 2009 19:09:29 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD728FC16; Wed, 4 Nov 2009 19:09:27 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,682,1249250400"; d="scan'208";a="287375005" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 04 Nov 2009 20:09:26 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5BBA31B0766; Wed, 4 Nov 2009 20:09:26 +0100 (CET) Date: Wed, 04 Nov 2009 20:09:25 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alan Cox , Ed Schouten Message-ID: In-Reply-To: <4AF1CB11.2090503@cs.rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Alexander Best Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:09:29 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 20:26:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E2B1065670 for ; Wed, 4 Nov 2009 20:26:30 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id C29C88FC1D for ; Wed, 4 Nov 2009 20:26:29 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,682,1249250400"; d="scan'208";a="228089306" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 04 Nov 2009 21:26:28 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 43B091B0751; Wed, 4 Nov 2009 21:26:28 +0100 (CET) Date: Wed, 04 Nov 2009 21:26:27 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:26:30 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 21:44:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88163106566B; Wed, 4 Nov 2009 21:44:24 +0000 (UTC) (envelope-from kayve@sfsu.edu) Received: from iron3.sfsu.edu (iron3.sfsu.edu [130.212.10.128]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5758FC14; Wed, 4 Nov 2009 21:44:24 +0000 (UTC) X-Inbound-SFSU: False X-onepass: IPPSC X-From-SFSU: True X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKd58UqC1B9C/2dsb2JhbADQKwEJBYVziEyCVIFpBINYgTCEHQ Received: from edg02.sfsu.edu ([130.212.31.66]) by iron3.sfsu.edu with ESMTP; 04 Nov 2009 13:16:01 -0800 Received: from EHB02.ad.sfsu.edu (130.212.31.84) by EDG02.sfsu.edu (130.212.31.66) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 13:16:01 -0800 Received: from smtp01.sfsu.edu (130.212.10.100) by ehb.ad.sfsu.edu (130.212.31.28) with Microsoft SMTP Server id 8.2.176.0; Wed, 4 Nov 2009 13:16:01 -0800 Received: from libra.sfsu.edu ([130.212.10.238]) by mail05a.sfsu.edu (Lotus Domino Release 7.0.4HF59) with ESMTP id 2009110413160021-2578 ; Wed, 4 Nov 2009 13:16:00 -0800 Date: Wed, 4 Nov 2009 13:15:59 -0800 From: KAYVEN RIESE To: Harald Servat In-Reply-To: Message-ID: References: <6b4b2d2c0910261308i367569dbg887d7c713bf20ad1@mail.gmail.com> <4AE60F70.9070808@FreeBSD.org> <6b4b2d2c0911040031h2175011dy949e4d368ffbb997@mail.gmail.com> <86bpjih4yd.fsf@ds4.des.no> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MAIL05a/SERVERS/SFSU(Release 7.0.4HF59 | August 11, 2009) at 11/04/2009 13:16:00, Serialize by Router on SMTP01/SERVERS/SFSU(Release 7.0.4|March 23, 2009) at 11/04/2009 13:16:00, Serialize complete at 11/04/2009 13:16:00 Content-Type: multipart/mixed; boundary="-559023410-851401618-1257369359=:3147" Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , f.loeber@googlemail.com, Oliver Mahmoudi , Gabor Kovesdan , freebsd-hackers@freebsd.org Subject: Re: writing a FreeBSD C library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 21:44:24 -0000 ---559023410-851401618-1257369359=:3147 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Type: text/plain; charset="ISO-8859-1"; format=flowed On Wed, 4 Nov 2009, Harald Servat wrote: > Oh, yes! You're right DES. They look the same to me here in the web-brows= er > :) 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=F8rgrav > >> 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=F8rgrav - des@des.no >> > > > > --=20 > _________________________________________________________________ > 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 *----------------------------------------------------------* ---559023410-851401618-1257369359=:3147-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 23:03:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7086106568D for ; Wed, 4 Nov 2009 23:03:54 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6328FC20 for ; Wed, 4 Nov 2009 23:03:54 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id B8BDE7E853 for ; Wed, 4 Nov 2009 14:03:52 -0900 (AKST) From: Mel Flynn To: freebsd-hackers@freebsd.org Date: Thu, 5 Nov 2009 00:03:50 +0100 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; i386; ; ) References: <200911032122.28905.mel.flynn+fbsd.hackers@mailing.thruhere.net> <200911041349.54943.mel.flynn+fbsd.hackers@mailing.thruhere.net> In-Reply-To: <200911041349.54943.mel.flynn+fbsd.hackers@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911050003.51080.mel.flynn+fbsd.hackers@mailing.thruhere.net> Subject: Grep -i and UTF-8 (Was: Re: Issue with grep -i (on i386 only?)) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 23:03:54 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Wed Nov 4 23:07:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9677D1065672; Wed, 4 Nov 2009 23:07:30 +0000 (UTC) (envelope-from dclark@engr.scu.edu) Received: from endor.engr.scu.edu (smtp.engr.scu.edu [129.210.16.13]) by mx1.freebsd.org (Postfix) with ESMTP id 64B9F8FC08; Wed, 4 Nov 2009 23:07:28 +0000 (UTC) Received: from nova32.dc.engr.scu.edu (nova32.dc.engr.scu.edu [129.210.16.29]) by endor.engr.scu.edu (8.13.6/8.13.6) with ESMTP id nA4N7QK9001016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 15:07:28 -0800 Received: from localhost (dclark@localhost) by nova32.dc.engr.scu.edu (8.13.6/8.13.6) with ESMTP id nA4N6HVO029738; Wed, 4 Nov 2009 15:06:17 -0800 (PST) X-Authentication-Warning: nova32.dc.engr.scu.edu: dclark owned process doing -bs Date: Wed, 4 Nov 2009 15:06:17 -0800 (PST) From: "Dorr H. Clark" X-Sender: dclark@nova32.dc.engr.scu.edu To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 04 Nov 2009 23:32:51 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: gdb/libkvm problem - can someone explain this? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 23:07:30 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Thu Nov 5 01:17:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B18106566B for ; Thu, 5 Nov 2009 01:17:17 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id A59078FC16 for ; Thu, 5 Nov 2009 01:17:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,683,1249250400"; d="scan'208";a="17640006" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 05 Nov 2009 02:17:15 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id A56431B07BE; Thu, 5 Nov 2009 02:17:15 +0100 (CET) Date: Thu, 05 Nov 2009 02:17:15 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 01:17:17 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Thu Nov 5 09:12:32 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7051065670; Thu, 5 Nov 2009 09:12:32 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0755B8FC13; Thu, 5 Nov 2009 09:12:32 +0000 (UTC) Received: from [195.4.92.24] (helo=14.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N5yOK-0005Bx-CT; Thu, 05 Nov 2009 10:12:28 +0100 Received: from tbfde.t.pppool.de ([89.55.191.222]:22223 helo=ernst.jennejohn.org) by 14.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N5yOK-0007hW-3f; Thu, 05 Nov 2009 10:12:28 +0100 Date: Thu, 5 Nov 2009 10:12:26 +0100 From: Gary Jennejohn To: "Dorr H. Clark" Message-ID: <20091105101226.5c6ef961@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: gdb/libkvm problem - can someone explain this? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 09:12:32 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Thu Nov 5 13:56:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F435106566C; Thu, 5 Nov 2009 13:56:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3100F8FC25; Thu, 5 Nov 2009 13:56:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CF59D46B2E; Thu, 5 Nov 2009 08:56:36 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 13D008A020; Thu, 5 Nov 2009 08:56:36 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 5 Nov 2009 08:56:12 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911050856.13188.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 05 Nov 2009 08:56:36 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, "Dorr H. Clark" Subject: Re: gdb/libkvm problem - can someone explain this? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:56:37 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Thu Nov 5 18:03:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF56106566B; Thu, 5 Nov 2009 18:03:44 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id B3A008FC08; Thu, 5 Nov 2009 18:03:44 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 025032C2D34; Thu, 5 Nov 2009 12:03:44 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id px+9oMJIRvM3; Thu, 5 Nov 2009 12:03:36 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id EF32F2C2D3C; Thu, 5 Nov 2009 12:03:35 -0600 (CST) Message-ID: <4AF31377.60405@cs.rice.edu> Date: Thu, 05 Nov 2009 12:03:35 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Ed Schouten , freebsd-hackers@freebsd.org Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:03:45 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 01:06:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51B13106566B; Fri, 6 Nov 2009 01:06:24 +0000 (UTC) (envelope-from dclark@engr.scu.edu) Received: from endor.engr.scu.edu (smtp.engr.scu.edu [129.210.16.13]) by mx1.freebsd.org (Postfix) with ESMTP id 381B98FC18; Fri, 6 Nov 2009 01:06:23 +0000 (UTC) Received: from nova48.dc.engr.scu.edu (nova48.dc.engr.scu.edu [129.210.16.45]) by endor.engr.scu.edu (8.13.6/8.13.6) with ESMTP id nA616LCL032279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 17:06:23 -0800 Received: from localhost (dclark@localhost) by nova48.dc.engr.scu.edu (8.13.6/8.13.6) with ESMTP id nA616LEX013858; Thu, 5 Nov 2009 17:06:21 -0800 (PST) X-Authentication-Warning: nova48.dc.engr.scu.edu: dclark owned process doing -bs Date: Thu, 5 Nov 2009 17:06:21 -0800 (PST) From: "Dorr H. Clark" X-Sender: dclark@nova48.dc.engr.scu.edu To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 06 Nov 2009 03:08:12 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: resource leak in fifo_vnops.c: 6.x/7.x/8.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 01:06:24 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 05:12:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE48B106566B for ; Fri, 6 Nov 2009 05:12:42 +0000 (UTC) (envelope-from cronfy@sprinthost.ru) Received: from odin.from.sh (odin.from.sh [80.93.50.112]) by mx1.freebsd.org (Postfix) with ESMTP id A356D8FC1C for ; Fri, 6 Nov 2009 05:12:42 +0000 (UTC) Received: from odin.from.sh ([80.93.50.112]) by odin.from.sh with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N6H73-000Gdl-Th for freebsd-hackers@freebsd.org; Fri, 06 Nov 2009 08:11:53 +0300 Received: from [194.8.176.106] (helo=[192.168.0.3]) by odin.from.sh with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N6H6y-000Gcm-KC for freebsd-hackers@freebsd.org; Fri, 06 Nov 2009 08:11:48 +0300 Message-ID: <4AF3B013.5080205@sprinthost.ru> Date: Fri, 06 Nov 2009 08:11:47 +0300 From: cronfy User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: resource leak in fifo_vnops.c: 6.x/7.x/8.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 05:12:43 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 08:57:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A6A8106566B; Fri, 6 Nov 2009 08:57:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id CB66E8FC13; Fri, 6 Nov 2009 08:57:21 +0000 (UTC) Received: by bwz5 with SMTP id 5so924473bwz.3 for ; Fri, 06 Nov 2009 00:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=8yGk30zCWtAw5KWeCpJNFfXPDY7F2i5wVxLEhaS6HC0=; b=px/CGiSkEngTqR+yUd9iB/Hn+arFJL4UXw7FgtH9ToTAJpYyJ/rnyd2dk+w10dkrVz u978rjd1sSJFb0Br1NagU7+JO01eZJY/CCRJkezpQrm1dD5sj+FhV5Lutzgb5cQGJGdu 6LS0AyJ+ZYqHun02SYL5B20idbO01S1/fFh80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uHV565ejv0kWU2BDwKr+/oF/+8XeSsKQlsUPlJFB7l3J4MbMwqeszyflxodFxz5IRc BzhCrGb6hoQvhjLYbZGwVnnMDrclmUOvQQG/nbfssfGrOYJ1La22a4kU52GSvRm5aXES xBzG2G9V2UFwF1BPUqofgJJv/HvPJaVx0JanU= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.58.208 with SMTP id i16mr588527fah.22.1257497840612; Fri, 06 Nov 2009 00:57:20 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Nov 2009 09:57:20 +0100 X-Google-Sender-Auth: f936111433c45289 Message-ID: <3bbf2fe10911060057t5ebfb330n486c80018826fa93@mail.gmail.com> From: Attilio Rao To: "Dorr H. Clark" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: resource leak in fifo_vnops.c: 6.x/7.x/8.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 08:57:22 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 14:33:07 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB532106566B for ; Fri, 6 Nov 2009 14:33:07 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id A73058FC0A for ; Fri, 6 Nov 2009 14:33:06 +0000 (UTC) Received: (qmail 71702 invoked from network); 6 Nov 2009 14:06:25 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 6 Nov 2009 14:06:25 -0000 Message-ID: <4AF42D61.6050403@FreeBSD.org> Date: Fri, 06 Nov 2009 15:06:25 +0100 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:33:07 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 15:32:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E4711065670; Fri, 6 Nov 2009 15:32:33 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8C78E8FC1A; Fri, 6 Nov 2009 15:32:32 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,694,1249250400"; d="txt'?scan'208";a="17789749" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 06 Nov 2009 16:32:31 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 09F0F1B07BE; Fri, 6 Nov 2009 16:32:30 +0100 (CET) Date: Fri, 06 Nov 2009 16:32:22 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alex Dupre , Alexander Best Message-ID: In-Reply-To: <4AF42D61.6050403@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2009110615322280e26a0b00003ff9-a_best01+ Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 15:32:33 -0000 This is a MIME encoded multipart message. --+permail-2009110615322280e26a0b00003ff9-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 --+permail-2009110615322280e26a0b00003ff9-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="vfslookup.c.patch.txt" LS0tIHZmc19sb29rdXAuYwkyMDA5LTExLTA2IDE2OjE0OjQxLjAwMDAwMDAwMCArMDEwMAorKysg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX2xvb2t1cC5jCTIwMDktMTEtMDYgMTY6MTM6MTkuMDAwMDAw MDAwICswMTAwCkBAIC0zNSw3ICszNSw3IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy9jZGVmcy5o PgotX19GQlNESUQoIiRGcmVlQlNEJCIpOworX19GQlNESUQoIiRGcmVlQlNEOiBoZWFkL3N5cy9r ZXJuL3Zmc19sb29rdXAuYyAxOTU5MzkgMjAwOS0wNy0yOSAwNzo0NDo0M1ogcndhdHNvbiAkIik7 CiAKICNpbmNsdWRlICJvcHRfa2R0cmFjZS5oIgogI2luY2x1ZGUgIm9wdF9rdHJhY2UuaCIKQEAg LTU2Myw4ICs1NjMsMTIgQEAKIAkJCWVycm9yID0gRU5PVERJUjsKIAkJCWdvdG8gYmFkOwogCQl9 Ci0JCWlmIChjbnAtPmNuX25hbWVpb3AgIT0gTE9PS1VQKSB7Ci0JCQllcnJvciA9IEVJU0RJUjsK KwkJaWYgKGNucC0+Y25fbmFtZWlvcCAhPSBMT09LVVAgJiYgY25wLT5jbl9uYW1laW9wID09IERF TEVURSkgeworCQkJZXJyb3IgPSBFQlVTWTsKKwkJCWdvdG8gYmFkOworCQl9CisJCWlmIChjbnAt PmNuX25hbWVpb3AgIT0gTE9PS1VQICYmIGNucC0+Y25fbmFtZWlvcCA9PSBDUkVBVEUpIHsKKwkJ CWVycm9yID0gRUVYSVNUOwogCQkJZ290byBiYWQ7CiAJCX0KIAkJaWYgKHdhbnRwYXJlbnQpIHsK --+permail-2009110615322280e26a0b00003ff9-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 15:45:52 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A43C6106566B for ; Fri, 6 Nov 2009 15:45:52 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id C92818FC0A for ; Fri, 6 Nov 2009 15:45:50 +0000 (UTC) Received: (qmail 22182 invoked from network); 6 Nov 2009 15:45:49 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 6 Nov 2009 15:45:49 -0000 Message-ID: <4AF444AC.1030507@FreeBSD.org> Date: Fri, 06 Nov 2009 16:45:48 +0100 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 15:45:52 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 16:03:00 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D94D51065676; Fri, 6 Nov 2009 16:03:00 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0016F8FC14; Fri, 6 Nov 2009 16:02:59 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,694,1249250400"; d="scan'208";a="17792038" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 06 Nov 2009 17:02:59 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 130151B07BE; Fri, 6 Nov 2009 17:02:59 +0100 (CET) Date: Fri, 06 Nov 2009 17:02:58 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alex Dupre , Alexander Best Message-ID: In-Reply-To: <4AF444AC.1030507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:03:00 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 16:15:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19BD7106568B; Fri, 6 Nov 2009 16:15:58 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 643D58FC1E; Fri, 6 Nov 2009 16:15:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,694,1249250400"; d="scan'208";a="287561269" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 06 Nov 2009 17:15:55 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id D96461B07BE; Fri, 6 Nov 2009 17:15:55 +0100 (CET) Date: Fri, 06 Nov 2009 17:15:54 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: , Alexander Best Message-ID: In-Reply-To: <20091106170853.7d0b0b6f@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Alexander Best , Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:15:58 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 16:43:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB311065670; Fri, 6 Nov 2009 16:43:14 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id CCBC68FC30; Fri, 6 Nov 2009 16:43:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,694,1249250400"; d="txt'?scan'208";a="287563478" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 06 Nov 2009 17:43:13 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id E3F541B07BE; Fri, 6 Nov 2009 17:43:12 +0100 (CET) Date: Fri, 06 Nov 2009 17:43:06 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: , Alexander Best Message-ID: In-Reply-To: <20091106170853.7d0b0b6f@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2009110616430680e26a0b000006fe-a_best01+ Cc: freebsd-hackers@FreeBSD.org, Alexander Best , Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:43:14 -0000 This is a MIME encoded multipart message. --+permail-2009110616430680e26a0b000006fe-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 --+permail-2009110616430680e26a0b000006fe-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="vfslookup.c.patch.txt" LS0tIHZmc19sb29rdXAuYwkyMDA5LTExLTA2IDE2OjE0OjQxLjAwMDAwMDAwMCArMDEwMAorKysg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX2xvb2t1cC5jCTIwMDktMTEtMDYgMTc6NDE6NDAuMDAwMDAw MDAwICswMTAwCkBAIC0zNSw3ICszNSw3IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy9jZGVmcy5o PgotX19GQlNESUQoIiRGcmVlQlNEJCIpOworX19GQlNESUQoIiRGcmVlQlNEOiBoZWFkL3N5cy9r ZXJuL3Zmc19sb29rdXAuYyAxOTU5MzkgMjAwOS0wNy0yOSAwNzo0NDo0M1ogcndhdHNvbiAkIik7 CiAKICNpbmNsdWRlICJvcHRfa2R0cmFjZS5oIgogI2luY2x1ZGUgIm9wdF9rdHJhY2UuaCIKQEAg LTU2Myw2ICs1NjMsMTUgQEAKIAkJCWVycm9yID0gRU5PVERJUjsKIAkJCWdvdG8gYmFkOwogCQl9 CisJCWlmIChjbnAtPmNuX25hbWVpb3AgPT0gREVMRVRFIHx8IGNucC0+Y25fbmFtZWlvcCA9PSBS RU5BTUUpIHsKKwkJCWVycm9yID0gRUJVU1k7CisJCQlnb3RvIGJhZDsKKwkJfQorCQlpZiAoY25w LT5jbl9uYW1laW9wID09IENSRUFURSkgeworCQkJZXJyb3IgPSBFRVhJU1Q7CisJCQlnb3RvIGJh ZDsKKwkJfQorCQkvKiBYWFggVGhpcyBibG9jayBtaWdodCBub3QgYmUgbmVlZGVkLiAqLwogCQlp ZiAoY25wLT5jbl9uYW1laW9wICE9IExPT0tVUCkgewogCQkJZXJyb3IgPSBFSVNESVI7CiAJCQln b3RvIGJhZDsK --+permail-2009110616430680e26a0b000006fe-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 16:08:56 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE21C106568F; Fri, 6 Nov 2009 16:08:56 +0000 (UTC) (envelope-from garyj@denx.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 55B088FC12; Fri, 6 Nov 2009 16:08:56 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N6RMs-00029S-TN; Fri, 06 Nov 2009 17:08:54 +0100 Received: from tc89e.t.pppool.de ([89.55.200.158]:40643 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N6RMs-0002Zc-HP; Fri, 06 Nov 2009 17:08:54 +0100 Date: Fri, 6 Nov 2009 17:08:53 +0100 From: Gary Jennejohn To: Alexander Best Message-ID: <20091106170853.7d0b0b6f@ernst.jennejohn.org> In-Reply-To: References: <4AF42D61.6050403@FreeBSD.org> Organization: DENX Softwre Engineering GmbH X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Nov 2009 16:44:21 +0000 Cc: freebsd-hackers@FreeBSD.org, Alexander Best , Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: garyj@denx.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:08:57 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 17:23:12 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D45106566B; Fri, 6 Nov 2009 17:23:12 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id C794C8FC0C; Fri, 6 Nov 2009 17:23:11 +0000 (UTC) Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N6SWk-0002lF-DB; Fri, 06 Nov 2009 18:23:10 +0100 Received: from tc89e.t.pppool.de ([89.55.200.158]:55359 helo=ernst.jennejohn.org) by 7.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N6SWk-0002g1-4e; Fri, 06 Nov 2009 18:23:10 +0100 Date: Fri, 6 Nov 2009 18:23:08 +0100 From: Gary Jennejohn To: Alexander Best Message-ID: <20091106182308.14dffc50@ernst.jennejohn.org> In-Reply-To: References: <20091106170853.7d0b0b6f@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:23:12 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 17:42:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9240E1065696; Fri, 6 Nov 2009 17:42:30 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8772D8FC14; Fri, 6 Nov 2009 17:42:29 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,694,1249250400"; d="scan'208";a="17799129" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 06 Nov 2009 18:42:28 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0F2C51B0751; Fri, 6 Nov 2009 18:42:27 +0100 (CET) Date: Fri, 06 Nov 2009 18:42:27 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: , Alexander Best Message-ID: In-Reply-To: <20091106182308.14dffc50@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:42:30 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 17:52:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE9D106566B; Fri, 6 Nov 2009 17:52:42 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id A11BD8FC16; Fri, 6 Nov 2009 17:52:41 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,694,1249250400"; d="scan'208";a="287569039" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 06 Nov 2009 18:52:40 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id B2BBF1B0751; Fri, 6 Nov 2009 18:52:40 +0100 (CET) Date: Fri, 06 Nov 2009 18:52:40 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alexander Best , , Alexander Best Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:52:42 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 19:19:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E811065670 for ; Fri, 6 Nov 2009 19:19:52 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: from web113204.mail.gq1.yahoo.com (web113204.mail.gq1.yahoo.com [98.136.165.125]) by mx1.freebsd.org (Postfix) with SMTP id 3A8A68FC23 for ; Fri, 6 Nov 2009 19:19:52 +0000 (UTC) Received: (qmail 20493 invoked by uid 60001); 6 Nov 2009 19:19:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1257535191; bh=uo4QdrN+Fy4rE7Sc07oZHbK75BE6W3Qpa8hC3k4MUmc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=LZTuzHGx4JEymKstvF2WUA/MzKLQRWb3kcKzA8EB0XQh4aQgqAOzUv03KxpwHcmjRWgQjI+mllCmwbXlGnsiqfuB0mS3pHBBcyKbO7XiQYijAwWUtv1cf7D9X77CDm2Hd47S9R0bmcP7iBA5YE1mHCsEtO2SGJVCPeUpCLUqaAg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=PB78vxugJYdRiVDrdEQJNCLqP3gjVniYH4u0/rnnlvAKzItr2K+FaT7mHzdhMfm86mXPFX9Z1eIhD8WXMNtNXNCf13Mh19Maq68dnVIAKc/QtAQtyXIcNShPF7A0W+DTZuRhOooG80se+jHEkfYFqJOMzHEoCWQ72lTMq6l4b7A=; Message-ID: <761362.20406.qm@web113204.mail.gq1.yahoo.com> X-YMail-OSG: Ni7qblcVM1nH6lf4b0xzqOEavyYDS5QY4gPFP5_xUUcVHg9oEJ0HS3WY660zVWFG0aGzbJCqwHEJEcykiEtDb50JyjcCIbP2EK82iRVrBpUPdVHoYi33EdTMmI0dEGUkQIuumJmAA3NXy8.tjst5s5C4vB8nDr9ZshQ9Jv3F4.uL.hO7gaUFPQdASw0H7FeNE0qwYjJYuU1.tugOL2d1IwdeWOp8xY8lmoNKMOsDvFO.9A0qF3.bFps_VQExzkwt.yc- Received: from [128.55.19.49] by web113204.mail.gq1.yahoo.com via HTTP; Fri, 06 Nov 2009 11:19:51 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.361.4 Date: Fri, 6 Nov 2009 11:19:51 -0800 (PST) From: Trever To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Why is default value of NKPT so small? mfsroot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:19:52 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 19:27:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A841065679 for ; Fri, 6 Nov 2009 19:27:58 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1DB8FC13 for ; Fri, 6 Nov 2009 19:27:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,695,1249250400"; d="scan'208";a="228276096" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 06 Nov 2009 20:27:55 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id A988F1B07BE; Fri, 6 Nov 2009 20:27:55 +0100 (CET) Date: Fri, 06 Nov 2009 20:27:55 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:27:58 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 21:09:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D76C1065672 for ; Fri, 6 Nov 2009 21:09:59 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 44ABF8FC0C for ; Fri, 6 Nov 2009 21:09:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,695,1249250400"; d="txt'?scan'208";a="287581654" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 06 Nov 2009 22:09:56 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4FA8E1B0766; Fri, 6 Nov 2009 22:09:56 +0100 (CET) Date: Fri, 06 Nov 2009 22:09:49 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: , Alexander Best Message-ID: In-Reply-To: <20091106182308.14dffc50@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20091106210949f0889e8400000862-a_best01+ Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 21:09:59 -0000 This is a MIME encoded multipart message. --+permail-20091106210949f0889e8400000862-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 --+permail-20091106210949f0889e8400000862-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="vfssyscalls.c.patch.txt" LS0tIHZmc19zeXNjYWxscy5jCTIwMDktMTEtMDYgMjI6MDc6MDguMDAwMDAwMDAwICswMTAwCisr KyAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYwkyMDA5LTExLTA2IDIxOjM3OjQ3LjAw MDAwMDAwMCArMDEwMApAQCAtMzUsNyArMzUsNyBAQAogICovCiAKICNpbmNsdWRlIDxzeXMvY2Rl ZnMuaD4KLV9fRkJTRElEKCIkRnJlZUJTRCQiKTsKK19fRkJTRElEKCIkRnJlZUJTRDogaGVhZC9z eXMva2Vybi92ZnNfc3lzY2FsbHMuYyAxOTY4ODcgMjAwOS0wOS0wNiAxMTo0NDo0Nloga2liICQi KTsKIAogI2luY2x1ZGUgIm9wdF9jb21wYXQuaCIKICNpbmNsdWRlICJvcHRfa2R0cmFjZS5oIgpA QCAtMzU4Nyw4ICszNTg3LDEyIEBACiAJICAgIEFVRElUVk5PREUxLCBwYXRoc2VnLCBvbGQsIG9s ZGZkLCB0ZCk7CiAjZW5kaWYKIAotCWlmICgoZXJyb3IgPSBuYW1laSgmZnJvbW5kKSkgIT0gMCkK KwlpZiAoKGVycm9yID0gbmFtZWkoJmZyb21uZCkpICE9IDApIHsKKwkJLyogVHJhbnNsYXRlIGVy cm9yIGNvZGUgZm9yIHJlbmFtZSgiLyIsICJkaXIyIikuICovCisJCWlmIChlcnJvciA9PSBFSVNE SVIpCisJCQllcnJvciA9IEVJTlZBTDsKIAkJcmV0dXJuIChlcnJvcik7CisJfQogCWZ2ZnNsb2Nr ZWQgPSBOREhBU0dJQU5UKCZmcm9tbmQpOwogCXR2ZnNsb2NrZWQgPSAwOwogI2lmZGVmIE1BQwpA QCAtMzczNyw4ICszNzQxLDEyIEBACiAJTkRJTklUX0FUKCZuZCwgQ1JFQVRFLCBMT0NLUEFSRU5U IHwgU0FWRU5BTUUgfCBNUFNBRkUgfCBBVURJVFZOT0RFMSwKIAkgICAgc2VnZmxnLCBwYXRoLCBm ZCwgdGQpOwogCW5kLm5pX2NuZC5jbl9mbGFncyB8PSBXSUxMQkVESVI7Ci0JaWYgKChlcnJvciA9 IG5hbWVpKCZuZCkpICE9IDApCisJaWYgKChlcnJvciA9IG5hbWVpKCZuZCkpICE9IDApIHsKKwkJ LyogVHJhbnNsYXRlIGVycm9yIGNvZGUgZm9yIG1rZGlyKCIvIikuICovCisJCWlmIChlcnJvciA9 PSBFSVNESVIpCisJCQllcnJvciA9IEVFWElTVDsKIAkJcmV0dXJuIChlcnJvcik7CisJfQogCXZm c2xvY2tlZCA9IE5ESEFTR0lBTlQoJm5kKTsKIAl2cCA9IG5kLm5pX3ZwOwogCWlmICh2cCAhPSBO VUxMKSB7CkBAIC0zODI1LDEwICszODMzLDE1IEBACiAJYndpbGx3cml0ZSgpOwogCU5ESU5JVF9B VCgmbmQsIERFTEVURSwgTE9DS1BBUkVOVCB8IExPQ0tMRUFGIHwgTVBTQUZFIHwgQVVESVRWTk9E RTEsCiAJICAgIHBhdGhzZWcsIHBhdGgsIGZkLCB0ZCk7Ci0JaWYgKChlcnJvciA9IG5hbWVpKCZu ZCkpICE9IDApCisJaWYgKChlcnJvciA9IG5hbWVpKCZuZCkpICE9IDApIHsKKwkJLyogVHJhbnNs YXRlIGVycm9yIGNvZGUgZm9yIHJtZGlyKCIvIikuICovCisJCWlmIChlcnJvciA9PSBFSVNESVIp CisJCQllcnJvciA9IEVCVVNZOwogCQlyZXR1cm4gKGVycm9yKTsKKwl9CiAJdmZzbG9ja2VkID0g TkRIQVNHSUFOVCgmbmQpOwogCXZwID0gbmQubmlfdnA7CisJLyogWFhYIG5hbWVpKCkgdGFrZXMg Y2FyZSBvZiB0aGlzIGNhc2UuICovCiAJaWYgKHZwLT52X3R5cGUgIT0gVkRJUikgewogCQllcnJv ciA9IEVOT1RESVI7CiAJCWdvdG8gb3V0OwpAQCAtMzg0MSw2ICszODU0LDcgQEAKIAkJZ290byBv dXQ7CiAJfQogCS8qCisJICogWFhYIG5hbWVpKCkgdGFrZXMgY2FyZSBvZiB0aGlzIGNhc2UuCiAJ ICogVGhlIHJvb3Qgb2YgYSBtb3VudGVkIGZpbGVzeXN0ZW0gY2Fubm90IGJlIGRlbGV0ZWQuCiAJ ICovCiAJaWYgKHZwLT52X3ZmbGFnICYgVlZfUk9PVCkgewo= --+permail-20091106210949f0889e8400000862-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 21:34:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B8CF106566B for ; Fri, 6 Nov 2009 21:34:12 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 214698FC08 for ; Fri, 6 Nov 2009 21:34:11 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,695,1249250400"; d="scan'208";a="17811175" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 06 Nov 2009 22:33:58 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 55C061B0766; Fri, 6 Nov 2009 22:33:58 +0100 (CET) Date: Fri, 06 Nov 2009 22:33:57 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: SIGUNUSED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 21:34:12 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 22:11:52 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC6571065692 for ; Fri, 6 Nov 2009 22:11:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 923F08FC0C for ; Fri, 6 Nov 2009 22:11:52 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id A9E061DD642; Fri, 6 Nov 2009 23:11:50 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 9F075228C0; Fri, 6 Nov 2009 23:11:50 +0100 (CET) Date: Fri, 6 Nov 2009 23:11:50 +0100 From: Jilles Tjoelker To: Alexander Best Message-ID: <20091106221150.GA60707@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@FreeBSD.org Subject: Re: SIGUNUSED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:11:52 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 22:24:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA9A21065670 for ; Fri, 6 Nov 2009 22:24:47 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 3421F8FC1D for ; Fri, 6 Nov 2009 22:24:47 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 6197735A843 for ; Fri, 6 Nov 2009 23:24:46 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 51212228C0; Fri, 6 Nov 2009 23:24:46 +0100 (CET) Date: Fri, 6 Nov 2009 23:24:46 +0100 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org Message-ID: <20091106222446.GB60707@stack.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:24:47 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --5vNYLRcllDrimb99 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pwait.patch" Index: usr.bin/pwait/pwait.1 =================================================================== --- usr.bin/pwait/pwait.1 (revision 0) +++ usr.bin/pwait/pwait.1 (revision 0) @@ -0,0 +1,78 @@ +.\" +.\" Copyright (c) 2004-2009, Jilles Tjoelker +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with +.\" or without modification, are permitted provided that the +.\" following conditions are met: +.\" +.\" 1. Redistributions of source code must retain the above +.\" copyright notice, this list of conditions and the +.\" following disclaimer. +.\" 2. Redistributions in binary form must reproduce the +.\" above copyright notice, this list of conditions and +.\" the following disclaimer in the documentation and/or +.\" other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND +.\" CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED +.\" WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A +.\" PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +.\" COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY +.\" DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +.\" PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF +.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER +.\" CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING +.\" NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE +.\" USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY +.\" OF SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd November 1, 2009 +.Os +.Dt PWAIT 1 +.Sh NAME +.Nm pwait +.Nd wait for processes to terminate +.Sh SYNOPSIS +.Nm +.Op Fl v +.Ar pid +\&... +.Sh DESCRIPTION +The +.Nm +utility will wait until each of the given processes has terminated. +.Pp +The following option is available: +.Bl -tag -width indent +.It Fl v +Print the exit status when each process terminates. +.El +.Sh DIAGNOSTICS +.Pp +The +.Nm +utility returns 0 on success, and >0 if an error occurs. +.Pp +Invalid pids elicit a warning message but are otherwise ignored. +.Sh SEE ALSO +.Xr kill 1 , +.Xr pkill 1 , +.Xr ps 1 , +.Xr wait 1 , +.Xr kqueue 2 +.Sh NOTES +.Nm +is not a substitute for the +.Xr wait 1 +builtin +as it will not clean up any zombies or state in the parent process. +.Sh HISTORY +A +.Nm +command first appeared in SunOS 5.8. Property changes on: usr.bin/pwait/pwait.1 ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: usr.bin/pwait/pwait.c =================================================================== --- usr.bin/pwait/pwait.c (revision 0) +++ usr.bin/pwait/pwait.c (revision 0) @@ -0,0 +1,148 @@ +/*- + * Copyright (c) 2004-2009, Jilles Tjoelker + * All rights reserved. + * + * Redistribution and use in source and binary forms, with + * or without modification, are permitted provided that the + * following conditions are met: + * + * 1. Redistributions of source code must retain the above + * copyright notice, this list of conditions and the + * following disclaimer. + * 2. Redistributions in binary form must reproduce the + * above copyright notice, this list of conditions and + * the following disclaimer in the documentation and/or + * other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND + * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, + * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE + * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY + * OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static void +usage(void) +{ + + fprintf(stderr, "usage: pwait [-v] pid ...\n"); + exit(EX_USAGE); +} + +/* + * pwait - wait for processes to terminate + */ +int +main(int argc, char *argv[]) +{ + int kq; + struct kevent *e; + int verbose = 0; + int opt, nleft, n, i, duplicate, status; + long pid; + char *s, *end; + + while ((opt = getopt(argc, argv, "v")) != -1) { + switch (opt) { + case 'v': + verbose = 1; + break; + default: + usage(); + /* NOTREACHED */ + } + } + + argc -= optind; + argv += optind; + + if (argc == 0) + usage(); + + kq = kqueue(); + if (kq == -1) + err(1, "kqueue"); + + e = malloc(argc * sizeof(struct kevent)); + if (e == NULL) + err(1, "malloc"); + nleft = 0; + for (n = 0; n < argc; n++) { + s = argv[n]; + if (!strncmp(s, "/proc/", 6)) /* Undocumented Solaris compat */ + s += 6; + errno = 0; + pid = strtol(s, &end, 10); + if (pid < 0 || *end != '\0' || errno != 0) { + warnx("%s: bad process id", s); + continue; + } + duplicate = 0; + for (i = 0; i < nleft; i++) + if (e[i].ident == (uintptr_t)pid) + duplicate = 1; + if (!duplicate) { + EV_SET(e + nleft, pid, EVFILT_PROC, EV_ADD, NOTE_EXIT, + 0, NULL); + if (kevent(kq, e + nleft, 1, NULL, 0, NULL) == -1) + warn("%ld", pid); + else + nleft++; + } + } + + if (nleft == 0) + exit(0); /* Solaris does this too. */ + + while (nleft > 0) { + n = kevent(kq, NULL, 0, e, nleft, NULL); + if (n == -1) + err(1, "kevent"); + if (verbose) + for (i = 0; i < n; i++) { + status = e[i].data; + if (WIFEXITED(status)) + printf("%ld: exited with status %d.\n", + (long)e[i].ident, + WEXITSTATUS(status)); + else if (WIFSIGNALED(status)) + printf("%ld: killed by signal %d.\n", + (long)e[i].ident, + WTERMSIG(status)); + else + printf("%ld: terminated.\n", + (long)e[i].ident); + } + nleft -= n; + } + + return 0; +} Property changes on: usr.bin/pwait/pwait.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: usr.bin/pwait/Makefile =================================================================== --- usr.bin/pwait/Makefile (revision 0) +++ usr.bin/pwait/Makefile (revision 0) @@ -0,0 +1,7 @@ +# $FreeBSD$ + +PROG= pwait + +WARNS?= 6 + +.include Property changes on: usr.bin/pwait/Makefile ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: usr.bin/Makefile =================================================================== --- usr.bin/Makefile (revision 198703) +++ usr.bin/Makefile (working copy) @@ -154,6 +154,7 @@ printenv \ printf \ procstat \ + pwait \ ${_quota} \ renice \ rev \ --5vNYLRcllDrimb99-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 02:17:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 671D3106566B for ; Sat, 7 Nov 2009 02:17:52 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id EE74C8FC1A for ; Sat, 7 Nov 2009 02:17:51 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,697,1249250400"; d="scan'208";a="228293785" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 07 Nov 2009 03:17:50 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4BA251B07BE; Sat, 7 Nov 2009 03:17:50 +0100 (CET) Date: Sat, 07 Nov 2009 03:17:49 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Jilles Tjoelker , Alexander Best Message-ID: In-Reply-To: <20091106221150.GA60707@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: SIGUNUSED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 02:17:52 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 02:34:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FF76106566B for ; Sat, 7 Nov 2009 02:34:12 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 01B888FC12 for ; Sat, 7 Nov 2009 02:34:11 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nA72YBo17750; Fri, 6 Nov 2009 18:34:11 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nA72YBU16331; Fri, 6 Nov 2009 18:34:11 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Fri, 6 Nov 2009 18:34:11 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Alexander Best In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: SIGUNUSED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 02:34:12 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 04:19:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F8831065670 for ; Sat, 7 Nov 2009 04:19:25 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 73FA68FC17 for ; Sat, 7 Nov 2009 04:19:25 +0000 (UTC) Received: from Macintosh-4.local ([10.0.0.198]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id nA73q6Fi083724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 19:52:07 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4AF4EEE6.4080605@freebsd.org> Date: Fri, 06 Nov 2009 19:52:06 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nick Hibma References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Hackers Mailing List Subject: Re: Mesh networking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 04:19:25 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 07:02:04 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 591B61065672 for ; Sat, 7 Nov 2009 07:02:04 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id E1E288FC18 for ; Sat, 7 Nov 2009 07:02:03 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id nA7722lm054257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 08:02:02 +0100 (CET) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id nA7721Bs054256; Sat, 7 Nov 2009 08:02:01 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sat, 7 Nov 2009 08:02:01 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Jilles Tjoelker Message-ID: <20091107070201.GF34407@acme.spoerlein.net> Mail-Followup-To: Jilles Tjoelker , freebsd-hackers@freebsd.org References: <20091106222446.GB60707@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091106222446.GB60707@stack.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 07:02:04 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 10:09:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68F36106566C for ; Sat, 7 Nov 2009 10:09:38 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 0465E8FC12 for ; Sat, 7 Nov 2009 10:09:38 +0000 (UTC) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1N6iEi-00010z-Kv; Sat, 07 Nov 2009 11:09:36 +0100 Received: from tb7ea.t.pppool.de ([89.55.183.234]:43989 helo=ernst.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N6iEi-0002JY-ER; Sat, 07 Nov 2009 11:09:36 +0100 Date: Sat, 7 Nov 2009 11:09:35 +0100 From: Gary Jennejohn To: Trever Message-ID: <20091107110935.0cb624b9@ernst.jennejohn.org> In-Reply-To: <761362.20406.qm@web113204.mail.gq1.yahoo.com> References: <761362.20406.qm@web113204.mail.gq1.yahoo.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Why is default value of NKPT so small? mfsroot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 10:09:38 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 10:21:18 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6CF11065672 for ; Sat, 7 Nov 2009 10:21:18 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 5083F8FC23 for ; Sat, 7 Nov 2009 10:21:18 +0000 (UTC) Received: from [195.4.92.24] (helo=14.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N6iQ1-0000A9-48; Sat, 07 Nov 2009 11:21:17 +0100 Received: from tb7ea.t.pppool.de ([89.55.183.234]:32782 helo=ernst.jennejohn.org) by 14.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N6iQ0-0000p3-Ro; Sat, 07 Nov 2009 11:21:17 +0100 Date: Sat, 7 Nov 2009 11:21:16 +0100 From: Gary Jennejohn To: Alexander Best Message-ID: <20091107112116.50eb45ee@ernst.jennejohn.org> In-Reply-To: References: <20091106182308.14dffc50@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 10:21:18 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 10:28:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D331065679 for ; Sat, 7 Nov 2009 10:28:35 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4109E8FC0A for ; Sat, 7 Nov 2009 10:28:35 +0000 (UTC) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N6iX3-00015g-TG; Sat, 07 Nov 2009 11:28:33 +0100 Received: from tb7ea.t.pppool.de ([89.55.183.234]:35566 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N6iX3-00030N-Fr; Sat, 07 Nov 2009 11:28:33 +0100 Date: Sat, 7 Nov 2009 11:28:32 +0100 From: Gary Jennejohn To: Jilles Tjoelker Message-ID: <20091107112832.24b0c0d4@ernst.jennejohn.org> In-Reply-To: <20091106222446.GB60707@stack.nl> References: <20091106222446.GB60707@stack.nl> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 10:28:35 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 11:45:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A4F106566B for ; Sat, 7 Nov 2009 11:45:35 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id DF9F08FC13 for ; Sat, 7 Nov 2009 11:45:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,699,1249250400"; d="scan'208";a="17846879" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 07 Nov 2009 12:45:33 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0CC201B0751; Sat, 7 Nov 2009 12:45:33 +0100 (CET) Date: Sat, 07 Nov 2009 12:45:32 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: , Alexander Best Message-ID: In-Reply-To: <20091107112116.50eb45ee@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 11:45:35 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 07:41:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CEFF1065672 for ; Sat, 7 Nov 2009 07:41:05 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id BD4BF8FC14 for ; Sat, 7 Nov 2009 07:41:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.3/8.14.3) with ESMTP id nA77Ss21014459; Sat, 7 Nov 2009 14:28:54 +0700 (KRAT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.3/8.14.3/Submit) id nA77SsU4014458; Sat, 7 Nov 2009 14:28:54 +0700 (KRAT) (envelope-from eugen) Date: Sat, 7 Nov 2009 14:28:54 +0700 From: Eugene Grosbein To: Jilles Tjoelker Message-ID: <20091107072854.GC14078@rdtc.ru> References: <20091106222446.GB60707@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091106222446.GB60707@stack.nl> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sat, 07 Nov 2009 12:25:57 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 07:41:05 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 07:41:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A3901065670 for ; Sat, 7 Nov 2009 07:41:08 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id BEB5B8FC17 for ; Sat, 7 Nov 2009 07:41:07 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.3/8.14.3) with ESMTP id nA77QOlW014449; Sat, 7 Nov 2009 14:26:24 +0700 (KRAT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.3/8.14.3/Submit) id nA77QMuO014448; Sat, 7 Nov 2009 14:26:22 +0700 (KRAT) (envelope-from eugen) Date: Sat, 7 Nov 2009 14:26:22 +0700 From: Eugene Grosbein To: Alexander Best Message-ID: <20091107072622.GB14078@rdtc.ru> References: <20091106221150.GA60707@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sat, 07 Nov 2009 12:26:08 +0000 Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: SIGUNUSED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 07:41:08 -0000 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 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0EC0106568F for ; Sat, 7 Nov 2009 13:01:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0B48FC19 for ; Sat, 7 Nov 2009 13:01:42 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nA7D1alp089028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 15:01:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nA7D1aJV064803; Sat, 7 Nov 2009 15:01:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nA7D1ahB064802; Sat, 7 Nov 2009 15:01:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Nov 2009 15:01:36 +0200 From: Kostik Belousov To: Gary Jennejohn Message-ID: <20091107130136.GI2331@deviant.kiev.zoral.com.ua> References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IdGNrZu1oYcejyEu" Content-Disposition: inline In-Reply-To: <20091107112832.24b0c0d4@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 13:01:44 -0000 --IdGNrZu1oYcejyEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > 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. > >=20 >=20 > 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. --IdGNrZu1oYcejyEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkr1b7AACgkQC3+MBN1Mb4i2KwCgorz3J2FJYidqEmkhWnjzZI+2 BVQAoKXX0EOQMPendP9Za2GtFlr1Ap6H =6RpI -----END PGP SIGNATURE----- --IdGNrZu1oYcejyEu-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 13:50:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D004106566B for ; Sat, 7 Nov 2009 13:50:51 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4BE8FC17 for ; Sat, 7 Nov 2009 13:50:50 +0000 (UTC) Received: by ewy18 with SMTP id 18so1603944ewy.43 for ; Sat, 07 Nov 2009 05:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wI76VXML5iDhEQ+qZsWtWNi0O33RYXlHOCs5lWFMeeY=; b=XkWt2aHUo+WAHjboXKtL5unTfOd+E74J9WwcslPbz9DifiRZQzoMe93dCsSA9QRCwg rf70yTkxSOThy5DjcqYnaTf17zm+7ymmpxrAk42bFjACG66OxjPhC7U28L1EwY+DeR3q JVa8PM4K4eUxSfduXkvcEUajYYPc1GdQh2pUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nFzJSV5HnzPuzMmS8OpAmcoR6jJucfXq21Rfd5VShrZtA9VAVGmdLQuOxQcQxii8V9 mHyjr09qiVBm8RtRndQaL3U3RO/iMzaqdRvOqMaIFSW1MU0yFoUgunKjGL5Q/CFv+zMW ASxhPqNhG6a51vkoSnxxQpB0Npl87QexeMUhg= Received: by 10.213.24.24 with SMTP id t24mr778621ebb.16.1257601850169; Sat, 07 Nov 2009 05:50:50 -0800 (PST) Received: from mac-mini.lan (bl7-119-248.dsl.telepac.pt [85.240.119.248]) by mx.google.com with ESMTPS id 24sm1261883eyx.29.2009.11.07.05.50.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Nov 2009 05:50:49 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed From: Rui Paulo In-Reply-To: <20091107070201.GF34407@acme.spoerlein.net> Date: Sat, 7 Nov 2009 13:50:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCC2EE8-D9B1-4283-A022-C4B94FE0642C@freebsd.org> References: <20091106222446.GB60707@stack.nl> <20091107070201.GF34407@acme.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1076) Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 13:50:51 -0000 On 7 Nov 2009, at 07:02, Ulrich Sp=F6rlein wrote: > I understand that shutdown duration is of zero importance for server > operations, FWIW, I don't agree with this. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 15:48:01 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFF58106566B for ; Sat, 7 Nov 2009 15:48:01 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 810C98FC12 for ; Sat, 7 Nov 2009 15:48:01 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 582736D41B; Sat, 7 Nov 2009 15:48:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0E53084503; Sat, 7 Nov 2009 16:48:00 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jilles Tjoelker References: <20091106221150.GA60707@stack.nl> Date: Sat, 07 Nov 2009 16:47:59 +0100 In-Reply-To: <20091106221150.GA60707@stack.nl> (Jilles Tjoelker's message of "Fri, 6 Nov 2009 23:11:50 +0100") Message-ID: <867hu2gwuo.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Alexander Best Subject: Re: SIGUNUSED X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 15:48:01 -0000 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 20:19:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C842D10656A3 for ; Sat, 7 Nov 2009 20:19:55 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9298FC19 for ; Sat, 7 Nov 2009 20:19:55 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id A3ED335A836; Sat, 7 Nov 2009 21:19:54 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 93919228C0; Sat, 7 Nov 2009 21:19:54 +0100 (CET) Date: Sat, 7 Nov 2009 21:19:54 +0100 From: Jilles Tjoelker To: Kostik Belousov Message-ID: <20091107201954.GA84099@stack.nl> References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> <20091107130136.GI2331@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091107130136.GI2331@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 20:19:55 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 20:27:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33FCC106568B for ; Sat, 7 Nov 2009 20:27:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id CFE638FC16 for ; Sat, 7 Nov 2009 20:27:38 +0000 (UTC) Received: (qmail 497 invoked by uid 399); 7 Nov 2009 20:27:37 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Nov 2009 20:27:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AF5D840.6090707@FreeBSD.org> Date: Sat, 07 Nov 2009 12:27:44 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Jilles Tjoelker References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> <20091107130136.GI2331@deviant.kiev.zoral.com.ua> <20091107201954.GA84099@stack.nl> In-Reply-To: <20091107201954.GA84099@stack.nl> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 20:27:39 -0000 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 owner-freebsd-hackers@FreeBSD.ORG Sat Nov 7 21:17:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE39106566B for ; Sat, 7 Nov 2009 21:17:14 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id A894F8FC16 for ; Sat, 7 Nov 2009 21:17:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 0B92014D9B57; Sat, 7 Nov 2009 22:17:14 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id at5-ncqAZS1F; Sat, 7 Nov 2009 22:17:11 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 6438014D9B52; Sat, 7 Nov 2009 22:17:11 +0100 (CET) Message-ID: <4AF5E3D5.3050009@FreeBSD.org> Date: Sat, 07 Nov 2009 22:17:09 +0100 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jilles Tjoelker References: <20091106222446.GB60707@stack.nl> <20091107112832.24b0c0d4@ernst.jennejohn.org> <20091107130136.GI2331@deviant.kiev.zoral.com.ua> <20091107201954.GA84099@stack.nl> In-Reply-To: <20091107201954.GA84099@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: [patch] add pwait utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 21:17:15 -0000 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