From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 00:23:21 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D657316A41F for ; Sun, 31 Jul 2005 00:23:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E0A243D45 for ; Sun, 31 Jul 2005 00:23:18 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6V0VlKX028921; Sat, 30 Jul 2005 18:31:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42EC19DF.3020306@samsco.org> Date: Sat, 30 Jul 2005 18:22:55 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <42EBDC29.2070603@san.rr.com> <20050730.165054.99724167.imp@bsdimp.com> In-Reply-To: <20050730.165054.99724167.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: jbaggs@san.rr.com, hackers@freebsd.org Subject: Re: UFS endian-ness 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, 31 Jul 2005 00:23:21 -0000 M. Warner Losh wrote: > In message: <42EBDC29.2070603@san.rr.com> > Jeremy Baggs writes: > : I was wondering if anyone has done any recent work with, or knows how > : (non-)trival it would be adding support for mounting big-endian UFS > : filesystems, such as the one in use on os X. > > It is trivial. NetBSD just does the swapping on input or output and > the diffs to do it were small. > > Warner Do their patches include UFS2 and EA support? Scott From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 03:18:02 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FE3D16A41F for ; Sun, 31 Jul 2005 03:18:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0C5143D45 for ; Sun, 31 Jul 2005 03:18:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j6V3HmnK076240; Sat, 30 Jul 2005 21:17:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 30 Jul 2005 21:18:39 -0600 (MDT) Message-Id: <20050730.211839.15328567.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <42EC19DF.3020306@samsco.org> References: <42EBDC29.2070603@san.rr.com> <20050730.165054.99724167.imp@bsdimp.com> <42EC19DF.3020306@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jbaggs@san.rr.com, hackers@freebsd.org Subject: Re: UFS endian-ness 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, 31 Jul 2005 03:18:02 -0000 In message: <42EC19DF.3020306@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > In message: <42EBDC29.2070603@san.rr.com> : > Jeremy Baggs writes: : > : I was wondering if anyone has done any recent work with, or knows how : > : (non-)trival it would be adding support for mounting big-endian UFS : > : filesystems, such as the one in use on os X. : > : > It is trivial. NetBSD just does the swapping on input or output and : > the diffs to do it were small. : > : > Warner : : Do their patches include UFS2 and EA support? I checked prior to ufs2 being imported... Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 02:35:10 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EA1116A420 for ; Sun, 31 Jul 2005 02:35:10 +0000 (GMT) (envelope-from koma2@lovepeers.org) Received: from www235.sakura.ne.jp (www235.sakura.ne.jp [202.181.97.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A2143D48 for ; Sun, 31 Jul 2005 02:35:07 +0000 (GMT) (envelope-from koma2@lovepeers.org) Received: from [192.168.11.9] (61-26-245-137.rev.home.ne.jp [61.26.245.137]) (authenticated bits=0) by www235.sakura.ne.jp (8.12.11/8.12.11) with ESMTP id j6V2YotJ084294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jul 2005 11:34:56 +0900 (JST) (envelope-from koma2@lovepeers.org) Message-ID: <42EC38C9.8070402@lovepeers.org> Date: Sun, 31 Jul 2005 11:34:49 +0900 From: KOMATSU Shinichiro User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Olivier Certner References: <200507102313.12719.olivier.certner@free.fr> <20050712165530.GA5475@xor.obsecurity.org> <1121189986.6598.1.camel@cream.xbsd.org> <200507130015.31521.olivier.certner@free.fr> In-Reply-To: <200507130015.31521.olivier.certner@free.fr> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 31 Jul 2005 13:21:50 +0000 Cc: freebsd-hackers@freebsd.org, Kris Kennaway , Florent Thoumie Subject: Re: Bug in portupgrade 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, 31 Jul 2005 02:35:10 -0000 Hello. Olivier Certner wrote: > Le Mardi 12 Juillet 2005 19:39, Florent Thoumie a écrit : > >>Le Mardi 12 juillet 2005 à 12:55 -0400, Kris Kennaway a écrit : >> >>>On Sun, Jul 10, 2005 at 11:13:12PM +0200, Olivier Certner wrote: >>> >>>> Hi, >>>> >>>> There is a bug with portupgrade when it is used to upgrade already >>>>compiled and installed ports for which some dependencies have been >>>>deleted in the package database. This causes a crash in the function >>>>'deorigin' in pkgdb.rb. >>>> >>>> Since I don't know the internals of portupgrade, I don't know if it's >>>>normal to call 'deorigin' with its argument set to nil. If it is, then >>>>the patch below might be useful (beware, I don't know any ruby, I've >>>>just tried something and it works), if it is not, I only can provide >>>>the stack (see below) in order for maintainers to seek the faulty >>>>callers. >>> >>>Please talk to the port maintainer. >> >> Yeah, and good luck :) >> >> Otherwise, he can try to pkgdb -F or remove pkgdb.rb and re-run >> portupgrade. > > > This doesn't work in fact. I'm forwarding these mails to the maintainer. Sorry for my late reply, but would you try out the following patch? Index: lib/portsdb.rb =================================================================== --- lib/portsdb.rb (revision 37) +++ lib/portsdb.rb (revision 38) @@ -846,7 +846,7 @@ def all_depends_list(origin, before_args = nil, after_args = nil) if !before_args && !after_args && i = port(origin) - i.all_depends.map { |n| origin(n) } + i.all_depends.map { |n| origin(n) }.compact else all_depends_list!(origin, before_args, after_args) end From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 13:59:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85EF716A41F; Sun, 31 Jul 2005 13:59:24 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD6043D49; Sun, 31 Jul 2005 13:59:24 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id j6VDxNW5087524; Sun, 31 Jul 2005 09:59:23 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id j6VDxKjn087523; Sun, 31 Jul 2005 09:59:20 -0400 (EDT) (envelope-from afields) Date: Sun, 31 Jul 2005 09:59:19 -0400 From: Allan Fields To: Poul-Henning Kamp Message-ID: <20050731135919.GA43753@afields.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Cc: Pawel Jakub Dawidek , freebsd-geom , freebsd-hackers , freebsd-security , Alexander Leidinger , "Ronnel P. Maglasang" Subject: Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem) 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, 31 Jul 2005 13:59:24 -0000 On Fri, Jul 29, 2005 at 01:52:40PM +0200, Poul-Henning Kamp wrote: > In message <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net>, Alexander Leidinger writes: > >Pawel Jakub Dawidek wrote: > > > >> This is not not possible with current GBDE. > >> I've patches which allows this here: > >> > >> http://people.freebsd.org/~pjd/patches/gbde.patch > > > >I fail to see how this allows an encryted root-FS, it doesn't add gbde > >support to boot0(ext) or to the loader. It needs access to an unencrypted > >kernel. I don't think this is what Ronnel had in mind (overlooking the fact > >that his suggestion to save the passphrase in the loader is insecure). > > There is a difference between loading the kernel from an encrypted volume > (very hard!) and mounting the root filesystem from an encrypted volume > (possible with pawels patch. > > Now of course, if your kernel has been trojaned, you're in trouble, but > then again, most people just worry about their data if the machine gets > stolen. Yes, this is all very nice, but when is someone actually going to commit it? ;) I don't think it wise to have GBDE and GEOM subsystems which are rather central to the system require too much fussing around with patches, this makes the admin's job harder and makes us developers look lazy (though I know it not to be the case for GEOM folks). Can we decide on something and get it in the main kernel source tree? Further forking the BSD kernel: (sarcasm implied) Either that or can we fork GBDE (and other subsystems) into three (up to inf.) different concurrent implementations and maintain kernel build "knobs" to customize which version is compiled? I'll admit I haven't submitted some of the hacks to GBDE I'd like to see integrated into the tree, mostly to avoid these types of issues, where I'd like to see certain features completely implemented before I post patches. And then I have the concern: if I post patches, will they ever get committed? Should I just wait for an official implementation by core GEOM developers -- but even pjd isn't committing some work, why not? I don't like to get bogged down patching source manually, unless I have to and I've even explored using a shell script to maintain FreeBSD kernel source trees, which I still haven't posted on list. But, who has time to polish a shell script up when you have $N tasks? -- My latest life-wide TODO list (including some history and various notes): 3977 22204 148955 20050517 Further FYI: It's called srctag and is my attempt at automating/unifying kernel source tree management. Again I'll reference BSDCan 2004 slides, but this is rather vain absent my posting the script. ;) The idea would be to reinforce/automate checkout/build process from potentially heterogenous source code collections (cvs,cvsup,perforce,rsync, nfs, patches, etc.) and maintain a properly labelled/date-time stamped directory which merges the collected source, patches, etc. ready for build/install.) Potentially local modifications could be captured avoiding cvs clumbsiness. At one point I thought of using union mounts to combine trees/capture changes, but can this just as easily be done using standard diff/patch mechanisms? Some of my gbde work is obviously still not finished, due to time constraints. Though I don't intend to wait all-the-way for the gbde "mega-patch" if I get around to finishing. ( I thought of holding off until I do something important enough which really can't be rejected on specific small merits alone.. ;) Though, I don't think this is the Open Source commit early/often collaborative model. I'd rather not ram my code design choices into a big ball of code, even if I think I'm doing the "right thing" so I'll post on-list in hopes of getting feedback like I emailed phk about gbde root implementation ideas. Still taste seems best. ) Another thing on my TODO list as discussed with mdod at BSDCan is possibility of PAMifying gbde(8) and generally looking at kernel side key store/management issues. The idea of hardware integration / support was discussed and it might be beneficial to find out some way to use generic hardware in configuration as an affordable HSM w/ some degree of key protection. I've also now been tracking the ongoing work on Linux side with interest to adoption. Both device level and vnode level solutions are valid and of interest. There was a presentation on TCG (IBM Trusted Computing hardware) including coverage of TPM, etc. On the vnode level there is work toward an integrated solution (eCryptFS) on the Linux side, I might have an interest in porting this to FreeBSD and vice-versa for all applicable technologies. One thing is clear, if I plan on proactively deploying GBDE in a production environment or promoting it's use, I'd like some assurance I'll be able to count on coordinated development with timely response to security or other patches. The current state of gbde bugs/PRs is something I'd like to help get resolved if I select gbde for wider adoption. People trying and failing to use GBDE is of concern to me being interested in wider disk encryption use. In the past I've tried to help on list, but I think time constraints would prevent me from doing much specific support work unpaid. Also, I have a number of "legacy" volumes, personally which use my patch for password input which is different than pjd's solution so I have to build a different gbde(8) binary each time I rebuild world on that machine. I've noted that perforce might further the divide. I recognize it's meant as an experimental code base and it's great if people make something work in their kernel tree, but if it takes too long to merge back into CVS (especially when it is requested/working feature) then that can be prohibitive. I don't fully grok perforce yet, it's time consuming learning all these systems. What ever happened to plain old CVS? (lacking as it can be construed..) Can't developers settle on one source management tool (per project at least)? I attended a presentation at Desktop Developers' Con. 2005 here in Ottawa where this issue was discussed wrt Open Source desktop developers. IMO, this issue of source management lacking central coordination can only hobble the best intentions of Open Source authors. How many systems do we have now? 10,11,12 and you (source maintainers) expect me to install and use _all_ of these in addition to keeping track of regular patches if I want to contribute or use most recent source tree from the projects? (Note this is not a FreeBSD specific problem and FreeBSD isn't _that_ bad off.) I note that KDE is now on svn and Linux is moving off bk to mercurial (or is it git)? I heard supposedly bk stopped working for people due to some commercial decisions made? So, on the one hand I advocate better source management tools; but as a user, I note these source management issues are general impediments to my progress and could also slow down developers/stifle contribution. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Allan Fields (afields) - Ottawa, Canada (45"10'N 75"56'W) Himeji Systems http://himejisystems.com Afields Research/AFRSL http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 14:07:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B8016A41F; Sun, 31 Jul 2005 14:07:30 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F81243D48; Sun, 31 Jul 2005 14:07:30 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id AB291BC69; Sun, 31 Jul 2005 14:07:27 +0000 (UTC) To: Allan Fields From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 31 Jul 2005 09:59:19 EDT." <20050731135919.GA43753@afields.ca> Date: Sun, 31 Jul 2005 16:07:27 +0200 Message-ID: <10601.1122818847@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Pawel Jakub Dawidek , freebsd-geom , freebsd-hackers , freebsd-security , Alexander Leidinger , "Ronnel P. Maglasang" Subject: Re: Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem) 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, 31 Jul 2005 14:07:30 -0000 In message <20050731135919.GA43753@afields.ca>, Allan Fields writes: >Yes, this is all very nice, but when is someone actually going to >commit it? ;) I'm (as always) short of time, and GBDE is not the top priority for me for the time being. So I am more than happy to see people band together and improve gbde. The main work necessary is to polish the userland program and that is relatively trivial programming, so anyone should be able to pick that up: just go for it. Giving gbde a taste function so that the root filesystem can be protected by GBDE, this is also OK by me in principle, but I'd like to review the patch before it gets committed because there are a large number of dragons. In P4:phk_gbde there is the beginning of hw-crypto support through opencrypto(9), if somebody wants to work on that, get in touch with me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 15:08:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFAC616A41F; Sun, 31 Jul 2005 15:08:47 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06C8643D48; Sun, 31 Jul 2005 15:08:47 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 68E02ACBD2; Sun, 31 Jul 2005 17:08:45 +0200 (CEST) Date: Sun, 31 Jul 2005 17:08:45 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20050731150845.GJ636@darkness.comp.waw.pl> References: <20050731135919.GA43753@afields.ca> <10601.1122818847@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gMR3gsNFwZpnI/Ts" Content-Disposition: inline In-Reply-To: <10601.1122818847@phk.freebsd.dk> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Cc: freebsd-geom , freebsd-hackers , freebsd-security , Allan Fields , Alexander Leidinger , "Ronnel P. Maglasang" Subject: Re: Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem) 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, 31 Jul 2005 15:08:48 -0000 --gMR3gsNFwZpnI/Ts Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 31, 2005 at 04:07:27PM +0200, Poul-Henning Kamp wrote: +> In message <20050731135919.GA43753@afields.ca>, Allan Fields writes: +>=20 +> >Yes, this is all very nice, but when is someone actually going to +> >commit it? ;) +>=20 +> I'm (as always) short of time, and GBDE is not the top priority +> for me for the time being. +>=20 +> So I am more than happy to see people band together and improve +> gbde. +>=20 +> The main work necessary is to polish the userland program and that +> is relatively trivial programming, so anyone should be able to pick +> that up: just go for it. +>=20 +> Giving gbde a taste function so that the root filesystem can be +> protected by GBDE, this is also OK by me in principle, but I'd like +> to review the patch before it gets committed because there are a +> large number of dragons. +>=20 +> In P4:phk_gbde there is the beginning of hw-crypto support through +> opencrypto(9), if somebody wants to work on that, get in touch with +> me. I'm starting to wonder if we couldn't create one storage-crypto-base and rewrite gbde, geli on top of it. geli(8) is complete, ie. you can use any command on attached and detached providers, you can backup your metadata, protect your passphrase with PKCS#5v2, use files as a key part, etc. gbde(8) (userland tool) is not finished (all those things I've in geli already are on its todo list). I've plan for another crypto-storage class, which will provide privacy and integrity verification (the very thing we are missing now). I want another class, because it will be slower than geli in both crypto-time and disk-access-time aspects. Another possibility is to integrate two classes and allow user to decide if he wants privacy, integrity verification or both. If someone can spend time on integreting gbde crypto scheme into geli where userland part is complete, where crypto(9) is used already, etc. that'd be cool. The truth is, that the main difference between gbde/geli is how crypto is used on disk, the other elements (managing keys, protecting passphrases, metadata backups, encrypted root partition, etc.) are or could be the same. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gMR3gsNFwZpnI/Ts Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFC7Ol9ForvXbEpPzQRAi4TAJ9CF+1bk001L51nLuv1W1zyZvlX9ACeOD0Z kn+CkQGHGOlJE3grlw5YElk= =TU/M -----END PGP SIGNATURE----- --gMR3gsNFwZpnI/Ts-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 15:11:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47C4216A420; Sun, 31 Jul 2005 15:11:22 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3EF43D48; Sun, 31 Jul 2005 15:11:19 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id A5A47BC66; Sun, 31 Jul 2005 15:11:16 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 31 Jul 2005 17:08:45 +0200." <20050731150845.GJ636@darkness.comp.waw.pl> Date: Sun, 31 Jul 2005 17:11:16 +0200 Message-ID: <10880.1122822676@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-geom , freebsd-hackers , freebsd-security , Allan Fields , Alexander Leidinger , "Ronnel P. Maglasang" Subject: Re: Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem) 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, 31 Jul 2005 15:11:22 -0000 In message <20050731150845.GJ636@darkness.comp.waw.pl>, Pawel Jakub Dawidek writes: >I'm starting to wonder if we couldn't create one storage-crypto-base >and rewrite gbde, geli on top of it. Could be, it all depends how much you actually gain from generalizing common code. Best way to find out is to try :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 18:40:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E4416A41F for ; Sun, 31 Jul 2005 18:40:33 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AA8443D45 for ; Sun, 31 Jul 2005 18:40:33 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j6VIeXYk028508; Sun, 31 Jul 2005 11:40:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j6VIeWGv028507; Sun, 31 Jul 2005 11:40:32 -0700 (PDT) (envelope-from dillon) Date: Sun, 31 Jul 2005 11:40:32 -0700 (PDT) From: Matthew Dillon Message-Id: <200507311840.j6VIeWGv028507@apollo.backplane.com> To: Kirk McKusick Cc: freebsd-hackers@freebsd.org Subject: Possible softupdates bug when a indirect block buffer is reused 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, 31 Jul 2005 18:40:33 -0000 Hi Kirk, hackers! I'm trying to track down a bug that is causing a buffer to be left in a locked state and then causes the filesystem to lock up because of that. The symptoms are that a heavily used filesystem suddenly starts running out of space. It isn't due to deleted files with open descriptors, it's due to the syncer getting stuck in a getblk state. This is in DragonFly, but I can't find anything DFlyish wrong so I'm beginning to think it may be an actual bug in softupdates. I have wound up with a situation where a getblk()'d bp has been associated with a indirdep dependancy, i.e. stored in indirdep->ir_savebp, but is never released. When something like the syncer comes along and tries to access it, it locks up, and this of course leads to inodes not getting cleared and the filesystem eventually runs out of space when a lot of files are being created and deleted. What has got me really confused is that the buffer in question seems to wind up with a D_INDIRDEP dependancy that points back to itself. Here's the situation from a live gdb. Here is where the syncer is stuck: (kgdb) back #0 lwkt_switch () at thread2.h:95 #1 0xc02a8a79 in tsleep (ident=0x0, flags=0, wmesg=0xc04eadb0 "getblk", timo=0) at /usr/src-125beta/sys/kern/kern_synch.c:428 #2 0xc02956bb in acquire (lkp=0xc758b4e0, extflags=33554464, wanted=1536) at /usr/src-125beta/sys/kern/kern_lock.c:127 #3 0xc0295a92 in lockmgr (lkp=0xc758b4e0, flags=33620002, interlkp=0x0, td=0xd68f6400) at /usr/src-125beta/sys/kern/kern_lock.c:354 #4 0xc02d6828 in getblk (vp=0xc71b3058, blkno=94440240, size=8192, slpflag=0, slptimeo=0) at thread.h:79 #5 0xc02d4404 in bread (vp=0xc71b3058, blkno=0, size=0, bpp=0x0) at /usr/src-125beta/sys/kern/vfs_bio.c:567 #6 0xc03f24fe in indir_trunc (ip=0xe048fc0c, dbn=94440240, level=1, lbn=2060, countp=0xe048fbf8) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2221 #7 0xc03f22df in handle_workitem_freeblocks (freeblks=0xe2fcef98) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2138 #8 0xc03f0462 in process_worklist_item (matchmnt=0x0, flags=0) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:726 #9 0xc03f026c in softdep_process_worklist (matchmnt=0x0) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:625 #10 0xc02e5ff3 in sched_sync () at /usr/src-125beta/sys/kern/vfs_sync.c:244 #11 0xc0294863 in kthread_create_stk (func=0, arg=0x0, tdp=0xff800000, stksize=0, fmt=0x0) at /usr/src-125beta/sys/kern/kern_kthread.c:104 (kgdb) The buffer it is stuck on: (kgdb) print bp $62 = (struct buf *) 0xc758b4b8 (kgdb) print *bp $63 = { b_hash = { le_next = 0x0, le_prev = 0xc7391348 }, b_vnbufs = { tqe_next = 0xc739b890, tqe_prev = 0xc76f32b8 }, b_freelist = { tqe_next = 0xc768d610, tqe_prev = 0xc0565ac0 }, b_act = { tqe_next = 0x0, tqe_prev = 0x0 }, b_flags = 536870912, <<<<<<<<< 0x20000000 (getblk with no bread, etc) b_qindex = 0, b_xflags = 2 '\002', b_lock = { lk_interlock = { t_cpu = 0xff800000, t_reqcpu = 0xff800000, t_unused01 = 0 }, lk_flags = 2098176, lk_sharecount = 0, lk_waitcount = 1, lk_exclusivecount = 1, lk_prio = 0, lk_wmesg = 0xc04eadb0 "getblk", lk_timo = 0, lk_lockholder = 0xfffffffe }, b_error = 0, b_bufsize = 8192, b_runningbufspace = 0, b_bcount = 8192, b_resid = 0, b_dev = 0xde0f0e38, b_data = 0xcf824000 "¨\205Ð\002", b_kvabase = 0xcf824000 "¨\205Ð\002", b_kvasize = 16384, b_lblkno = 94440240, b_blkno = 94440240, b_offset = 48353402880, b_iodone = 0, b_iodone_chain = 0x0, b_vp = 0xc71b3058, b_dirtyoff = 0, b_dirtyend = 0, b_pblkno = 87503631, b_saveaddr = 0x0, b_driver1 = 0x0, b_caller1 = 0x0, b_pager = { pg_spc = 0x0, pg_reqpage = 0 }, b_cluster = { cluster_head = { tqh_first = 0x0, tqh_last = 0xc768d6bc ---Type to continue, or q to quit--- }, cluster_entry = { tqe_next = 0x0, tqe_prev = 0xc768d6bc } }, b_xio = { xio_pages = 0xc758b584, xio_npages = 2, xio_offset = 0, xio_bytes = 0, xio_flags = 0, xio_error = 0, xio_internal_pages = {0xc34e5870, 0xc4aeb2b4, 0x0 } }, b_dep = { lh_first = 0xc7045040 }, b_chain = { parent = 0x0, count = 0 } } As you can see from b_flags, which is 0x20000000, the buffer has been getblk()'d but not bread() or anything else. It is the typical state that occurs when a buffer is placed in an indirdep->ir_savebp state in setup_allocindir_phase2(). The buffer's dependancy looks like this: (kgdb) print bp $65 = (struct buf *) 0xc758b4b8 (kgdb) print *(struct indirdep *)bp->b_dep.lh_first $66 = { ir_list = { wk_list = { le_next = 0x0, le_prev = 0xc758b604 }, wk_type = 5, wk_state = 33025 <<<<<<<<<<<<< ATTACHED|GOINGAWAY|ONWORKLIST }, ir_saveddata = 0xdeadc0de "", ir_savebp = 0xc758b4b8, <<<<<<<<<<<<< points back to itself ir_donehd = { lh_first = 0x0 }, ir_deplisthd = { lh_first = 0x0 } } (kgdb) As you can see, the buffer's dependancy seems to point to itself. As you may know, ir_savebp buffers are left in a locked state, so a buffer that has gotten into this situation winds up being permanently deadlocked. This is on DragonFly, but I can't find anything else wrong. This is on a filesystem running a myrid of jails which is constantly creating and deleting files in parallel... so buffers are being reused quite often. It takes about a week of this heavy activity for the bug to rear its ugly head. It's fairly difficult to reproduce (takes about a week to reproduce). When the problem does occur the system remains functional... the disk device continues to work, the filesystem continues to work, except for any blockages that chain down to the particular block that has deadlocked (usually the syncer, but as time goes by more parts of the system will deadlock). It IS possible to run a live gdb when the situation is caught early enough. I am trying to figure out how the buffer manages to get into this self-locked state. I'm pretty much stuck once I get to the deallocate_dependancies() procedure. This procedure seems to be trying to move a D_INDIRDEP dependancy from the passed bp into the buffer pointed to by ir_savebp. As far as I can tell this is what is creating the situation that makes the buffer's dependancy self-referential and deadlocks the syncer. I have noticed a number of FreeBSD bug reports related to blocking in getblk or to softupdates. I don't know if this is a similar problem but it's worth Ccing freebsd-hackers on it as well. -Matt From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 19:44:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 273E916A41F for ; Sun, 31 Jul 2005 19:44:17 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC80F43D46 for ; Sun, 31 Jul 2005 19:44:16 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j6VJiGYk028933; Sun, 31 Jul 2005 12:44:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j6VJiGNT028932; Sun, 31 Jul 2005 12:44:16 -0700 (PDT) (envelope-from dillon) Date: Sun, 31 Jul 2005 12:44:16 -0700 (PDT) From: Matthew Dillon Message-Id: <200507311944.j6VJiGNT028932@apollo.backplane.com> To: Kirk McKusick , freebsd-hackers@freebsd.org References: <200507311840.j6VIeWGv028507@apollo.backplane.com> Cc: Subject: addendum Re: Possible softupdates bug when a indirect block buffer is reused 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, 31 Jul 2005 19:44:17 -0000 Addendum: My user reports that the problem also occurs on FreeBSD 4.10 and 4.11, on uniprocessor builds (other builds and 5.x/6.x have not been tested). I took a look at the 4.x and 6.x softupdates code and didn't see any commits that might address the problem. This adds weight to the likelihood of it being a softupdates bug of some sort, possibly still present in 6.x. -Matt From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 31 19:47:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05D7B16A41F for ; Sun, 31 Jul 2005 19:47:42 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B02443D48 for ; Sun, 31 Jul 2005 19:47:41 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 25020 invoked by uid 210); 31 Jul 2005 19:47:40 +0000 Received: from 66.23.216.49 by talon (envelope-from , uid 201) with qmail-scanner-1.25st (clamdscan: 0.85.1/998. spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(66.23.216.49):. Processed in 0.030537 secs); 31 Jul 2005 19:47:40 -0000 X-Qmail-Scanner-Mail-From: ups@tree.com via talon X-Qmail-Scanner: 1.25st (Clear:RC:1(66.23.216.49):. Processed in 0.030537 secs Process 25013) Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 31 Jul 2005 19:47:40 +0000 Received: from [127.0.0.1] (ups@localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j6VJlbrK002603; Sun, 31 Jul 2005 15:47:37 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Matthew Dillon In-Reply-To: <200507311840.j6VIeWGv028507@apollo.backplane.com> References: <200507311840.j6VIeWGv028507@apollo.backplane.com> Content-Type: text/plain Message-Id: <1122839257.1360.5.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 31 Jul 2005 15:47:37 -0400 Content-Transfer-Encoding: 7bit Cc: Kirk McKusick , freebsd-hackers@freebsd.org Subject: Re: Possible softupdates bug when a indirect block buffer is reused 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, 31 Jul 2005 19:47:42 -0000 Hi Matthew, We have been testing a fix for this for a few weeks. I will check it in today. Stephan On Sun, 2005-07-31 at 14:40, Matthew Dillon wrote: > Hi Kirk, hackers! > > I'm trying to track down a bug that is causing a buffer to be left > in a locked state and then causes the filesystem to lock up because > of that. > > The symptoms are that a heavily used filesystem suddenly starts running > out of space. It isn't due to deleted files with open descriptors, it's > due to the syncer getting stuck in a getblk state. This is in DragonFly, > but I can't find anything DFlyish wrong so I'm beginning to think it may > be an actual bug in softupdates. > > I have wound up with a situation where a getblk()'d bp has been > associated with a indirdep dependancy, i.e. stored in > indirdep->ir_savebp, but is never released. When something like > the syncer comes along and tries to access it, it locks up, and this > of course leads to inodes not getting cleared and the filesystem > eventually runs out of space when a lot of files are being created and > deleted. > > What has got me really confused is that the buffer in question seems to > wind up with a D_INDIRDEP dependancy that points back to itself. > > Here's the situation from a live gdb. Here is where the syncer is > stuck: > > (kgdb) back > #0 lwkt_switch () at thread2.h:95 > #1 0xc02a8a79 in tsleep (ident=0x0, flags=0, wmesg=0xc04eadb0 "getblk", > timo=0) at /usr/src-125beta/sys/kern/kern_synch.c:428 > #2 0xc02956bb in acquire (lkp=0xc758b4e0, extflags=33554464, wanted=1536) > at /usr/src-125beta/sys/kern/kern_lock.c:127 > #3 0xc0295a92 in lockmgr (lkp=0xc758b4e0, flags=33620002, interlkp=0x0, > td=0xd68f6400) at /usr/src-125beta/sys/kern/kern_lock.c:354 > #4 0xc02d6828 in getblk (vp=0xc71b3058, blkno=94440240, size=8192, slpflag=0, > slptimeo=0) at thread.h:79 > #5 0xc02d4404 in bread (vp=0xc71b3058, blkno=0, size=0, bpp=0x0) > at /usr/src-125beta/sys/kern/vfs_bio.c:567 > #6 0xc03f24fe in indir_trunc (ip=0xe048fc0c, dbn=94440240, level=1, lbn=2060, > countp=0xe048fbf8) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2221 > #7 0xc03f22df in handle_workitem_freeblocks (freeblks=0xe2fcef98) > at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2138 > #8 0xc03f0462 in process_worklist_item (matchmnt=0x0, flags=0) > at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:726 > #9 0xc03f026c in softdep_process_worklist (matchmnt=0x0) > at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:625 > #10 0xc02e5ff3 in sched_sync () at /usr/src-125beta/sys/kern/vfs_sync.c:244 > #11 0xc0294863 in kthread_create_stk (func=0, arg=0x0, tdp=0xff800000, > stksize=0, fmt=0x0) at /usr/src-125beta/sys/kern/kern_kthread.c:104 > (kgdb) > > The buffer it is stuck on: > > (kgdb) print bp > $62 = (struct buf *) 0xc758b4b8 > (kgdb) print *bp > $63 = { > b_hash = { > le_next = 0x0, > le_prev = 0xc7391348 > }, > b_vnbufs = { > tqe_next = 0xc739b890, > tqe_prev = 0xc76f32b8 > }, > b_freelist = { > tqe_next = 0xc768d610, > tqe_prev = 0xc0565ac0 > }, > b_act = { > tqe_next = 0x0, > tqe_prev = 0x0 > }, > b_flags = 536870912, <<<<<<<<< 0x20000000 (getblk with no bread, etc) > b_qindex = 0, > b_xflags = 2 '\002', > b_lock = { > lk_interlock = { > t_cpu = 0xff800000, > t_reqcpu = 0xff800000, > t_unused01 = 0 > }, > lk_flags = 2098176, > lk_sharecount = 0, > lk_waitcount = 1, > lk_exclusivecount = 1, > lk_prio = 0, > lk_wmesg = 0xc04eadb0 "getblk", > lk_timo = 0, > lk_lockholder = 0xfffffffe > }, > b_error = 0, > b_bufsize = 8192, > b_runningbufspace = 0, > b_bcount = 8192, > b_resid = 0, > b_dev = 0xde0f0e38, > b_data = 0xcf824000 "\205\002", > b_kvabase = 0xcf824000 "\205\002", > b_kvasize = 16384, > b_lblkno = 94440240, > b_blkno = 94440240, > b_offset = 48353402880, > b_iodone = 0, > b_iodone_chain = 0x0, > b_vp = 0xc71b3058, > b_dirtyoff = 0, > b_dirtyend = 0, > b_pblkno = 87503631, > b_saveaddr = 0x0, > b_driver1 = 0x0, > b_caller1 = 0x0, > b_pager = { > pg_spc = 0x0, > pg_reqpage = 0 > }, > b_cluster = { > cluster_head = { > tqh_first = 0x0, > tqh_last = 0xc768d6bc > ---Type to continue, or q to quit--- > }, > cluster_entry = { > tqe_next = 0x0, > tqe_prev = 0xc768d6bc > } > }, > b_xio = { > xio_pages = 0xc758b584, > xio_npages = 2, > xio_offset = 0, > xio_bytes = 0, > xio_flags = 0, > xio_error = 0, > xio_internal_pages = {0xc34e5870, 0xc4aeb2b4, 0x0 } > }, > b_dep = { > lh_first = 0xc7045040 > }, > b_chain = { > parent = 0x0, > count = 0 > } > } > > As you can see from b_flags, which is 0x20000000, the buffer has been > getblk()'d but not bread() or anything else. It is the typical state > that occurs when a buffer is placed in an indirdep->ir_savebp state > in setup_allocindir_phase2(). > > The buffer's dependancy looks like this: > > (kgdb) print bp > $65 = (struct buf *) 0xc758b4b8 > (kgdb) print *(struct indirdep *)bp->b_dep.lh_first > $66 = { > ir_list = { > wk_list = { > le_next = 0x0, > le_prev = 0xc758b604 > }, > wk_type = 5, > wk_state = 33025 <<<<<<<<<<<<< ATTACHED|GOINGAWAY|ONWORKLIST > }, > ir_saveddata = 0xdeadc0de "", > ir_savebp = 0xc758b4b8, <<<<<<<<<<<<< points back to itself > ir_donehd = { > lh_first = 0x0 > }, > ir_deplisthd = { > lh_first = 0x0 > } > } > (kgdb) > > As you can see, the buffer's dependancy seems to point to itself. > As you may know, ir_savebp buffers are left in a locked state, so a > buffer that has gotten into this situation winds up being permanently > deadlocked. > > This is on DragonFly, but I can't find anything else wrong. This is > on a filesystem running a myrid of jails which is constantly creating > and deleting files in parallel... so buffers are being reused quite often. > It takes about a week of this heavy activity for the bug to rear its > ugly head. It's fairly difficult to reproduce (takes about a week to > reproduce). > > When the problem does occur the system remains functional... the disk > device continues to work, the filesystem continues to work, except for > any blockages that chain down to the particular block that has deadlocked > (usually the syncer, but as time goes by more parts of the system will > deadlock). It IS possible to run a live gdb when the situation is > caught early enough. > > I am trying to figure out how the buffer manages to get into this > self-locked state. I'm pretty much stuck once I get to the > deallocate_dependancies() procedure. This procedure seems to be trying > to move a D_INDIRDEP dependancy from the passed bp into the buffer > pointed to by ir_savebp. As far as I can tell this is what is creating > the situation that makes the buffer's dependancy self-referential > and deadlocks the syncer. > > I have noticed a number of FreeBSD bug reports related to blocking in > getblk or to softupdates. I don't know if this is a similar problem > but it's worth Ccing freebsd-hackers on it as well. > > -Matt > > _______________________________________________ > 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 Mon Aug 1 11:36:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2238516A41F; Mon, 1 Aug 2005 11:36:09 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id A61DC43D49; Mon, 1 Aug 2005 11:36:08 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 5C90197773; Mon, 1 Aug 2005 04:36:05 -0700 (PDT) Message-Id: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Mon, 01 Aug 2005 04:36:07 -0700 To: freebsd-hackers@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-x11@freebsd.org Subject: FreeBSD desktop? 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, 01 Aug 2005 11:36:09 -0000 Maybe someone on the hackers or x11 list can help me get going the right direction here. I can setup FreeBSD servers like the wind - tweak the kernel, you name it. So this weekend I tried to install FreeBSD 5.4 on my desktop - what a mess. I never could get anything to run, other than startx or xstart or something. I ended up once with a blank desktop (I think I typed X) and another time with the same desktop, but with 3 open windows. Anyway, I finally gave up. Anyone have any run down on loading FreeBSD as your desktop? I am trying to go with FreeBSD because I use it for my servers, but I feel like I'm lacking a broad understanding of how Unix handles windows. I get the impression there is a server that deals with windows called X windows and then there are different desktop managers (such as KDE, Gnome, etc) - but I don't understand the interplay between them and the Kernel as it relates to how I normally see FreeBSD. I'm wondering if someone can give me an overview? I'm also wondering if I'm barking up the wrong tree. I know Mac uses Darwin, which is based on BSD. And in the past, I have loaded up Redhat and SUSE and ended up with a nice desktop - but with FreeBSD I didn't have much luck, even though I installed just about everything on the install CD's. From what I could see, there were a ton of things to configure, but I couldn't find any good documentation on setting up my monitor or what the heck was going on overall - even in my BSD books, not a lot of help. Anyway, I am wondering if maybe running SUSE or Fedora or something might be better. I'm reading one article right now that says this thing called Xandros Desktop 3 is great - so far it looks nice in the article and I may give that a try. I've been using Windows XP for my desktop for so long and am so used to so many applications on it - I think it would be difficult (at this time) to change over completely. Unless Wine really does work well enough to run some applications I can't live without (e.g. Eudora or Pagemaker, etc). Anyway, any help anyone can provide would be great? I just feel like I'm lacking a core understanding of how Windowing and desktop interfaces to the Kernel. And like I say, as much as I would like to make this all happen on FreeBSD, it seems like Linux maybe is a better choice? Anyone? Ray From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 11:42:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2C716A41F for ; Mon, 1 Aug 2005 11:42:23 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD2B043D45 for ; Mon, 1 Aug 2005 11:42:22 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so984288wra for ; Mon, 01 Aug 2005 04:42:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=q5VufjGW953rvR/KYpdpTXMf9GrAo4hBzi/8sJduo0eTRHaYW9W83w5GsnUAa+rdad9Eu+He9ZT5ItNkixr0k1o58J6VfB5LxAuLrYqtv5WMCG3uW2stFEjr+DE8GKTMS+ErEXePfRA+zFSqWQojSbIQyX7mdtC2gA3OeOTXRII= Received: by 10.54.137.14 with SMTP id k14mr527900wrd; Mon, 01 Aug 2005 04:42:21 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Mon, 1 Aug 2005 04:42:21 -0700 (PDT) Message-ID: <494025505080104427c3f91f6@mail.gmail.com> Date: Mon, 1 Aug 2005 14:42:21 +0300 From: victor cruceru To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 11:42:23 -0000 Hi all, I'm just wondering if it's OK for an open syscall on such a device (i.e.=20 /dev/acd0 or /dev/da1 with a CF reader attached) to block till the media is= =20 ready or a timeout occurs. Thanks, Victor From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 11:56:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B1C516A42F for ; Mon, 1 Aug 2005 11:56:36 +0000 (GMT) (envelope-from dmitry.mityugov@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABB0A43D48 for ; Mon, 1 Aug 2005 11:56:35 +0000 (GMT) (envelope-from dmitry.mityugov@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so986058wra for ; Mon, 01 Aug 2005 04:56:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DduXM3RZ0JslIfifVe3Gd5FpUh+T3fgm3hAxcvmP7rHRwxl0XK4aZGYADXakSRdIaww2ggc54BZ8sQaSr/sLUhMarL6YdNMHs1RpUl21EYmYOtdtSBZt4ZfqfUcwFN0U7vaHBz2hlCbrEFYvZpclId3o7IlQbjVjswHA4lIUi7U= Received: by 10.54.54.39 with SMTP id c39mr2605568wra; Mon, 01 Aug 2005 04:56:34 -0700 (PDT) Received: by 10.54.56.33 with HTTP; Mon, 1 Aug 2005 04:56:34 -0700 (PDT) Message-ID: Date: Mon, 1 Aug 2005 15:56:34 +0400 From: Dmitry Mityugov To: "ray@redshift.com" In-Reply-To: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> Cc: freebsd-hackers@freebsd.org, freebsd-x11@freebsd.org Subject: Re: FreeBSD desktop? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitry Mityugov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 11:56:36 -0000 On 8/1/05, ray@redshift.com wrote: > Maybe someone on the hackers or x11 list can help me get going the righ= t > direction here. I can setup FreeBSD servers like the wind - tweak the ke= rnel, > you name it. So this weekend I tried to install FreeBSD 5.4 on my deskto= p - > what a mess. I never could get anything to run, other than startx or xst= art or > something. I ended up once with a blank desktop (I think I typed X) and = another > time with the same desktop, but with 3 open windows. Anyway, I finally g= ave up. >=20 > Anyone have any run down on loading FreeBSD as your desktop? I am tryi= ng to > go with FreeBSD because I use it for my servers, but I feel like I'm lack= ing a > broad understanding of how Unix handles windows. I get the impression th= ere is > a server that deals with windows called X windows and then there are diff= erent > desktop managers (such as KDE, Gnome, etc) - but I don't understand the > interplay between them and the Kernel as it relates to how I normally see= FreeBSD. >=20 > I'm wondering if someone can give me an overview? ... Chapter 5 in the Handbook, The X Window System, is probably what you're looking for: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11.html --=20 Dmitry Mityugov, St. Petersburg, Russia I ignore all messages with confidentiality statements "We live less by imagination than despite it" - Rockwell Kent, "N by E" From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 12:00:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69CAD16A422; Mon, 1 Aug 2005 12:00:48 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB9F443D5D; Mon, 1 Aug 2005 12:00:47 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j71C0lvY085240; Mon, 1 Aug 2005 07:00:47 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42EE0EE7.2010809@centtech.com> Date: Mon, 01 Aug 2005 07:00:39 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> In-Reply-To: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1000/Sun Jul 31 14:28:06 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, freebsd-x11@freebsd.org Subject: Re: FreeBSD desktop? 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, 01 Aug 2005 12:00:48 -0000 ray@redshift.com wrote: > Maybe someone on the hackers or x11 list can help me get going the right > direction here. I can setup FreeBSD servers like the wind - tweak the kernel, > you name it. So this weekend I tried to install FreeBSD 5.4 on my desktop - > what a mess. I never could get anything to run, other than startx or xstart or > something. I ended up once with a blank desktop (I think I typed X) and another > time with the same desktop, but with 3 open windows. Anyway, I finally gave up. > > Anyone have any run down on loading FreeBSD as your desktop? I am trying to > go with FreeBSD because I use it for my servers, but I feel like I'm lacking a > broad understanding of how Unix handles windows. I get the impression there is > a server that deals with windows called X windows and then there are different > desktop managers (such as KDE, Gnome, etc) - but I don't understand the > interplay between them and the Kernel as it relates to how I normally see FreeBSD. > > I'm wondering if someone can give me an overview? > > I'm also wondering if I'm barking up the wrong tree. I know Mac uses Darwin, > which is based on BSD. And in the past, I have loaded up Redhat and SUSE and > ended up with a nice desktop - but with FreeBSD I didn't have much luck, even > though I installed just about everything on the install CD's. From what I could > see, there were a ton of things to configure, but I couldn't find any good > documentation on setting up my monitor or what the heck was going on overall - > even in my BSD books, not a lot of help. Have you looked at the Handbook? It pretty much covers what you need to know to get working. Also, freebsd-questions@ would be a better email list (rather than -hackers, which is for hacking on FreeBSD code, etc). > Anyway, I am wondering if maybe running SUSE or Fedora or something might be > better. I'm reading one article right now that says this thing called Xandros > Desktop 3 is great - so far it looks nice in the article and I may give that a try. Better? Depends of course. I (as do many others) use FreeBSD on my desktop and laptop, and feel no need to use anything else really. > I've been using Windows XP for my desktop for so long and am so used to so > many applications on it - I think it would be difficult (at this time) to change > over completely. Unless Wine really does work well enough to run some > applications I can't live without (e.g. Eudora or Pagemaker, etc). Not sure what you want here, but if you aren't willing to change some apps, then you shouldn't switch. FreeBSD/linux/etc are not Windows, so you can't expect them to be Windows. If you are willing to make a change of email readers (try Thunderbird, Mozilla, etc, etc) and a few other programs, you'd be fine. > Anyway, any help anyone can provide would be great? I just feel like I'm > lacking a core understanding of how Windowing and desktop interfaces to the > Kernel. And like I say, as much as I would like to make this all happen on > FreeBSD, it seems like Linux maybe is a better choice? Again, better is a general term that you haven't really defined, so nobody can help you there unless you explain what it is you want, and how you see things as 'better'. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 12:10:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5806F16A41F for ; Mon, 1 Aug 2005 12:10:06 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3DCF43D45 for ; Mon, 1 Aug 2005 12:10:05 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 2097A97777; Mon, 1 Aug 2005 05:10:05 -0700 (PDT) Message-Id: <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Mon, 01 Aug 2005 05:10:07 -0700 To: Eric Anderson From: ray@redshift.com In-Reply-To: <42EE0EE7.2010809@centtech.com> References: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD desktop? 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, 01 Aug 2005 12:10:06 -0000 | Have you looked at the Handbook? It pretty much covers what you need to | know to get working. Also, freebsd-questions@ would be a better email | list (rather than -hackers, which is for hacking on FreeBSD code, etc). I did read through the handbook, but I see I missed a couple of sections in it. I missed freebsd-questions on the list.. I was looking for something like freebsd-desktop :-D I am only subscribed to hackers and a couple of others to keep tabs on servers stuff. | Better? Depends of course. I (as do many others) use FreeBSD on my | desktop and laptop, and feel no need to use anything else really. Okay, good to hear. I love FreeBSD - I dumped Linux redhat a couple of years ago and moved all of our servers over to FreeBSD and just love it. I really want to be able to make FreeBSD my desktop and it seems like i should be able to get it up and running and configured like SUSE or Redhat or Xandros or something along those lines with a little work. | Not sure what you want here, but if you aren't willing to change some | apps, then you shouldn't switch. FreeBSD/linux/etc are not Windows, so | you can't expect them to be Windows. If you are willing to make a | change of email readers (try Thunderbird, Mozilla, etc, etc) and a few | other programs, you'd be fine. I have a drive tray on my machine, so I was going to keep XP around on another drive and pop that in to access a shared drive D maybe. I read about a product called codeweaver that looks pretty good - but I'm not sure if it will work on BSD Thanks again. Ray From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 01:52:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4837316A41F; Mon, 1 Aug 2005 01:52:09 +0000 (GMT) (envelope-from yfyoufeng@263.net) Received: from smtp.263.net (mx01.263.net.cn [211.150.96.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC4AB43D46; Mon, 1 Aug 2005 01:52:08 +0000 (GMT) (envelope-from yfyoufeng@263.net) Received: from [10.217.12.183] (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 59C78C37A0; Mon, 1 Aug 2005 09:52:02 +0800 (CST) (envelope-from yfyoufeng@263.net) Received: from [10.217.12.183] (unknown [61.135.152.194]) by antispam-2 (Coremail:263(050316)) with SMTP id EHAgAUKA7UKqHJjC.1 for ; Mon, 01 Aug 2005 09:52:02 +0800 (CST) X-TEBIE-Originating-IP: [61.135.152.194] From: yf-263 To: Ryan Sommers In-Reply-To: <42EB9005.8080200@gamersimpact.com> References: <42E9A0E7.40703@centtech.com> <42EB9005.8080200@gamersimpact.com> Content-Type: text/plain; charset=UTF-8 Organization: Unix-driver.org Date: Mon, 01 Aug 2005 17:51:59 +0800 Message-Id: <1122889920.2885.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 01 Aug 2005 12:16:25 +0000 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Eric Anderson Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yfyoufeng@263.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 01:52:09 -0000 在 2005-07-30å…­çš„ 09:34 -0500，Ryan Sommers写é“： > Eric Anderson wrote: > > I've very interested in learning about FreeBSD's implementation of > > vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter > > in the Design and Implmentation of FreeBSD book, and I've read the UNIX > > Filesystems book cover to cover. > > > > What I'd like to see/read/understand, is how FreeBSD in particular is > > put together in this regard, and then I'd like to go about writing a > > very very simple filesystem as a learning excercise. > > > > Can anyone give me some pointers? Would anyone be willing to guide me > > along in my quest by answering questions (off list if preferred, or on > > list), etc? > > > > Thanks in advance for the hints/input! > > Eric > > > > > > Best place would be the source code itself. I think the nullfs > implementation would be a good place (src/sys/fs/nullfs). I thought I > also remembered some little article on writing an FS for freebsd, > finding it is eluding me though. I'm also doing the same work. Now I'm working on port our data access library into the FreeBSD kernel space as a vnode hooks. Hope we can help each others :) > -- yf-263 Unix-driver.org From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 13:05:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E1016A41F; Mon, 1 Aug 2005 13:05:04 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id F060343D45; Mon, 1 Aug 2005 13:05:03 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 7D03DA3D79; Mon, 1 Aug 2005 15:05:02 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 5D7EA63A4; Mon, 1 Aug 2005 15:05:02 +0200 (CEST) Date: Mon, 1 Aug 2005 15:05:02 +0200 From: Marc Olzheim To: soc-victor@freebsd.org Message-ID: <20050801130502.GA39470@stack.nl> References: <494025505080104427c3f91f6@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <494025505080104427c3f91f6@mail.gmail.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media 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, 01 Aug 2005 13:05:04 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote: > Hi all, > I'm just wondering if it's OK for an open syscall on such a device (i.e.= =20 > /dev/acd0 or /dev/da1 with a CF reader attached) to block till the media = is=20 > ready or a timeout occurs. I'd say that depends completely on whether you supply O_NONBLOCK or not, so yes. Quoted from a sound driver discussion at:=20 http://sourceforge.net/mailarchive/message.php?msg_id=3D10011826 On block devices, O_NONBLOCK also is a way to say "don't try to do any=20 device discovery", ie you can do a O_NONBLOCK open on a removable disk=20 that doesn"t even have any media in it. Again, this has _nothing_ to do=20 with whether the device is "busy" or not. =2E.. Short summary: =20 - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag= =20 "early" (ie it"s conceptually equivalent to doing a "F_SETFL" fcntl=20 before the open. It _may_ affect the open itself, but when it does, it= =20 is generally considered to mean that you can open something that isn't= =20 even _reachable_. =20 - POSIX doesn't say anything much about its behaviour, except for named= =20 pipes, where it says the total reverse of what ALSA does. But that=20 doesn't actually mean anything, because even that is very much defined= =20 as a special case by POSIX. Marc --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7h3+ezjnobFOgrERAtlKAJwOytkg9PPLqeIXJ6TmSFDwrZRiEwCgynB8 JTtEaJ3En4jNvgYdnKYCN1Q= =Rrpr -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 13:33:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71EFB16A41F for ; Mon, 1 Aug 2005 13:33:49 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147F843D5E for ; Mon, 1 Aug 2005 13:33:24 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so1001977wra for ; Mon, 01 Aug 2005 06:33:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BuN9b+7QdJxaicSu/NhlE7Hs1yplTQMxIp6Mlp+IcsHA3EEnysBmQef3i+3nOLVuUQfXw5zm9wjAnUZtgDN1ABBGGV7RKRozgToeBlhCDiH6SkCkxfx7oUCExjoosk1D//iMvFM2CLw0I/WQdpEYMHt90iwU5sQmwtiaeKMszVs= Received: by 10.54.2.57 with SMTP id 57mr2860865wrb; Mon, 01 Aug 2005 06:33:23 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Mon, 1 Aug 2005 06:33:23 -0700 (PDT) Message-ID: <494025505080106336a329bb@mail.gmail.com> Date: Mon, 1 Aug 2005 16:33:23 +0300 From: victor cruceru To: Marc Olzheim In-Reply-To: <20050801130502.GA39470@stack.nl> Mime-Version: 1.0 References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 13:33:49 -0000 Hi Marc, Thanks for the info. Here it is one my situation. I have a CF reader (fully= =20 detected by the USB subsystem) with two slots (one with a media and one without any media). An open with O_NONBLOCK on th= e=20 empty slot (/dev/da1) is blocking me. Is this OK?=20 Thanks, Victor=20 On 8/1/05, Marc Olzheim wrote: >=20 > On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote: > > Hi all, > > I'm just wondering if it's OK for an open syscall on such a device (i.e= . > > /dev/acd0 or /dev/da1 with a CF reader attached) to block till the medi= a=20 > is > > ready or a timeout occurs. >=20 > I'd say that depends completely on whether you supply O_NONBLOCK or not, > so yes. >=20 > Quoted from a sound driver discussion at: > http://sourceforge.net/mailarchive/message.php?msg_id=3D10011826 >=20 >=20 > On block devices, O_NONBLOCK also is a way to say "don't try to do any > device discovery", ie you can do a O_NONBLOCK open on a removable disk > that doesn"t even have any media in it. Again, this has _nothing_ to do > with whether the device is "busy" or not. >=20 > ... >=20 > Short summary: >=20 > - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag > "early" (ie it"s conceptually equivalent to doing a "F_SETFL" fcntl > before the open. It _may_ affect the open itself, but when it does, it > is generally considered to mean that you can open something that isn't > even _reachable_. >=20 > - POSIX doesn't say anything much about its behaviour, except for named > pipes, where it says the total reverse of what ALSA does. But that > doesn't actually mean anything, because even that is very much defined > as a special case by POSIX. >=20 > Marc >=20 >=20 > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 13:35:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2874716A41F; Mon, 1 Aug 2005 13:35:48 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id A982F43D5C; Mon, 1 Aug 2005 13:35:47 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 77E86A3D83; Mon, 1 Aug 2005 15:35:46 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 5675E63A4; Mon, 1 Aug 2005 15:35:46 +0200 (CEST) Date: Mon, 1 Aug 2005 15:35:46 +0200 From: Marc Olzheim To: soc-victor@freebsd.org Message-ID: <20050801133546.GA39886@stack.nl> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <494025505080106336a329bb@mail.gmail.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media 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, 01 Aug 2005 13:35:48 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 04:33:23PM +0300, victor cruceru wrote: > Hi Marc, > Thanks for the info. Here it is one my situation. I have a CF reader (ful= ly=20 > detected by the USB subsystem) with two slots > (one with a media and one without any media). An open with O_NONBLOCK on = the=20 > empty slot (/dev/da1) is blocking me. > Is this OK?=20 Hmm, it seems not. Perhaps is trying to do its magic first. What's the wchan of the process doing the open() ? Marc --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7iUyezjnobFOgrERAss6AKCyQ1MPXsGr2fu8RFgXHKG30e4heQCeOYgB csSr5SfkUNyoqwLuPL6J5sA= =aLlU -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 13:36:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2CEF16A41F; Mon, 1 Aug 2005 13:36:52 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D5B943D45; Mon, 1 Aug 2005 13:36:52 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id BC067A3D86; Mon, 1 Aug 2005 15:36:51 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id AB78763A4; Mon, 1 Aug 2005 15:36:51 +0200 (CEST) Date: Mon, 1 Aug 2005 15:36:51 +0200 From: Marc Olzheim To: soc-victor@freebsd.org Message-ID: <20050801133651.GB39886@stack.nl> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801133546.GA39886@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <20050801133546.GA39886@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media 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, 01 Aug 2005 13:36:52 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 01, 2005 at 03:35:46PM +0200, Marc Olzheim wrote: > Hmm, it seems not. Perhaps is trying to do its magic first. What's the ^ Insert 'GEOM' here | :-/ > wchan of the process doing the open() ? Marc --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7iVzezjnobFOgrERAvopAKDPcsuWWXEGTkZWwtjiSku1g0DeawCePIwr STef4e0hKmJIDwGQVGDucD4= =eeiL -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 16:34:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E2816A41F for ; Mon, 1 Aug 2005 16:34:24 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D51343D45 for ; Mon, 1 Aug 2005 16:34:20 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 1FE7917721; Mon, 1 Aug 2005 13:33:10 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37316-01; Mon, 1 Aug 2005 13:33:03 -0300 (BRT) Received: from [10.0.0.15] (telco [201.8.56.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id CFF941700A; Mon, 1 Aug 2005 13:33:02 -0300 (BRT) Message-ID: <42EE4F06.70502@jonny.eng.br> Date: Mon, 01 Aug 2005 13:34:14 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Luis?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <20050729211719.C95340@woozle.rinet.ru> <20050729231544.GX26656@cicely12.cicely.de> In-Reply-To: <20050729231544.GX26656@cicely12.cicely.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAADBQ TFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/AP//////ex+xxAAA Ac9JREFUOMtdk8FupDAMhr1qRbjR2x77GD3uq7BS1TkuhyrmFnppcvOrUlUquXltJ2EAIw1Dvvz+ bRPgrQbU6NpzuY0AF1LABIc4AH9crxLwb/4VztEU42W9SOBezwX4ClzeLuC9PBFRq+2xpJJHN8KQ Oa9Hd/ACnldgUVADvgHKA2usVwW12BVSkrThJH+5lqqQXIAAvRkQM6WqkADpO5gBx5m5VOxRgBZV HRLRcgc4dv3ukbOBm3de8uHIe1n0BBUBIi4hi0U2ownGkkwrwN425ygVPjntsvOmkFyyXYfreHXq f1tugFLCFDhZcsffYIqxKNAB/FkNbBDslUTz0MMQfuRnkN6D5nLVQ0G2H3bWC6KByTZPZWhJ/jgs ChX3e/P5y0VReCUCYm0/pUQd1lQ4/aIty/YtW6y3WMHc8yazpcU8UuqqB+LfMql/wVx4kXNTwGQO PxTuL7+AhbSkWS4z0TdZFbo1BR6qQkA08DnogNNHey/SGc5GejqFttxhjBHd3rjd62nR08gnxeFr Ic2e52we+QC0rIg6KYn1AKQsbF3wcgAP00MZrZ6X0yc5v5TRXgTi/jtVwef5I6Y+J7kyb+d1eB6K 4LoOLphBW/8PdNW9dapKWXwAAAAASUVORK5CYII= Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at coe.ufrj.br Cc: freebsd-hackers@freebsd.org, Dmitry Morozovsky Subject: Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed 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, 01 Aug 2005 16:34:24 -0000 Bernd Walter wrote: > On Fri, Jul 29, 2005 at 09:41:24PM +0400, Dmitry Morozovsky wrote: > >>Dear colleagues, >> >>can anyone please point me why mdconfig method for tmpmfs >>is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? >> >>Are swap-backed file systems so inefficient? If no, why not move -M to >>/etc/defaultc/rc.conf so admin can override this behaviour? > > > Diskless systems may not have swap - the default is required as is. > Don't know about beeing hardcoded. It is hardcoded at /etc/rc.subr: # Provide a function for normalizing the mounting of memory # filesystems. This should allow the rest of the code here to remain # as close as possible between 5-current and 4-stable. # $1 = size # $2 = mount point # $3 = (optional) extra mdmfs flags mount_md() { if [ -n "$3" ]; then flags="$3" fi /sbin/mdmfs $flags -s $1 -M md $2 } I would prefer it to be configurable, too. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 16:50:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F83B16A41F for ; Mon, 1 Aug 2005 16:50:44 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA36B43D45 for ; Mon, 1 Aug 2005 16:50:43 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id j71GoTnC044418; Mon, 1 Aug 2005 20:50:29 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 1 Aug 2005 20:50:29 +0400 (MSD) From: Dmitry Morozovsky To: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Luis?= In-Reply-To: <42EE4F06.70502@jonny.eng.br> Message-ID: <20050801204935.D43677@woozle.rinet.ru> References: <20050729211719.C95340@woozle.rinet.ru> <20050729231544.GX26656@cicely12.cicely.de> <42EE4F06.70502@jonny.eng.br> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (woozle.rinet.ru [0.0.0.0]); Mon, 01 Aug 2005 20:50:29 +0400 (MSD) Cc: freebsd-hackers@freebsd.org, ticso@cicely.de Subject: Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed 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, 01 Aug 2005 16:50:44 -0000 On Mon, 1 Aug 2005, Jo?o Carlos Mendes Luis wrote: JCML> > > can anyone please point me why mdconfig method for tmpmfs is JCML> > > malloc-backed instead of swap-backed, and it is hardcoded into JCML> > > rc.subr? JCML> > > Are swap-backed file systems so inefficient? If no, why not move -M to JCML> > > /etc/defaultc/rc.conf so admin can override this behaviour? JCML> > JCML> > JCML> > Diskless systems may not have swap - the default is required as is. JCML> > Don't know about beeing hardcoded. JCML> JCML> It is hardcoded at /etc/rc.subr: JCML> JCML> # Provide a function for normalizing the mounting of memory JCML> # filesystems. This should allow the rest of the code here to remain JCML> # as close as possible between 5-current and 4-stable. JCML> # $1 = size JCML> # $2 = mount point JCML> # $3 = (optional) extra mdmfs flags JCML> mount_md() { JCML> if [ -n "$3" ]; then JCML> flags="$3" JCML> fi JCML> /sbin/mdmfs $flags -s $1 -M md $2 JCML> } JCML> JCML> I would prefer it to be configurable, too. I did contacted keramida@ yesterday, and he seems to be happy with my proposed patch. So, just wait for it to be committed. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:02:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C94A16A41F for ; Mon, 1 Aug 2005 17:02:43 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4966143D45 for ; Mon, 1 Aug 2005 17:02:40 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j71H2abR010802; Mon, 1 Aug 2005 20:02:36 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j71H2aL3000790; Mon, 1 Aug 2005 20:02:36 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j71H2ae5000789; Mon, 1 Aug 2005 20:02:36 +0300 (EEST) Date: Mon, 1 Aug 2005 20:02:36 +0300 From: Giorgos Keramidas To: Dmitry Morozovsky Message-ID: <20050801170236.GA767@beatrix.daedalusnetworks.priv> References: <20050729211719.C95340@woozle.rinet.ru> <20050729231544.GX26656@cicely12.cicely.de> <42EE4F06.70502@jonny.eng.br> <20050801204935.D43677@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801204935.D43677@woozle.rinet.ru> Cc: freebsd-hackers@freebsd.org, ticso@cicely.de, =?iso-8859-7?Q?Jo=E3o?= Carlos Mendes Luis Subject: Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed 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, 01 Aug 2005 17:02:43 -0000 On 2005-08-01 20:50, Dmitry Morozovsky wrote: >On Mon, 1 Aug 2005, Jo?o Carlos Mendes Luis wrote: >>>> can anyone please point me why mdconfig method for tmpmfs is >>>> malloc-backed instead of swap-backed, and it is hardcoded into >>>> rc.subr? >>>> Are swap-backed file systems so inefficient? If no, why not move -M to >>>> /etc/defaultc/rc.conf so admin can override this behaviour? >>> >>> Diskless systems may not have swap - the default is required as is. >>> Don't know about beeing hardcoded. >> >> It is hardcoded at /etc/rc.subr: >> >> # Provide a function for normalizing the mounting of memory >> # filesystems. This should allow the rest of the code here to remain >> # as close as possible between 5-current and 4-stable. >> # $1 = size >> # $2 = mount point >> # $3 = (optional) extra mdmfs flags >> mount_md() { >> if [ -n "$3" ]; then >> flags="$3" >> fi >> /sbin/mdmfs $flags -s $1 -M md $2 >> } >> >> I would prefer it to be configurable, too. > > I did contacted keramida@ yesterday, and he seems to be happy with my > proposed patch. So, just wait for it to be committed. Yes, I like the change. I'm not an src-committer, so it is just an informed opinion by someone who eats shell scripts for breakfast, so feel free to ask the freebsd-rc@freebsd.org guys too :-) - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:23:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B17B916A438 for ; Mon, 1 Aug 2005 17:23:33 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: from web52109.mail.yahoo.com (web52109.mail.yahoo.com [206.190.48.112]) by mx1.FreeBSD.org (Postfix) with SMTP id 2FDE943D45 for ; Mon, 1 Aug 2005 17:23:33 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: (qmail 49834 invoked by uid 60001); 1 Aug 2005 17:23:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xn+eLAuY/ZlYA15F1RhBiMAUA8VrbanpoyPmXlqLIfv4mipMaWL7bNuMHdfs9Y75exo5+2s4iZoVZHYmH/xCEKEGeSt4nojQM+6hFOQH61OYU1KSQhmwspehpv0OuYBlWIISFyK06myZo8SA/UFNNuj5/Lu0FiPSMhHsFlEvA4E= ; Message-ID: <20050801172332.49832.qmail@web52109.mail.yahoo.com> Received: from [61.10.7.32] by web52109.mail.yahoo.com via HTTP; Mon, 01 Aug 2005 10:23:32 PDT Date: Mon, 1 Aug 2005 10:23:32 -0700 (PDT) From: Patrick Dung To: freebsd hackers MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: How to protect an is-spam@xxx and no-spam@xxx alias? 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, 01 Aug 2005 17:23:33 -0000 Hi I want user to forward spam mails to is-spam@mydomain.com and not spam mails to non-spam@myhomdin.com. However, I don't want the people in the internet to send mail to these to account. But the people in the internet can send mail to other user in the system. Can this be done in Sendmail (and postfix and qmail)? Regards Patrick __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:31:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6366716A41F for ; Mon, 1 Aug 2005 17:31:08 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E81BB43D49 for ; Mon, 1 Aug 2005 17:31:05 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 5E497264278 for ; Mon, 1 Aug 2005 12:29:49 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21790-09 for ; Mon, 1 Aug 2005 12:29:47 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id 7D954264053 for ; Mon, 1 Aug 2005 12:29:47 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 12:29:47 -0500 (CDT) Message-ID: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> Date: Mon, 1 Aug 2005 12:29:47 -0500 (CDT) From: diz@linuxpowered.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050801122947_40158" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [patch] rc.d cleanup 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, 01 Aug 2005 17:31:08 -0000 ------=_20050801122947_40158 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi there, This is my first patch to this project. This is the first of many patches to come actually, but I need to find a sponsor to guide me, and review what I submit. The patch is kinda big, and far reaching in terms of altering almost every rc.d script. This patch effects most of the rc.d scripts that utilize simple IF statements, converting them to logical AND/OR's instead. For example: if [ ! -f foo ] then bar fi Would simply become: [ -f foo ] || bar The exception (but not the rule) is for any situation where ELIF/ELSE is required. In other words any exclusive conditional situations. I also applied this notion to many simple blocks of code wrapped around non-exclusive IF statements, such as: [ -f foo ] && { command-list [...] } This has the result of reducing the size of the shell code, and reducing the problem of over-engineering that plagues many scripts. I found quite many places where there were one-line situations wrapped up in multi-line IF statements, which I was compelled to eliminate. Further more, as I audited the scripts, I noticed that in several places this style of scripting was already used in various places. So I feel this make the entire span of scripts uniform. -Jon Disnard ------=_20050801122947_40158-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:31:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 958D516A41F; Mon, 1 Aug 2005 17:31:52 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78FCE43D48; Mon, 1 Aug 2005 17:31:51 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j71HVlBS058423 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 19:31:49 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j71HUrJ7013214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 19:30:54 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j71HUr2u064185; Mon, 1 Aug 2005 19:30:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71HUmpo064184; Mon, 1 Aug 2005 19:30:48 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 19:30:48 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801173047.GC26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494025505080106336a329bb@mail.gmail.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 17:31:52 -0000 On Mon, Aug 01, 2005 at 04:33:23PM +0300, victor cruceru wrote: > Hi Marc, > Thanks for the info. Here it is one my situation. I have a CF reader (fully > detected by the USB subsystem) with two slots > (one with a media and one without any media). An open with O_NONBLOCK on the > empty slot (/dev/da1) is blocking me. It should not block for a long time since the device should directly reply with either ready or no media. > Is this OK? No, but it is a broken device if you don't get back in a resonable time. I don't think that O_NONBLOCK is ment to never block for a short time. In case of disks you have to ask the device for ready state, if you don't allow blocking you can't do that and therefor never successfull open a disk. The intention should read more in the sense of, don't wait for a disk to spin up, but even this is problematic to implement correct with many devices. > On 8/1/05, Marc Olzheim wrote: > > > > On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote: > > > Hi all, > > > I'm just wondering if it's OK for an open syscall on such a device (i.e. > > > /dev/acd0 or /dev/da1 with a CF reader attached) to block till the media > > is > > > ready or a timeout occurs. > > > > I'd say that depends completely on whether you supply O_NONBLOCK or not, > > so yes. > > > > Quoted from a sound driver discussion at: > > http://sourceforge.net/mailarchive/message.php?msg_id=10011826 > > > > > > On block devices, O_NONBLOCK also is a way to say "don't try to do any > > device discovery", ie you can do a O_NONBLOCK open on a removable disk > > that doesn"t even have any media in it. Again, this has _nothing_ to do > > with whether the device is "busy" or not. > > > > ... > > > > Short summary: > > > > - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag > > "early" (ie it"s conceptually equivalent to doing a "F_SETFL" fcntl > > before the open. It _may_ affect the open itself, but when it does, it > > is generally considered to mean that you can open something that isn't > > even _reachable_. > > > > - POSIX doesn't say anything much about its behaviour, except for named > > pipes, where it says the total reverse of what ALSA does. But that > > doesn't actually mean anything, because even that is very much defined > > as a special case by POSIX. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:43:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A62416A41F for ; Mon, 1 Aug 2005 17:43:58 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFCBE43D46 for ; Mon, 1 Aug 2005 17:43:57 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id j71Hhs5f045847; Mon, 1 Aug 2005 21:43:54 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 1 Aug 2005 21:43:54 +0400 (MSD) From: Dmitry Morozovsky To: Giorgos Keramidas In-Reply-To: <20050801170236.GA767@beatrix.daedalusnetworks.priv> Message-ID: <20050801214150.S43677@woozle.rinet.ru> References: <20050729211719.C95340@woozle.rinet.ru> <20050729231544.GX26656@cicely12.cicely.de> <42EE4F06.70502@jonny.eng.br> <20050801204935.D43677@woozle.rinet.ru> <20050801170236.GA767@beatrix.daedalusnetworks.priv> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (woozle.rinet.ru [0.0.0.0]); Mon, 01 Aug 2005 21:43:54 +0400 (MSD) Cc: freebsd-hackers@freebsd.org, ticso@cicely.de, =?iso-8859-7?Q?Jo=E3o?= Carlos Mendes Luis Subject: Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed 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, 01 Aug 2005 17:43:58 -0000 On Mon, 1 Aug 2005, Giorgos Keramidas wrote: GK> On 2005-08-01 20:50, Dmitry Morozovsky wrote: GK> >On Mon, 1 Aug 2005, Jo?o Carlos Mendes Luis wrote: GK> >>>> can anyone please point me why mdconfig method for tmpmfs is GK> >>>> malloc-backed instead of swap-backed, and it is hardcoded into GK> >>>> rc.subr? GK> >>>> Are swap-backed file systems so inefficient? If no, why not move -M to GK> >>>> /etc/defaultc/rc.conf so admin can override this behaviour? GK> >>> GK> >>> Diskless systems may not have swap - the default is required as is. GK> >>> Don't know about beeing hardcoded. GK> >> GK> >> It is hardcoded at /etc/rc.subr: GK> >> GK> >> # Provide a function for normalizing the mounting of memory GK> >> # filesystems. This should allow the rest of the code here to remain GK> >> # as close as possible between 5-current and 4-stable. GK> >> # $1 = size GK> >> # $2 = mount point GK> >> # $3 = (optional) extra mdmfs flags GK> >> mount_md() { GK> >> if [ -n "$3" ]; then GK> >> flags="$3" GK> >> fi GK> >> /sbin/mdmfs $flags -s $1 -M md $2 GK> >> } GK> >> GK> >> I would prefer it to be configurable, too. GK> > GK> > I did contacted keramida@ yesterday, and he seems to be happy with my GK> > proposed patch. So, just wait for it to be committed. GK> GK> Yes, I like the change. I'm not an src-committer, so it is just an GK> informed opinion by someone who eats shell scripts for breakfast, so GK> feel free to ask the freebsd-rc@freebsd.org guys too :-) Hmm. marck@woozle:/lh/src.current> whodid etc/rc.subr etc/rc.subr: 20 mtm 6 gordon 3 keramida 2 obrien 2 cperciva 1 schweikh 1 des 1 brooks I supposed you can commit there, as you already did it 3 times, and I can't see any Approved: lines in CVS logs ;-P Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:48:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8506B16A420 for ; Mon, 1 Aug 2005 17:48:14 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70A9E43D45 for ; Mon, 1 Aug 2005 17:48:13 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j71HmALb029284; Mon, 1 Aug 2005 20:48:11 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j71HmAIp001105; Mon, 1 Aug 2005 20:48:10 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j71HmAKb001104; Mon, 1 Aug 2005 20:48:10 +0300 (EEST) Date: Mon, 1 Aug 2005 20:48:10 +0300 From: Giorgos Keramidas To: Dmitry Morozovsky Message-ID: <20050801174810.GA994@beatrix.daedalusnetworks.priv> References: <20050729211719.C95340@woozle.rinet.ru> <20050729231544.GX26656@cicely12.cicely.de> <42EE4F06.70502@jonny.eng.br> <20050801204935.D43677@woozle.rinet.ru> <20050801170236.GA767@beatrix.daedalusnetworks.priv> <20050801214150.S43677@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801214150.S43677@woozle.rinet.ru> Cc: freebsd-hackers@freebsd.org, ticso@cicely.de, =?iso-8859-7?Q?Jo=E3o?= Carlos Mendes Luis Subject: Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed 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, 01 Aug 2005 17:48:14 -0000 On 2005-08-01 21:43, Dmitry Morozovsky wrote: > On Mon, 1 Aug 2005, Giorgos Keramidas wrote: > GK> Yes, I like the change. I'm not an src-committer, so it is just an > GK> informed opinion by someone who eats shell scripts for breakfast, so > GK> feel free to ask the freebsd-rc@freebsd.org guys too :-) > > Hmm. > > marck@woozle:/lh/src.current> whodid etc/rc.subr > etc/rc.subr: > 20 mtm > 6 gordon > 3 keramida > 2 obrien > 2 cperciva > 1 schweikh > 1 des > 1 brooks > > I supposed you can commit there, as you already did it 3 times, and I > can't see any Approved: lines in CVS logs ;-P The change was marked as "Reviewed by:" mtm@ though. If I got the wrong line in the commit log, then it was a bug of the commit log I guess. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:49:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D44F816A420 for ; Mon, 1 Aug 2005 17:49:35 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C2643D76 for ; Mon, 1 Aug 2005 17:49:26 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from dialup84116-56.ip.peterstar.net ([84.204.116.56] helo=doom.homeunix.org) by voodoo.oberon.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1DzePB-000GAk-6K for freebsd-hackers@freebsd.org; Mon, 01 Aug 2005 19:48:50 +0200 Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.13.3/8.13.3) with ESMTP id j71HmgcL000724; Mon, 1 Aug 2005 21:48:42 +0400 (MSD) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.13.3/8.13.3/Submit) id j6VH86qK012106; Sun, 31 Jul 2005 21:08:06 +0400 (MSD) (envelope-from igor) Date: Sun, 31 Jul 2005 21:08:06 +0400 From: Igor Pokrovsky To: KOMATSU Shinichiro Message-ID: <20050731170806.GA7783@doom.homeunix.org> Mail-Followup-To: KOMATSU Shinichiro , Olivier Certner , freebsd-hackers@freebsd.org, Kris Kennaway , Florent Thoumie References: <200507102313.12719.olivier.certner@free.fr> <20050712165530.GA5475@xor.obsecurity.org> <1121189986.6598.1.camel@cream.xbsd.org> <200507130015.31521.olivier.certner@free.fr> <42EC38C9.8070402@lovepeers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42EC38C9.8070402@lovepeers.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, Florent Thoumie , Kris Kennaway Subject: Re: Bug in portupgrade 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, 01 Aug 2005 17:49:36 -0000 On Sun, Jul 31, 2005 at 11:34:49AM +0900, KOMATSU Shinichiro wrote: > Hello. > > Olivier Certner wrote: > >Le Mardi 12 Juillet 2005 19:39, Florent Thoumie a ?crit : > > > >>Le Mardi 12 juillet 2005 ? 12:55 -0400, Kris Kennaway a ?crit : > >> > >>>On Sun, Jul 10, 2005 at 11:13:12PM +0200, Olivier Certner wrote: > >>> > >>>> Hi, > >>>> > >>>> There is a bug with portupgrade when it is used to upgrade already > >>>>compiled and installed ports for which some dependencies have been > >>>>deleted in the package database. This causes a crash in the function > >>>>'deorigin' in pkgdb.rb. > >>>> > >>>> Since I don't know the internals of portupgrade, I don't know if it's > >>>>normal to call 'deorigin' with its argument set to nil. If it is, then > >>>>the patch below might be useful (beware, I don't know any ruby, I've > >>>>just tried something and it works), if it is not, I only can provide > >>>>the stack (see below) in order for maintainers to seek the faulty > >>>>callers. > >>> > >>>Please talk to the port maintainer. > >> > >> Yeah, and good luck :) > >> > >> Otherwise, he can try to pkgdb -F or remove pkgdb.rb and re-run > >> portupgrade. > > > > > > This doesn't work in fact. I'm forwarding these mails to the > > maintainer. > > Sorry for my late reply, but would you try out the following patch? > > > Index: lib/portsdb.rb > =================================================================== > --- lib/portsdb.rb (revision 37) > +++ lib/portsdb.rb (revision 38) > @@ -846,7 +846,7 @@ > > def all_depends_list(origin, before_args = nil, after_args = nil) > if !before_args && !after_args && i = port(origin) > - i.all_depends.map { |n| origin(n) } > + i.all_depends.map { |n| origin(n) }.compact > else > all_depends_list!(origin, before_args, after_args) > end > _______________________________________________ > 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" Thanks! It works. Does it have a chance to be committed? -ip -- Never leave hold of what you've got until you've got hold of something else. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:56:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B7C116A41F for ; Mon, 1 Aug 2005 17:56:06 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEA6E43D45 for ; Mon, 1 Aug 2005 17:56:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 01 Aug 2005 14:10:40 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 1 Aug 2005 13:55:18 -0400 User-Agent: KMail/1.8 References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> In-Reply-To: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508011355.19274.jhb@FreeBSD.org> Cc: Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 17:56:06 -0000 On Monday 01 August 2005 01:29 pm, diz@linuxpowered.com wrote: > Hi there, > > This is my first patch to this project. > This is the first of many patches to come actually, but I need to find a > sponsor to guide me, and review what I submit. The patch is kinda big, and > far reaching in terms of altering almost every rc.d script. > > This patch effects most of the rc.d scripts that utilize simple IF > statements, converting them to logical AND/OR's instead. For example: > > if [ ! -f foo ] > then > bar > fi > > Would simply become: > > [ -f foo ] || bar > > The exception (but not the rule) is for any situation where ELIF/ELSE is > required. In other words any exclusive conditional situations. > > I also applied this notion to many simple blocks of code wrapped around > non-exclusive IF statements, such as: > > [ -f foo ] && { > command-list > [...] > } > > This has the result of reducing the size of the shell code, and reducing > the problem of over-engineering that plagues many scripts. I found quite > many places where there were one-line situations wrapped up in multi-line > IF statements, which I was compelled to eliminate. Further more, as I > audited the scripts, I noticed that in several places this style of > scripting was already used in various places. So I feel this make the > entire span of scripts uniform. > > > -Jon Disnard The argument I would have against this is that it is a lot easier to read the 'if foo; then ; fi' style, esp. for folks used to using C, etc. Shell scripts don't need to be overly obfuscated. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:02:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19D8516A41F; Mon, 1 Aug 2005 18:02:58 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24EB743D45; Mon, 1 Aug 2005 18:02:56 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j71I2soG010942; Mon, 1 Aug 2005 21:02:54 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j71I2sgG001213; Mon, 1 Aug 2005 21:02:54 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j71I2s5V001212; Mon, 1 Aug 2005 21:02:54 +0300 (EEST) Date: Mon, 1 Aug 2005 21:02:54 +0300 From: Giorgos Keramidas To: John Baldwin Message-ID: <20050801180254.GB1176@beatrix.daedalusnetworks.priv> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508011355.19274.jhb@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 18:02:58 -0000 On 2005-08-01 13:55, John Baldwin wrote: >On Monday 01 August 2005 01:29 pm, diz@linuxpowered.com wrote: >> This patch effects most of the rc.d scripts that utilize simple IF >> statements, converting them to logical AND/OR's instead. For example: >> >> if [ ! -f foo ] >> then >> bar >> fi >> >> Would simply become: >> >> [ -f foo ] || bar >> >> The exception (but not the rule) is for any situation where ELIF/ELSE is >> required. In other words any exclusive conditional situations. >> >> I also applied this notion to many simple blocks of code wrapped around >> non-exclusive IF statements, such as: >> >> [ -f foo ] && { >> command-list >> [...] >> } > > The argument I would have against this is that it is a lot easier to > read the 'if foo; then ; fi' style, esp. for folks used to using C, > etc. Shell scripts don't need to be overly obfuscated. Ditto. The if/then blocks may look superficial at first and entirely redundant, but they really work much better then code like this: [ -f foo ] || bar has to be extended to form a multiline statement. Now, I know that one can always write: [ -f foo ] || { [ -d bar ] && { blah } } But this quickly gets too ugly for my taste. The equivalent if/then blocks: if [ ! -f foo ]; then if [ -d bar ]; then blah fi fi or even, the similar: if [ ! -f foo ] && [ -d bar ]; then blah fi Look much much prettier to the eyes of one who knows how to read both shell scripts and C code. - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:10:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1899516A41F; Mon, 1 Aug 2005 18:10:15 +0000 (GMT) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B1143D45; Mon, 1 Aug 2005 18:10:14 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id CE56F5C793; Mon, 1 Aug 2005 11:10:14 -0700 (PDT) Date: Mon, 1 Aug 2005 20:10:14 +0200 From: Maxime Henrion To: Giorgos Keramidas Message-ID: <20050801181014.GA14567@elvis.mu.org> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801180254.GB1176@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 18:10:15 -0000 Giorgos Keramidas wrote: > On 2005-08-01 13:55, John Baldwin wrote: > >On Monday 01 August 2005 01:29 pm, diz@linuxpowered.com wrote: > >> This patch effects most of the rc.d scripts that utilize simple IF > >> statements, converting them to logical AND/OR's instead. For example: > >> > >> if [ ! -f foo ] > >> then > >> bar > >> fi > >> > >> Would simply become: > >> > >> [ -f foo ] || bar > >> > >> The exception (but not the rule) is for any situation where ELIF/ELSE is > >> required. In other words any exclusive conditional situations. > >> > >> I also applied this notion to many simple blocks of code wrapped around > >> non-exclusive IF statements, such as: > >> > >> [ -f foo ] && { > >> command-list > >> [...] > >> } > > > > The argument I would have against this is that it is a lot easier to > > read the 'if foo; then ; fi' style, esp. for folks used to using C, > > etc. Shell scripts don't need to be overly obfuscated. > > Ditto. The if/then blocks may look superficial at first and entirely > redundant, but they really work much better then code like this: > > [ -f foo ] || bar > > has to be extended to form a multiline statement. Now, I know that one > can always write: > > [ -f foo ] || { > [ -d bar ] && { > blah > } > } > > But this quickly gets too ugly for my taste. The equivalent if/then > blocks: > > if [ ! -f foo ]; then > if [ -d bar ]; then > blah > fi > fi > > or even, the similar: > > if [ ! -f foo ] && [ -d bar ]; then > blah > fi > > Look much much prettier to the eyes of one who knows how to read both > shell scripts and C code. Thirded. I far prefer the bigger C-like if statements and think this patch is a huge code churn for what is basically code obfuscation. Cheers, Maxime From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:28:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F02116A41F for ; Mon, 1 Aug 2005 18:28:55 +0000 (GMT) (envelope-from ca+envelope@esmtp.org) Received: from zardoc.esmtp.org (adsl-63-195-85-27.dsl.snfc21.pacbell.net [63.195.85.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A44B43D45 for ; Mon, 1 Aug 2005 18:28:54 +0000 (GMT) (envelope-from ca+envelope@esmtp.org) Received: from zardoc.esmtp.org (localhost.endmail.org. [127.0.0.1]) by zardoc.esmtp.org (sendmail X.0.0.Alpha9.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=AES256-SHA, bits=256, verify=NO) id S000000000007C0D100; Mon, 1 Aug 2005 11:29:32 -0700 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.0/8.12.10.Beta0/Submit) id j71ITWSV028029; Mon, 1 Aug 2005 11:29:32 -0700 (PDT) Date: Mon, 1 Aug 2005 11:29:32 -0700 From: Claus Assmann To: Patrick Dung Message-ID: <20050801182932.GA24057@zardoc.esmtp.org> References: <20050801172332.49832.qmail@web52109.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801172332.49832.qmail@web52109.mail.yahoo.com> User-Agent: Mutt/1.5.6i Cc: freebsd hackers Subject: Re: How to protect an is-spam@xxx and no-spam@xxx alias? 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, 01 Aug 2005 18:28:55 -0000 On Mon, Aug 01, 2005, Patrick Dung wrote: > However, I don't want the people in the internet to send mail to these > to account. But the people in the internet can send mail to other user > in the system. > Can this be done in Sendmail (and postfix and qmail)? For sendmail 8: http://www.sendmail.org/~ca/email/protected.html For sendmail X: http://www.sendmail.org/~ca/email/sm-X/doc-X.0.0.Alpha9.0/README.html#SECTION004102000000000000000 From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:30:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B97A16A41F; Mon, 1 Aug 2005 18:30:22 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 538F743D46; Mon, 1 Aug 2005 18:30:19 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 78C05264278; Mon, 1 Aug 2005 13:29:02 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26487-06; Mon, 1 Aug 2005 13:29:00 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id BD5B2264053; Mon, 1 Aug 2005 13:29:00 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 13:29:00 -0500 (CDT) Message-ID: <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> In-Reply-To: <20050801181014.GA14567@elvis.mu.org> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> <20050801181014.GA14567@elvis.mu.org> Date: Mon, 1 Aug 2005 13:29:00 -0500 (CDT) From: diz@linuxpowered.com To: "Maxime Henrion" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 18:30:22 -0000 > Giorgos Keramidas wrote: >> On 2005-08-01 13:55, John Baldwin wrote: >> >On Monday 01 August 2005 01:29 pm, diz@linuxpowered.com wrote: >> >> This patch effects most of the rc.d scripts that utilize simple IF >> >> statements, converting them to logical AND/OR's instead. For example: >> >> >> >> if [ ! -f foo ] >> >> then >> >> bar >> >> fi >> >> >> >> Would simply become: >> >> >> >> [ -f foo ] || bar >> >> >> >> The exception (but not the rule) is for any situation where ELIF/ELSE >> is >> >> required. In other words any exclusive conditional situations. >> >> >> >> I also applied this notion to many simple blocks of code wrapped >> around >> >> non-exclusive IF statements, such as: >> >> >> >> [ -f foo ] && { >> >> command-list >> >> [...] >> >> } >> > >> > The argument I would have against this is that it is a lot easier to >> > read the 'if foo; then ; fi' style, esp. for folks used to using C, >> > etc. Shell scripts don't need to be overly obfuscated. >> >> Ditto. The if/then blocks may look superficial at first and entirely >> redundant, but they really work much better then code like this: >> >> [ -f foo ] || bar >> >> has to be extended to form a multiline statement. Now, I know that one >> can always write: >> >> [ -f foo ] || { >> [ -d bar ] && { >> blah >> } >> } >> >> But this quickly gets too ugly for my taste. The equivalent if/then >> blocks: >> >> if [ ! -f foo ]; then >> if [ -d bar ]; then >> blah >> fi >> fi >> >> or even, the similar: >> >> if [ ! -f foo ] && [ -d bar ]; then >> blah >> fi >> >> Look much much prettier to the eyes of one who knows how to read both >> shell scripts and C code. > > Thirded. I far prefer the bigger C-like if statements and think this > patch is a huge code churn for what is basically code obfuscation. > > Cheers, > Maxime Well I certainly respect the opinions, but respectfully when has the use of && and || become obfuscation? Secondly, the use of shell style blocks of code is similar to the way they are done in C where curly-braces are used to enclose blocks of code. I honestly don't believe that it is because of people who look at C and shell code, it is probably more due to the foundation of all that existing shell code we read that does use IF statements instead of logical AND/OR. What is the point of using a bulky IF statement for the evaluating simple true/false situation that the shell supports with && or ||? I would characterize this patch as a simplification, or rounding down to the lowest common denominator. It doesn't touch the parts that require the bulky ELIF/ELSE's, just the simple conditions. However, I would be willing to make the patch less "code-churning" to only affect the non-blocks of code, aka one-liners like: [-f foo ] && bar. I don't have the intention to obfusecate, just good shell code. =) -Jon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:41:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B262416A41F for ; Mon, 1 Aug 2005 18:41:32 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 192D843D46 for ; Mon, 1 Aug 2005 18:41:31 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i1so1090435wra for ; Mon, 01 Aug 2005 11:41:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aKjbfLMQNZ+aiw1IYXoqbqu5TcrRkwkzj0zW+au8fcifqFOk/nfn+4XzdC+4IdtKsh5FF0JA9j6sDHAzQ0JgFEZGO0GP4wJMVG+pp8YaIlaVI/YhA0GZjEY0kqe4hp1vnAotudGG4/ucTyY7OI9un3ouaht+t2jamoeMfxqM/78= Received: by 10.54.83.5 with SMTP id g5mr3131288wrb; Mon, 01 Aug 2005 11:41:30 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Mon, 1 Aug 2005 11:41:30 -0700 (PDT) Message-ID: <4940255050801114161c1cea3@mail.gmail.com> Date: Mon, 1 Aug 2005 21:41:30 +0300 From: victor cruceru To: ticso@cicely.de In-Reply-To: <20050801173047.GC26656@cicely12.cicely.de> Mime-Version: 1.0 References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:41:32 -0000 Well, if you are doing this from a daemon (multiplexing a lot of events)=20 which is blocked in this open syscall, even 1 second is not reasonable. In= =20 my case it is something more than 30 of seconds (again, on a 5.4 box). I'll= =20 give it a try on FreeBSD 6. I'm currently investigating if there is=20 something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be issue= d=20 on a control device (i.e. /dev/ata) BR,=20 Victor Cruceru On 8/1/05, Bernd Walter wrote: >=20 > On Mon, Aug 01, 2005 at 04:33:23PM +0300, victor cruceru wrote: > > Hi Marc, > > Thanks for the info. Here it is one my situation. I have a CF reader=20 > (fully > > detected by the USB subsystem) with two slots > > (one with a media and one without any media). An open with O_NONBLOCK o= n=20 > the > > empty slot (/dev/da1) is blocking me. >=20 > It should not block for a long time since the device should directly > reply with either ready or no media. >=20 > > Is this OK? >=20 > No, but it is a broken device if you don't get back in a resonable > time. > I don't think that O_NONBLOCK is ment to never block for a short time. > In case of disks you have to ask the device for ready state, if you > don't allow blocking you can't do that and therefor never successfull > open a disk. > The intention should read more in the sense of, don't wait for a disk > to spin up, but even this is problematic to implement correct with many > devices. >=20 > > On 8/1/05, Marc Olzheim wrote: > > > > > > On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote: > > > > Hi all, > > > > I'm just wondering if it's OK for an open syscall on such a device = ( > i.e. > > > > /dev/acd0 or /dev/da1 with a CF reader attached) to block till the= =20 > media > > > is > > > > ready or a timeout occurs. > > > > > > I'd say that depends completely on whether you supply O_NONBLOCK or= =20 > not, > > > so yes. > > > > > > Quoted from a sound driver discussion at: > > > http://sourceforge.net/mailarchive/message.php?msg_id=3D10011826 > > > > > > > > > On block devices, O_NONBLOCK also is a way to say "don't try to do an= y > > > device discovery", ie you can do a O_NONBLOCK open on a removable dis= k > > > that doesn"t even have any media in it. Again, this has _nothing_ to= =20 > do > > > with whether the device is "busy" or not. > > > > > > ... > > > > > > Short summary: > > > > > > - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK= =20 > flag > > > "early" (ie it"s conceptually equivalent to doing a "F_SETFL" fcntl > > > before the open. It _may_ affect the open itself, but when it does, i= t > > > is generally considered to mean that you can open something that isn'= t > > > even _reachable_. > > > > > > - POSIX doesn't say anything much about its behaviour, except for=20 > named > > > pipes, where it says the total reverse of what ALSA does. But that > > > doesn't actually mean anything, because even that is very much define= d > > > as a special case by POSIX. >=20 > -- > B.Walter BWCT http://www.bwct.de > bernd@bwct.de info@bwct.de >=20 > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:48:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1981D16A41F; Mon, 1 Aug 2005 18:48:04 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD05A43D75; Mon, 1 Aug 2005 18:47:51 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j71IllBS060752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 20:47:49 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j71IlWJ7013665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 20:47:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j71IlVSs064656; Mon, 1 Aug 2005 20:47:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71IlVW2064655; Mon, 1 Aug 2005 20:47:31 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 20:47:31 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801184731.GD26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4940255050801114161c1cea3@mail.gmail.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: Marc Olzheim , freebsd-hackers@freebsd.org, ticso@cicely.de Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:48:04 -0000 On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: > Well, if you are doing this from a daemon (multiplexing a lot of events) > which is blocked in this open syscall, even 1 second is not reasonable. In > my case it is something more than 30 of seconds (again, on a 5.4 box). I'll > give it a try on FreeBSD 6. I'm currently investigating if there is > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be issued > on a control device (i.e. /dev/ata) What do you expect it to do? Ask the device about the state or always fail, because it is not allowed to ask the device? In your case you have a broken device, this isn't much of an argument. A resonable reply time for a USB device would be less then 10ms. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:59:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3343116A432; Mon, 1 Aug 2005 18:59:27 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E7B43D46; Mon, 1 Aug 2005 18:59:26 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with SMTP id j71IxNg9077612; Mon, 1 Aug 2005 11:59:23 -0700 (PDT) (envelope-from frank@exit.com) Date: Mon, 1 Aug 2005 11:59:21 -0700 From: Frank Mayhar To: diz@linuxpowered.com Message-Id: <20050801115921.5ee26b78.frank@exit.com> In-Reply-To: <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> <20050801181014.GA14567@elvis.mu.org> <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> Organization: Exit Consulting X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1000/Sun Jul 31 12:28:06 2005 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 18:59:27 -0000 On Mon, 1 Aug 2005 13:29:00 -0500 (CDT) diz@linuxpowered.com wrote: > Well I certainly respect the opinions, but respectfully when has the use > of && and || become obfuscation? Secondly, the use of shell style blocks > of code is similar to the way they are done in C where curly-braces are > used to enclose blocks of code. I honestly don't believe that it is > because of people who look at C and shell code, it is probably more due to > the foundation of all that existing shell code we read that does use IF > statements instead of logical AND/OR. That may be true for you, but I suspect that you don't write much (if any) C, do you? When one is accustomed to seeing standard if/else with proper indentation, the kind of thing you propose is indeed obfuscatory. This is one of the reasons that Perl is nearly unmaintainable, and that is the name of the game in one word: Maintainability. Most of us aren't experts in /bin/{ba}sh syntax, nor will we be. > What is the point of using a bulky > IF statement for the evaluating simple true/false situation that the shell > supports with && or ||? The point is that it is more clear. It expresses exactly what it is: A conditional statement in a programming language. The "&&" and "||" syntax is just a shortcut to do the same thing. Like most shortcuts, it has its place, but should be avoided when writing for a general audience. Ghods know I'm as guilty as anyone of violating this rule, but I try... -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:04:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AC0316A41F for ; Mon, 1 Aug 2005 19:04:27 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A162443D45 for ; Mon, 1 Aug 2005 19:04:26 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so1066388wra for ; Mon, 01 Aug 2005 12:04:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VWzgJI//oyM6VrOS42nYhJJTm03wOM5L+o8Viz3S5WKIF/7Rf+t5860tyyGGPTZqziSjpzppY/t5jsdv/9La5+Ep/7AAxWwPK/OaaCsYP8MRsvNWz0mhsCAsiiDsQ5AyjJnFPTVC2FJe7Fbz7mmDBl7HQ3InYLIlCJg1iWBv5+U= Received: by 10.54.57.62 with SMTP id f62mr3141710wra; Mon, 01 Aug 2005 12:04:25 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Mon, 1 Aug 2005 12:04:25 -0700 (PDT) Message-ID: <494025505080112043f8a0554@mail.gmail.com> Date: Mon, 1 Aug 2005 22:04:25 +0300 From: victor cruceru To: ticso@cicely.de In-Reply-To: <20050801184731.GD26656@cicely12.cicely.de> Mime-Version: 1.0 References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> <20050801184731.GD26656@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 19:04:27 -0000 In conclusion:=20 any difference between open with O_NONBLOCK and open without it for this=20 kind of devices? Because man 2 open says: ---------------------------------------------------------------------------= ------------------------- If the O_NONBLOCK flag is specified and the open() system call would result= =20 in the process being blocked for some reason (e.g., waiting for carrier on a dialup line), open() returns immediately. The descriptor remains in non- blocking mode for subsequent operations. ---------------------------------------------------------------------------= ------------------------- Thanks victor cruceru On 8/1/05, Bernd Walter wrote: >=20 > On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: > > Well, if you are doing this from a daemon (multiplexing a lot of events= ) > > which is blocked in this open syscall, even 1 second is not reasonable.= =20 > In > > my case it is something more than 30 of seconds (again, on a 5.4 box).= =20 > I'll > > give it a try on FreeBSD 6. I'm currently investigating if there is > > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be= =20 > issued > > on a control device (i.e. /dev/ata) >=20 > What do you expect it to do? > Ask the device about the state or always fail, because it is not > allowed to ask the device? > In your case you have a broken device, this isn't much of an argument. > A resonable reply time for a USB device would be less then 10ms. >=20 > -- > B.Walter BWCT http://www.bwct.de > bernd@bwct.de info@bwct.de >=20 > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:20:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B215016A41F; Mon, 1 Aug 2005 19:20:53 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B8B643D49; Mon, 1 Aug 2005 19:20:52 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j71JKmBS061528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 21:20:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j71JK1J7013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 21:20:02 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j71JK1id064837; Mon, 1 Aug 2005 21:20:01 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71JK1Zg064836; Mon, 1 Aug 2005 21:20:01 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 21:20:00 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801192000.GE26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> <20050801184731.GD26656@cicely12.cicely.de> <494025505080112043f8a0554@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494025505080112043f8a0554@mail.gmail.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: Marc Olzheim , freebsd-hackers@freebsd.org, ticso@cicely.de Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 19:20:53 -0000 On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: > In conclusion: > any difference between open with O_NONBLOCK and open without it for this > kind of devices? > Because man 2 open says: > ---------------------------------------------------------------------------------------------------- > If the O_NONBLOCK flag is specified and the open() system call would result > in > the process being blocked for some reason (e.g., waiting for carrier on a > dialup line), open() returns immediately. The descriptor remains in non- > blocking mode for subsequent operations. > ---------------------------------------------------------------------------------------------------- Then make it always fail for disk devices. I really don't know what you expect to win with this. There is no other choice. There are many short time blocks you won't noice, e.g. openeing a device requiring GIANT or any other lock. You can't open any kind device without a risk to block for a very short time. But still you are talking about a broken device - replace or fix it and return to real problems. Really - a disk should know if it is ready or not and I won't call it blocking if you ask a disk about it. If you want a workaround then fork another process opening the device for you and passing the descriptor back to you via domain socket. > On 8/1/05, Bernd Walter wrote: > > > > On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: > > > Well, if you are doing this from a daemon (multiplexing a lot of events) > > > which is blocked in this open syscall, even 1 second is not reasonable. > > In > > > my case it is something more than 30 of seconds (again, on a 5.4 box). > > I'll > > > give it a try on FreeBSD 6. I'm currently investigating if there is > > > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be > > issued > > > on a control device (i.e. /dev/ata) > > > > What do you expect it to do? > > Ask the device about the state or always fail, because it is not > > allowed to ask the device? > > In your case you have a broken device, this isn't much of an argument. > > A resonable reply time for a USB device would be less then 10ms. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:23:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7957D16A41F; Mon, 1 Aug 2005 19:23:31 +0000 (GMT) (envelope-from carlson39@llnl.gov) Received: from smtp-3.llnl.gov (smtp-3.llnl.gov [128.115.41.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A94143D49; Mon, 1 Aug 2005 19:23:31 +0000 (GMT) (envelope-from carlson39@llnl.gov) Received: from wushu.llnl.gov (localhost [127.0.0.1]) by smtp-3.llnl.gov (8.12.3p2-20030917/8.12.3/LLNL evision: 1.16 $) with ESMTP id j71JNTMq010618; Mon, 1 Aug 2005 12:23:30 -0700 (PDT) From: Michael Carlson To: ray@redshift.com In-Reply-To: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> References: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> Date: Mon, 01 Aug 2005 12:23:29 -0700 Message-Id: <1122924209.19849.18.camel@wushu.llnl.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-x11@freebsd.org Subject: Re: FreeBSD desktop? 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, 01 Aug 2005 19:23:31 -0000 Hello Ray, I've been using FreeBSD 5.x as my primary desktop for almost a year now, and I've used it as a secondary for years. It can be a little difficult when compared to something like like Redhat but once you get it going its wonderful. First, you should update your ports, I use a cvsup script like this one: *default host=cvsup10.freebsd.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress ports-all Then I usually run portupgrade -ra, this will sort out any dependencies especially with libraries changing so often, After that, install the xorg window system. This is sort of the back-end to a nice GUI interface. $ cd /usr/ports/x11/xorg $ make clean install Then, pick a Window Manager you would like, I constatnly switch between Gnome, KDE and XFCE for no real reason, I just like the variety. But if you dont want to wait a couple of days, XFCE is probably the lightest Window Manager. $ cd /usr/ports/x11-wm/xfce-4 $ make clean install Do you want a session manager to come up automatically? You can use the default xdm, but I prefer gdm or kdm. $ cd /usr/ports/x11/gdm $ make clean install $ chmod +x /usr/X11R6/etc/rc.d/gdm.sh That should get you up and running. If you have a nVidia card, I recommend installing the driver in /usr/ports/x11/nvidia-driver. After all is said and done, run xorgcfg(1) to get a basic xorg.conf file created. Thats off the top of my head, be sure to check the handbook and google :) Mike C On Mon, 2005-08-01 at 04:36 -0700, ray@redshift.com wrote: > Maybe someone on the hackers or x11 list can help me get going the right > direction here. I can setup FreeBSD servers like the wind - tweak the kernel, > you name it. So this weekend I tried to install FreeBSD 5.4 on my desktop - > what a mess. I never could get anything to run, other than startx or xstart or > something. I ended up once with a blank desktop (I think I typed X) and another > time with the same desktop, but with 3 open windows. Anyway, I finally gave up. > > Anyone have any run down on loading FreeBSD as your desktop? I am trying to > go with FreeBSD because I use it for my servers, but I feel like I'm lacking a > broad understanding of how Unix handles windows. I get the impression there is > a server that deals with windows called X windows and then there are different > desktop managers (such as KDE, Gnome, etc) - but I don't understand the > interplay between them and the Kernel as it relates to how I normally see FreeBSD. > > I'm wondering if someone can give me an overview? > > I'm also wondering if I'm barking up the wrong tree. I know Mac uses Darwin, > which is based on BSD. And in the past, I have loaded up Redhat and SUSE and > ended up with a nice desktop - but with FreeBSD I didn't have much luck, even > though I installed just about everything on the install CD's. From what I could > see, there were a ton of things to configure, but I couldn't find any good > documentation on setting up my monitor or what the heck was going on overall - > even in my BSD books, not a lot of help. > > Anyway, I am wondering if maybe running SUSE or Fedora or something might be > better. I'm reading one article right now that says this thing called Xandros > Desktop 3 is great - so far it looks nice in the article and I may give that a try. > > I've been using Windows XP for my desktop for so long and am so used to so > many applications on it - I think it would be difficult (at this time) to change > over completely. Unless Wine really does work well enough to run some > applications I can't live without (e.g. Eudora or Pagemaker, etc). > > Anyway, any help anyone can provide would be great? I just feel like I'm > lacking a core understanding of how Windowing and desktop interfaces to the > Kernel. And like I say, as much as I would like to make this all happen on > FreeBSD, it seems like Linux maybe is a better choice? > > Anyone? > > Ray > > > > _______________________________________________ > 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 Mon Aug 1 19:44:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE9C16A41F for ; Mon, 1 Aug 2005 19:44:48 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C1AE43D45 for ; Mon, 1 Aug 2005 19:44:47 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so1073847wra for ; Mon, 01 Aug 2005 12:44:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KfsZNmjwyr6Oe6ARrby6BEn+azUPmSqKt+BtWy4u8fVfyoCEBPPQzQH4yZqp4BWajlNVg6FS6LJfxZVg1VqyuhTo3vFTRn12vKz1FjK6P+g9/0z7d46HmpuDddU/EjVxfVnxnIGvyULKUFaukQsdpUICU1qHDNXxjB5AN9z7uzE= Received: by 10.54.137.14 with SMTP id k14mr911739wrd; Mon, 01 Aug 2005 12:44:46 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Mon, 1 Aug 2005 12:44:46 -0700 (PDT) Message-ID: <494025505080112441ac23dfa@mail.gmail.com> Date: Mon, 1 Aug 2005 22:44:46 +0300 From: victor cruceru To: ticso@cicely.de In-Reply-To: <20050801192000.GE26656@cicely12.cicely.de> Mime-Version: 1.0 References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> <20050801184731.GD26656@cicely12.cicely.de> <494025505080112043f8a0554@mail.gmail.com> <20050801192000.GE26656@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 19:44:48 -0000 See below. On 8/1/05, Bernd Walter wrote: >=20 > On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: > > In conclusion: > > any difference between open with O_NONBLOCK and open without it for thi= s > > kind of devices? > > Because man 2 open says: > >=20 > -------------------------------------------------------------------------= --------------------------- > > If the O_NONBLOCK flag is specified and the open() system call would=20 > result > > in > > the process being blocked for some reason (e.g., waiting for carrier on= =20 > a > > dialup line), open() returns immediately. The descriptor remains in non= - > > blocking mode for subsequent operations. > >=20 > -------------------------------------------------------------------------= --------------------------- >=20 > Then make it always fail for disk devices. This is not a solution.=20 I really don't know what you expect to win with this. > There is no other choice. There are many short time blocks you won't noice, e.g. openeing a > device requiring GIANT or any other lock. > You can't open any kind device without a risk to block for a very > short time. It is OK if this is short (10-20 ms). But still you are talking about a broken device - replace or fix it > and return to real problems. Yes, this it is maybe true, but why to block in a driver if the user told= =20 not to do it? On the other hand all the HW is broken somehow... So this O_NONBLOCK should= =20 be a way to deal with this kind of silly devices. Really - a disk should know if it is ready or not and I won't call > it blocking if you ask a disk about it. >=20 > If you want a workaround then fork another process opening the device > for you and passing the descriptor back to you via domain socket. This is too complicated to be useful. Maybe to spawn a thread - this is als= o=20 too complicated for getting the capacity of a damn media (this is my=20 situation). > On 8/1/05, Bernd Walter wrote: > > > > > > On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: > > > > Well, if you are doing this from a daemon (multiplexing a lot of=20 > events) > > > > which is blocked in this open syscall, even 1 second is not=20 > reasonable. > > > In > > > > my case it is something more than 30 of seconds (again, on a 5.4box= ). > > > I'll > > > > give it a try on FreeBSD 6. I'm currently investigating if there is > > > > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can= =20 > be > > > issued > > > > on a control device (i.e. /dev/ata) > > > > > > What do you expect it to do? > > > Ask the device about the state or always fail, because it is not > > > allowed to ask the device? > > > In your case you have a broken device, this isn't much of an argument= . > > > A resonable reply time for a USB device would be less then 10ms. >=20 > -- > B.Walter BWCT http://www.bwct.de > bernd@bwct.de info@bwct.de Thanks victor cruceru From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:57:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A950916A41F; Mon, 1 Aug 2005 19:57:53 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C205A43D48; Mon, 1 Aug 2005 19:57:52 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j71JvmBS062280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 21:57:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j71JveJ7014092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 21:57:41 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j71Jve6q065051; Mon, 1 Aug 2005 21:57:40 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71Jvdh5065050; Mon, 1 Aug 2005 21:57:40 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 21:57:39 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801195739.GF26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> <20050801184731.GD26656@cicely12.cicely.de> <494025505080112043f8a0554@mail.gmail.com> <20050801192000.GE26656@cicely12.cicely.de> <494025505080112441ac23dfa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494025505080112441ac23dfa@mail.gmail.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: Marc Olzheim , freebsd-hackers@freebsd.org, ticso@cicely.de Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 19:57:53 -0000 On Mon, Aug 01, 2005 at 10:44:46PM +0300, victor cruceru wrote: > See below. > > On 8/1/05, Bernd Walter wrote: > > > > On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: > > device requiring GIANT or any other lock. > > You can't open any kind device without a risk to block for a very > > short time. > > > It is OK if this is short (10-20 ms). Well - you have an USB frame every ms, so you can have multiple transactions in that time. One can really expect a device to react within that time. > But still you are talking about a broken device - replace or fix it > > and return to real problems. > > > Yes, this it is maybe true, but why to block in a driver if the user told > not to do it? Because progammers asumed non broken devices? > On the other hand all the HW is broken somehow... So this O_NONBLOCK should > be a way to deal with this kind of silly devices. Yes, ut USB devices are sometime horribly broken. It is really the question if we want workarouds for all and everything possible. Theoretically you can have a short timeout for such a request, but its complicated to handle USB timeouts for umass devices - you need to resync the whole transmission channel, which efefctivly is very much like a device reset. AFAIK these kind of resets are done in sync, so you still would block just to do the reset, which take seconds. On the other hand this would non-block the open call, but still not open the device, so you just stop the application from using it. > Really - a disk should know if it is ready or not and I won't call > > it blocking if you ask a disk about it. > > > > If you want a workaround then fork another process opening the device > > for you and passing the descriptor back to you via domain socket. > > > This is too complicated to be useful. Maybe to spawn a thread - this is also > too complicated for getting the capacity of a damn media (this is my > situation). This is less complicated than a kernel workaround and it even allows to use the device. But yes, it's still evil. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 20:00:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF95A16A41F for ; Mon, 1 Aug 2005 20:00:13 +0000 (GMT) (envelope-from fgleiser@cactus.fi.uba.ar) Received: from cactus.fi.uba.ar (cactus.fi.uba.ar [157.92.49.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1413343D6A for ; Mon, 1 Aug 2005 20:00:10 +0000 (GMT) (envelope-from fgleiser@cactus.fi.uba.ar) Received: from localhost (localhost [127.0.0.1]) by cactus.fi.uba.ar (8.13.3/8.13.3) with ESMTP id j71JxtZB056357; Mon, 1 Aug 2005 16:59:56 -0300 (ART) (envelope-from fgleiser@cactus.fi.uba.ar) Date: Mon, 1 Aug 2005 16:59:55 -0300 (ART) From: Fernando Gleiser To: Patrick Dung In-Reply-To: <20050801172332.49832.qmail@web52109.mail.yahoo.com> Message-ID: <20050801165646.F30745@cactus.fi.uba.ar> References: <20050801172332.49832.qmail@web52109.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.51 on 157.92.49.108 Cc: freebsd hackers Subject: Re: How to protect an is-spam@xxx and no-spam@xxx alias? 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, 01 Aug 2005 20:00:14 -0000 On Mon, 1 Aug 2005, Patrick Dung wrote: > Hi > > I want user to forward spam mails to is-spam@mydomain.com and not spam > mails to non-spam@myhomdin.com. > > However, I don't want the people in the internet to send mail to these > to account. But the people in the internet can send mail to other user > in the system. > > Can this be done in Sendmail (and postfix and qmail)? Not a pure sendmail solution, but MIMEDefang can do it. I use it for malware blocking and spam filtering besides doing what you want to do. Fer > > Regards > Patrick > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 20:12:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A5F816A41F for ; Mon, 1 Aug 2005 20:12:30 +0000 (GMT) (envelope-from andy@triera.net) Received: from deliver-1.mx.triera.net (deliver-1.mx.triera.net [213.161.0.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 219D543D4C for ; Mon, 1 Aug 2005 20:12:29 +0000 (GMT) (envelope-from andy@triera.net) Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id D76A5BFDE for ; Mon, 1 Aug 2005 22:12:17 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 346FD1BC084 for ; Mon, 1 Aug 2005 22:12:16 +0200 (CEST) Received: from [192.168.44.2] (cpe1-5-51.cable.triera.net [213.161.5.51]) by smtp.triera.net (Postfix) with ESMTP id 8157F1A18AB for ; Mon, 1 Aug 2005 22:12:16 +0200 (CEST) From: "Aleksander (Andy) Rozman" To: freebsd-hackers@freebsd.org Date: Mon, 1 Aug 2005 22:10:15 +0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508012210.15653.andy@triera.net> X-Virus-Scanned: Triera AV Service Subject: Sound problem 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, 01 Aug 2005 20:12:30 -0000 Hi ! I am using FreeBSD 5.4. I have installed sound modules from kernel and everything work OK. But then I installed mplayer and when I play movie sound is weird. I know how actors should sound and they don't sound as they should. If I play same file under Win, then the sound is ok. Has anybody same problem, and where could problem lay? Andy From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 20:40:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEDF016A41F for ; Mon, 1 Aug 2005 20:40:39 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5140243D45 for ; Mon, 1 Aug 2005 20:40:39 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j71KeciD029412; Mon, 1 Aug 2005 13:40:38 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j71KecFX029411; Mon, 1 Aug 2005 13:40:38 -0700 (PDT) (envelope-from jmg) Date: Mon, 1 Aug 2005 13:40:38 -0700 From: John-Mark Gurney To: diz@linuxpowered.com Message-ID: <20050801204038.GW62369@funkthat.com> Mail-Followup-To: diz@linuxpowered.com, freebsd-hackers@freebsd.org References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 20:40:39 -0000 diz@linuxpowered.com wrote this message on Mon, Aug 01, 2005 at 12:29 -0500: > This has the result of reducing the size of the shell code, and reducing Unless you cross a fs frag (usually 1024 bytes), i.e. reduce the scripts by an average of 512bytes *per* script, you will see no disk space savings from these changes... considering that on my 5.4-R system over half (73 of 124) are under a frag in size, it isn't that much... One thing that would be really useful for rc.d system is a way to cache the ordering on boot... On a slow system like a 200mhz arm, the rc ordering can take a long while.... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 21:41:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF49216A41F for ; Mon, 1 Aug 2005 21:41:48 +0000 (GMT) (envelope-from andy@triera.net) Received: from deliver-1.mx.triera.net (deliver-1.mx.triera.net [213.161.0.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427EA43D45 for ; Mon, 1 Aug 2005 21:41:48 +0000 (GMT) (envelope-from andy@triera.net) Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 0B2CCC002; Mon, 1 Aug 2005 23:41:36 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 969211BC084; Mon, 1 Aug 2005 23:41:34 +0200 (CEST) Received: from [192.168.44.2] (cpe1-5-51.cable.triera.net [213.161.5.51]) by smtp.triera.net (Postfix) with ESMTP id BC44B1A18A5; Mon, 1 Aug 2005 23:41:34 +0200 (CEST) From: "Aleksander (Andy) Rozman" To: stsp@stsp.in-berlin.de Date: Mon, 1 Aug 2005 23:39:38 +0000 User-Agent: KMail/1.7 References: <200508012210.15653.andy@triera.net> <20050801202857.GA6944@stud> In-Reply-To: <20050801202857.GA6944@stud> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508012339.38682.andy@triera.net> X-Virus-Scanned: Triera AV Service Cc: freebsd-hackers@freebsd.org Subject: Re: Sound problem 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, 01 Aug 2005 21:41:48 -0000 On Monday 01 of August 2005 20:28, you wrote: > On Mon, Aug 01, 2005 at 10:10:15PM +0000, Aleksander (Andy) Rozman wrote: > > Hi ! > > > > I know how actors should sound and they don't sound as they should. > > Not that I'm perfect myself, but this would be a good read for you, too :) > > http://www.catb.org/~esr/faqs/smart-questions.html And your point was? OK maybe I could have written it better.... Here it is. Since I am no newbie this is the right place for me to post. This is too specific question to be posted on fbsd-question list, since the problem is somewhere in software. I tried several things so far and it seems that the problem lies with reproduction of sound. I tried mplayer, kplayer, xine, and I aslo tried playing mp3 files, and all change the sound they should have reporduced. I am no audio expert, but I think that pitch of sound is wrong. I have FreeBSD 5.4 installed, with KDE 3.3, and I have onboard sound card, which uses snd_ich driver. I am using the same driver at another computer, and it works ok there. Hope this info will give more clues. Andy From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 21:49:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0B8116A41F; Mon, 1 Aug 2005 21:49:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED9043D45; Mon, 1 Aug 2005 21:49:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 3438B4CE923; Mon, 1 Aug 2005 14:49:23 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30327-02; Mon, 1 Aug 2005 14:49:22 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 785594CE922; Mon, 1 Aug 2005 14:49:22 -0700 (PDT) Message-ID: <42EE98E2.7020102@elischer.org> Date: Mon, 01 Aug 2005 14:49:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: diz@linuxpowered.com References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> <20050801181014.GA14567@elvis.mu.org> <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> In-Reply-To: <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 21:49:24 -0000 diz@linuxpowered.com wrote: >>Giorgos Keramidas wrote: >> >> >>> [...] >>Thirded. I far prefer the bigger C-like if statements and think this >>patch is a huge code churn for what is basically code obfuscation. >> >>Cheers, >>Maxime >> >> > > >Well I certainly respect the opinions, but respectfully when has the use >of && and || become obfuscation? > > I work on alot of shell code and I prefer the "spelled out the long way" approach. i.e. I prefer if [blah] then if [blah2] then etc.... it's just easier to get it right in my opinion. remember, when the rare 100 sets of fingers in teh picture then you have to code toteh "bloody obvios" standard because sometimes people have to change scripts to handle some external change, and thay may or may not] be shell syntax experts. there si a lot that needs cleanup.. I thonk this is nto one of them.. I do apreciate however the thought and time you have spent. julian >-Jon > >_______________________________________________ >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 Mon Aug 1 22:02:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C5E416A41F for ; Mon, 1 Aug 2005 22:02:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C53843D46 for ; Mon, 1 Aug 2005 22:02:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 547FA4CE972; Mon, 1 Aug 2005 15:02:26 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31019-03; Mon, 1 Aug 2005 15:02:25 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id B73074CE969; Mon, 1 Aug 2005 15:02:25 -0700 (PDT) Message-ID: <42EE9BF1.70409@elischer.org> Date: Mon, 01 Aug 2005 15:02:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> <20050801181014.GA14567@elvis.mu.org> <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> <42EE98E2.7020102@elischer.org> In-Reply-To: <42EE98E2.7020102@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 01 Aug 2005 22:02:27 -0000 lets try that again without most of the typos. Julian Elischer wrote: > > > diz@linuxpowered.com wrote: > >>> Giorgos Keramidas wrote: >>> >>> >>>> > [...] > >>> Thirded. I far prefer the bigger C-like if statements and think this >>> patch is a huge code churn for what is basically code obfuscation. >>> >>> Cheers, >>> Maxime >>> >> >> >> >> Well I certainly respect the opinions, but respectfully when has the use >> of && and || become obfuscation? >> > > I work on a lot of shell code and I prefer the "spelled out the long > way" > approach. > > i.e. I prefer > > if [blah] > then > if [blah2] > then > etc.... > > It's just easier to get it right in my opinion. > Remember, when there are 100 sets of fingers in the picture then > you have to code to the "bloody obvious" standard because sometimes > people > have to change scripts to handle some external change, and thay may or > may not] > be shell syntax experts. > > > There is a lot that needs cleanup.. > I think this is not one of them.. > I do appreciate however the thought and time you have spent. > > > julian > >> -Jon >> >> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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 Tue Aug 2 00:54:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBB4D16A41F for ; Tue, 2 Aug 2005 00:54:09 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: from web52108.mail.yahoo.com (web52108.mail.yahoo.com [206.190.48.111]) by mx1.FreeBSD.org (Postfix) with SMTP id 682AE43D45 for ; Tue, 2 Aug 2005 00:54:09 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: (qmail 60827 invoked by uid 60001); 2 Aug 2005 00:54:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dsOhOXE/7k1FEjURN99YuRVGxEnIZlx5bJssu9rln7n+81DHhOlZcFZxeHyY0i3uv9s9uick+S+Hw5DLsy+oDLsvI6BZ2p+nPplUPj87G0ZqTjc/BDo+kwr3GbaeTAQBhDPelwTvxTcXoA0eApG7tsYT/pb06hUBn2vVwZcHhSA= ; Message-ID: <20050802005408.60825.qmail@web52108.mail.yahoo.com> Received: from [202.134.67.184] by web52108.mail.yahoo.com via HTTP; Mon, 01 Aug 2005 17:54:08 PDT Date: Mon, 1 Aug 2005 17:54:08 -0700 (PDT) From: Patrick Dung To: Claus Assmann In-Reply-To: <20050801182932.GA24057@zardoc.esmtp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd hackers Subject: Re: How to protect an is-spam@xxx and no-spam@xxx alias? 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, 02 Aug 2005 00:54:10 -0000 Thanks for help. I will try it. These two accounts will be used as input for the Baysien learning process. Regards Patrick --- Claus Assmann wrote: > On Mon, Aug 01, 2005, Patrick Dung wrote: > > > However, I don't want the people in the internet to send mail to > these > > to account. But the people in the internet can send mail to other > user > > in the system. > > > Can this be done in Sendmail (and postfix and qmail)? > > For sendmail 8: > http://www.sendmail.org/~ca/email/protected.html > > For sendmail X: > http://www.sendmail.org/~ca/email/sm-X/doc-X.0.0.Alpha9.0/README.html#SECTION004102000000000000000 > > _______________________________________________ > 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" > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 00:56:00 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B13916A41F for ; Tue, 2 Aug 2005 00:56:00 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: from web52114.mail.yahoo.com (web52114.mail.yahoo.com [206.190.48.117]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C9DF43D45 for ; Tue, 2 Aug 2005 00:55:59 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: (qmail 87228 invoked by uid 60001); 2 Aug 2005 00:55:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=395QWq5E50wHfo4QAMmY3reIGzQ32MeM5JwKawkIws/AFAQHVdFNsORRC2jFHsoNip+U2Bc9yGSbQpCejw5aLH9CX9fobLghChoNDnUwTtVHzWMRrhQuqO7ej14QLYbPDQaRRaXEzkaYJ9lOUwL8gA259LdYypKTfJKsjICuDM4= ; Message-ID: <20050802005559.87226.qmail@web52114.mail.yahoo.com> Received: from [202.134.67.184] by web52114.mail.yahoo.com via HTTP; Mon, 01 Aug 2005 17:55:58 PDT Date: Mon, 1 Aug 2005 17:55:58 -0700 (PDT) From: Patrick Dung To: Fernando Gleiser In-Reply-To: <20050801165646.F30745@cactus.fi.uba.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd hackers Subject: Re: How to protect an is-spam@xxx and no-spam@xxx alias? 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, 02 Aug 2005 00:56:00 -0000 Hi dspam also state that it can also do this (for the anti-spam learning process) Regards Patrick --- Fernando Gleiser wrote: > On Mon, 1 Aug 2005, Patrick Dung wrote: > > > Hi > > > > I want user to forward spam mails to is-spam@mydomain.com and not > spam > > mails to non-spam@myhomdin.com. > > > > However, I don't want the people in the internet to send mail to > these > > to account. But the people in the internet can send mail to other > user > > in the system. > > > > Can this be done in Sendmail (and postfix and qmail)? > > Not a pure sendmail solution, but MIMEDefang can do it. I use it for > malware blocking and spam filtering besides doing what you want to > do. > > > Fer > > > > > > > Regards > > Patrick > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > 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" > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 01:35:32 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C0A816A41F; Tue, 2 Aug 2005 01:35:32 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2036243D48; Tue, 2 Aug 2005 01:35:31 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j721ZVYk035932; Mon, 1 Aug 2005 18:35:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j721ZVpf035931; Mon, 1 Aug 2005 18:35:31 -0700 (PDT) (envelope-from dillon) Date: Mon, 1 Aug 2005 18:35:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200508020135.j721ZVpf035931@apollo.backplane.com> To: Igor Shmukler References: <6533c1c9050721121030016b7d@mail.gmail.com> <200507211926.j6LJQ55D071115@apollo.backplane.com> <6533c1c905080111026f1f07ca@mail.gmail.com> Cc: hackers@freebsd.org, fs@freebsd.org Subject: Re: per file lock list 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, 02 Aug 2005 01:35:32 -0000 : :Matt, : :Thank you very much for response. This is a general solution, but it :not sufficient for our needs. I guess I should have been more clear :while explaining what we need. : :We want list of these locks for a group of processes. : :We made an implementation based on your suggestion, but there is one problem... : :Unfortunately this method does not return all shared locks for a :range. For example, if several processes have placed a shared lock on :a :range [1000 - 2000], F_GETLK returns a flock structure where l_pid field :contains a pid of process that takes the lock first. While, we want :to know all processes that takes this lock. Is there any way to retrieve :such information without using of internal kernel structures (inode :information)? : :Thank you in advance, : :igor I'm pretty sure there is no way to get a list of all shared users of a particular lock range short of going through kmem. You would need to program a new fcntl feature to get access to all the related locks. If you need the information just for debugging purposes then scanning the list via kmem might suffice, but it obviously isn't the best solution due to races. What I would recommend is that you create a new fcntl, say call it F_GETLKM, and hand it an extended flock structure which contains additional information...an index and a chaining field that the kernel can use to safely sequence through all related locks. That would allow the kernel to detect races with other processes changing the locking state at the same time. -Matt From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 02:22:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D293816A41F; Tue, 2 Aug 2005 02:22:51 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from ws2.infoweapons.com (ws2.infoweapons.com [203.177.161.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25EA443D45; Tue, 2 Aug 2005 02:22:50 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from [10.3.1.41] ([10.3.1.41]) by ws2.infoweapons.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 10:22:10 +0800 Message-ID: <42EEDABE.7080402@infoweapons.com> Date: Tue, 02 Aug 2005 10:30:22 +0800 From: "Ronnel P. Maglasang" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <42E9BC12.2050401@infoweapons.com> <20050729065357.GA617@darkness.comp.waw.pl> <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net> In-Reply-To: <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2005 02:22:10.0265 (UTC) FILETIME=[FC8E6490:01C59708] Cc: freebsd-hackers , Pawel Jakub Dawidek , freebsd-geom Subject: Re: booting gbde-encrypted filesystem 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, 02 Aug 2005 02:22:52 -0000 What I had in mind is perhaps I could find a way to enter the passphrase at the loader prompt, or configure the loader to get the passphrase from an external device or hardcoded the passphrase in the bootloader(really insecure). Alexander Leidinger wrote: > Pawel Jakub Dawidek wrote: > >> This is not not possible with current GBDE. >> I've patches which allows this here: >> >> http://people.freebsd.org/~pjd/patches/gbde.patch > > > I fail to see how this allows an encryted root-FS, it doesn't add gbde > support to boot0(ext) or to the loader. It needs access to an unencrypted > kernel. I don't think this is what Ronnel had in mind (overlooking the > fact > that his suggestion to save the passphrase in the loader is insecure). > > Bye, > Alexander. > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 02:49:21 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 224CE16A41F for ; Tue, 2 Aug 2005 02:49:21 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD71043D46 for ; Tue, 2 Aug 2005 02:49:18 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 2F28226427B; Mon, 1 Aug 2005 21:47:58 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29151-09; Mon, 1 Aug 2005 21:47:54 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id 8695A264053; Mon, 1 Aug 2005 21:47:54 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 21:47:54 -0500 (CDT) Message-ID: <53362.68.95.232.238.1122950874.squirrel@68.95.232.238> In-Reply-To: <20050801204038.GW62369@funkthat.com> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <20050801204038.GW62369@funkthat.com> Date: Mon, 1 Aug 2005 21:47:54 -0500 (CDT) From: diz@linuxpowered.com To: "John-Mark Gurney" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 02 Aug 2005 02:49:21 -0000 > diz@linuxpowered.com wrote this message on Mon, Aug 01, 2005 at 12:29 > -0500: >> This has the result of reducing the size of the shell code, and reducing > > Unless you cross a fs frag (usually 1024 bytes), i.e. reduce the scripts > by an average of 512bytes *per* script, you will see no disk space savings > from these changes... considering that on my 5.4-R system over half > (73 of 124) are under a frag in size, it isn't that much... > > One thing that would be really useful for rc.d system is a way to cache > the ordering on boot... On a slow system like a 200mhz arm, the rc > ordering can take a long while.... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > Ok thanks for the dirrection. Ask and thy shall receive. well a quick hack at least to implement cache of rcorder, although from my tests even on old hardware rcorder is quick. I wrote this in (cring) the long-spelled out way. Anyways... don't forget to add the essential rc.conf knobs for the two variables shown bellow. [root@:/etc]# diff -u rc rc.new --- rc Sun Jul 31 17:45:19 2005 +++ rc.new Mon Aug 1 21:42:12 2005 @@ -72,7 +72,17 @@ skip="-s nostart" [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ] && skip="$skip -s nojail" -files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` +# check for a rc.conf knob to check for existing cache, and skip the rcorder part +if checkyesno ${rc_cache_enable} ; then + if [ -f ${rc_cache_file} ] ; then + files=`cat ${rc_cache_file}` + else + files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` + echo "${files}" > ${rc_cache_file} + fi +else + files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` +fi for _rc_elem in ${files}; do run_rc_script ${_rc_elem} ${_boot} From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 02:54:07 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 542F616A41F; Tue, 2 Aug 2005 02:54:07 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D4B43D46; Tue, 2 Aug 2005 02:54:06 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id D7E5426427B; Mon, 1 Aug 2005 21:52:46 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30170-03; Mon, 1 Aug 2005 21:52:44 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id 5333D264053; Mon, 1 Aug 2005 21:52:44 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 21:52:44 -0500 (CDT) Message-ID: <55770.68.95.232.238.1122951164.squirrel@68.95.232.238> In-Reply-To: <42EE98E2.7020102@elischer.org> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> <20050801181014.GA14567@elvis.mu.org> <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> <42EE98E2.7020102@elischer.org> Date: Mon, 1 Aug 2005 21:52:44 -0500 (CDT) From: diz@linuxpowered.com To: "Julian Elischer" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup 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, 02 Aug 2005 02:54:07 -0000 > > > diz@linuxpowered.com wrote: > >>>Giorgos Keramidas wrote: >>> >>> >>>> > [...] > >>>Thirded. I far prefer the bigger C-like if statements and think this >>>patch is a huge code churn for what is basically code obfuscation. >>> >>>Cheers, >>>Maxime >>> >>> >> >> >>Well I certainly respect the opinions, but respectfully when has the use >>of && and || become obfuscation? >> >> > > I work on alot of shell code and I prefer the "spelled out the long way" > approach. > > i.e. I prefer > > if [blah] > then > if [blah2] > then > etc.... > > it's just easier to get it right in my opinion. > remember, when the rare 100 sets of fingers in teh picture then > you have to code toteh "bloody obvios" standard because sometimes people > have to change scripts to handle some external change, and thay may or > may not] > be shell syntax experts. > > > there si a lot that needs cleanup.. Like what? I'm receptive to any suggestions for area's of shell code that need attention. > I thonk this is nto one of them.. > I do apreciate however the thought and time you have spent. Thanks, but actually I was just bored durring a long portupgrade. Next time I won't bother with such "code-chuning" muse of boredom, but like I said, I'm eager to participate somehow, so perhaps next time I will send up much smaller more digestable enhancements. =) > > > julian > >>-Jon >> >>_______________________________________________ >>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 Tue Aug 2 03:03:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3746616A420 for ; Tue, 2 Aug 2005 03:03:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6628C43D4C for ; Tue, 2 Aug 2005 03:03:42 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7233dKr004575; Mon, 1 Aug 2005 20:03:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7233dbG004574; Mon, 1 Aug 2005 20:03:39 -0700 Date: Mon, 1 Aug 2005 20:03:39 -0700 From: Brooks Davis To: diz@linuxpowered.com Message-ID: <20050802030339.GA3993@odin.ac.hmc.edu> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <20050801204038.GW62369@funkthat.com> <53362.68.95.232.238.1122950874.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <53362.68.95.232.238.1122950874.squirrel@68.95.232.238> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-hackers@freebsd.org, John-Mark Gurney Subject: Re: [patch] rc.d cleanup 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, 02 Aug 2005 03:03:43 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 09:47:54PM -0500, diz@linuxpowered.com wrote: > > diz@linuxpowered.com wrote this message on Mon, Aug 01, 2005 at 12:29 > > -0500: > >> This has the result of reducing the size of the shell code, and reduci= ng > > > > Unless you cross a fs frag (usually 1024 bytes), i.e. reduce the scripts > > by an average of 512bytes *per* script, you will see no disk space savi= ngs > > from these changes... considering that on my 5.4-R system over half > > (73 of 124) are under a frag in size, it isn't that much... > > > > One thing that would be really useful for rc.d system is a way to cache > > the ordering on boot... On a slow system like a 200mhz arm, the rc > > ordering can take a long while.... > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > >=20 >=20 > Ok thanks for the dirrection. Ask and thy shall receive. well a quick hack > at least to implement cache of rcorder, although from my tests even on old > hardware rcorder is quick. I wrote this in (cring) the long-spelled out > way. Anyways... don't forget to add the essential rc.conf knobs for the > two variables shown bellow. >=20 > [root@:/etc]# diff -u rc rc.new > --- rc Sun Jul 31 17:45:19 2005 > +++ rc.new Mon Aug 1 21:42:12 2005 > @@ -72,7 +72,17 @@ >=20 > skip=3D"-s nostart" > [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ] && skip=3D"$skip -s noj= ail" > -files=3D`rcorder ${skip} /etc/rc.d/* 2>/dev/null` > +# check for a rc.conf knob to check for existing cache, and skip the > rcorder part > +if checkyesno ${rc_cache_enable} ; then > + if [ -f ${rc_cache_file} ] ; then > + files=3D`cat ${rc_cache_file}` > + else > + files=3D`rcorder ${skip} /etc/rc.d/* 2>/dev/null` > + echo "${files}" > ${rc_cache_file} > + fi > +else > + files=3D`rcorder ${skip} /etc/rc.d/* 2>/dev/null` > +fi >=20 > for _rc_elem in ${files}; do > run_rc_script ${_rc_elem} ${_boot} I'm pretty sure you don't have access to the contents of /etc/rc.conf in this context. You would have to use another mechanism to control this feature. I'd be tempted to use the existance of a cache file (probably /etc/rcorder.cache since it can't be outside /) and simply require users to regenerate it externally when they upgrade (I'd probably add code to mergemaster to handle it like the various database files). Note that we may well break the ability to do this is easily in 7.0 if we end up supporting ordering of local scripts. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC7uKKXY6L6fI4GtQRAi93AJ9g+Tookdh2yU9cKaBzvzuL7bCz3wCfb35n 3nmCh7TW4ZhS8cMvG46CZXA= =AHsp -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 04:16:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 343A816A41F for ; Tue, 2 Aug 2005 04:16:31 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id B20EA43D45 for ; Tue, 2 Aug 2005 04:16:28 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id B531B26427B; Mon, 1 Aug 2005 23:15:07 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02785-09; Mon, 1 Aug 2005 23:15:04 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id D72FD264053; Mon, 1 Aug 2005 23:15:03 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 23:15:03 -0500 (CDT) Message-ID: <52134.68.95.232.238.1122956103.squirrel@68.95.232.238> In-Reply-To: <20050802030339.GA3993@odin.ac.hmc.edu> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <20050801204038.GW62369@funkthat.com> <53362.68.95.232.238.1122950874.squirrel@68.95.232.238> <20050802030339.GA3993@odin.ac.hmc.edu> Date: Mon, 1 Aug 2005 23:15:03 -0500 (CDT) From: diz@linuxpowered.com To: "Brooks Davis" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org, John-Mark Gurney Subject: rcorder cache (was [patch] rc.d cleanup) 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, 02 Aug 2005 04:16:31 -0000 > On Mon, Aug 01, 2005 at 09:47:54PM -0500, diz@linuxpowered.com wrote: >> > diz@linuxpowered.com wrote this message on Mon, Aug 01, 2005 at 12:29 >> > -0500: >> >> This has the result of reducing the size of the shell code, and >> reducing >> > >> > Unless you cross a fs frag (usually 1024 bytes), i.e. reduce the >> scripts >> > by an average of 512bytes *per* script, you will see no disk space >> savings >> > from these changes... considering that on my 5.4-R system over half >> > (73 of 124) are under a frag in size, it isn't that much... >> > >> > One thing that would be really useful for rc.d system is a way to >> cache >> > the ordering on boot... On a slow system like a 200mhz arm, the rc >> > ordering can take a long while.... >> > >> > -- >> > John-Mark Gurney Voice: +1 415 225 5579 >> > >> > "All that I will do, has been done, All that I have, has not." >> > >> >> >> Ok thanks for the dirrection. Ask and thy shall receive. well a quick >> hack >> at least to implement cache of rcorder, although from my tests even on >> old >> hardware rcorder is quick. I wrote this in (cring) the long-spelled out >> way. Anyways... don't forget to add the essential rc.conf knobs for the >> two variables shown bellow. >> >> [root@:/etc]# diff -u rc rc.new >> --- rc Sun Jul 31 17:45:19 2005 >> +++ rc.new Mon Aug 1 21:42:12 2005 >> @@ -72,7 +72,17 @@ >> >> skip="-s nostart" >> [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ] && skip="$skip -s >> nojail" >> -files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` >> +# check for a rc.conf knob to check for existing cache, and skip the >> rcorder part >> +if checkyesno ${rc_cache_enable} ; then >> + if [ -f ${rc_cache_file} ] ; then >> + files=`cat ${rc_cache_file}` >> + else >> + files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` >> + echo "${files}" > ${rc_cache_file} >> + fi >> +else >> + files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` >> +fi >> >> for _rc_elem in ${files}; do >> run_rc_script ${_rc_elem} ${_boot} > > I'm pretty sure you don't have access to the contents of /etc/rc.conf in > this context. You would have to use another mechanism to control this > feature. I'd be tempted to use the existance of a cache file (probably > /etc/rcorder.cache since it can't be outside /) and simply require users > to regenerate it externally when they upgrade (I'd probably add code to > mergemaster to handle it like the various database files). Note that we > may well break the ability to do this is easily in 7.0 if we end up > supporting ordering of local scripts. Would it be possible or in anyway not unreasonable to source rc.conf in this file? Honestly I was working under the presumption that anytime rc.subr was sourced that the knobs file was too, but possibly my bad. Not that it matters, I can think of ways to work arround this, but I would want to have a rc.d script later on to control the presence of the rcorder cache file for the next boot, or something. I'd hate to use the existence of files to control the functionality, where rc.conf knobs are ideal. -Jon > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 04:38:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E31B16A41F for ; Tue, 2 Aug 2005 04:38:27 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A5CD43D48 for ; Tue, 2 Aug 2005 04:38:27 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 4B45F26427B for ; Mon, 1 Aug 2005 23:37:06 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05179-02 for ; Mon, 1 Aug 2005 23:37:05 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id 039B6264053 for ; Mon, 1 Aug 2005 23:37:05 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 23:37:05 -0500 (CDT) Message-ID: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> Date: Mon, 1 Aug 2005 23:37:05 -0500 (CDT) From: diz@linuxpowered.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Subject: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 04:38:27 -0000 Howdy hackers, I'm sorry for the previous patch, so here is at least one item that really bugs me that isn't obfuscation. In short, I don't see any reason to fork some process to simply "touch" a file (is a filesystem writable) when built-in shell i/o does this: --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 @@ -48,8 +48,8 @@ [Nn][Oo]) ;; *) - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then - rmdir /tmp/.diskless + if ( > /tmp/.diskless 2> /dev/null); then + rm /tmp/.diskless else if [ -h /tmp ]; then echo "*** /tmp is a symlink to a non-writable area!" I grep'ed the entire rc.d dir, and found that the same technique is used elsewhere in accounting, and cleanvar. So I feel justified this time, although please review, and thanks for the look. While I understand the need to want a fork program to touch, or otherwise create an inode, I feel forking for such an effort is weird and a bit over-engineered. -Jon From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 05:23:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D8CB16A41F for ; Tue, 2 Aug 2005 05:23:42 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE7143D45 for ; Tue, 2 Aug 2005 05:23:41 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j725NdlZ068360; Mon, 1 Aug 2005 22:23:39 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j725NdWD024603; Mon, 1 Aug 2005 22:23:39 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j725Ncki024542; Mon, 1 Aug 2005 22:23:38 -0700 (PDT) (envelope-from frank) Date: Mon, 1 Aug 2005 22:23:38 -0700 From: Frank Mayhar To: diz@linuxpowered.com Message-Id: <20050801222338.5d666438.frank@exit.com> In-Reply-To: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> Organization: Exit Consulting X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1000/Sun Jul 31 12:28:06 2005 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 05:23:42 -0000 On Mon, 1 Aug 2005 23:37:05 -0500 (CDT) diz@linuxpowered.com wrote: > I grep'ed the entire rc.d dir, and found that the same technique is used > elsewhere in accounting, and cleanvar. So I feel justified this time, > although please review, and thanks for the look. While I understand the > need to want a fork program to touch, or otherwise create an inode, I feel > forking for such an effort is weird and a bit over-engineered. Well, while one prefers a system to boot as quickly as reasonably possible, it's not like startup is particularly performance-critical. This is another place where I feel that clarity more than compensates for (very minor) slowness, particularly when coupled with the fact that the cost of a fork()/exec() is overwhelmed by the cost of cranking up some of the heavy-weight daemons. It seems to me that you're looking at things from a very "hacky" perspective. That is, it seems that you know a lot of shortcuts that add a bit of speed here and there and that's what you're trying to apply. (Please correct me if I'm wrong.) I would suggest that you look at the startup scripts somewhat differently, by asking yourself what is _broken_ there. I've seen at least a couple of suggestions along this line in reply to you. The mkdir usage isn't really broken, it seems to me. While I'm by no stretch of the imagination an expert regarding the rc scripts (they work and I ignore them), there are others around here that are, and they can, I am certain, give you some relevant, useful and very challenging suggestions. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 05:58:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF34C16A41F for ; Tue, 2 Aug 2005 05:58:05 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5252243D45 for ; Tue, 2 Aug 2005 05:58:05 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 8FC5926427B; Tue, 2 Aug 2005 00:56:43 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10371-07; Tue, 2 Aug 2005 00:56:33 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id 08983264053; Tue, 2 Aug 2005 00:56:33 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Tue, 2 Aug 2005 00:56:33 -0500 (CDT) Message-ID: <1107.68.95.232.238.1122962193.squirrel@68.95.232.238> In-Reply-To: <20050801222338.5d666438.frank@exit.com> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050801222338.5d666438.frank@exit.com> Date: Tue, 2 Aug 2005 00:56:33 -0500 (CDT) From: diz@linuxpowered.com To: "Frank Mayhar" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 05:58:05 -0000 All the while I point to code example of this exact same usage being deployed in the system already, and in the same exact situation. I see no reason why you must bikeshed on this. Correctness is always correct, despite established bad'ism, and in this case I am carefull to use an already approved shell code commit even if that is bad, it is approved bad or at least commited previously. -Jon > On Mon, 1 Aug 2005 23:37:05 -0500 (CDT) > diz@linuxpowered.com wrote: >> I grep'ed the entire rc.d dir, and found that the same technique is used >> elsewhere in accounting, and cleanvar. So I feel justified this time, >> although please review, and thanks for the look. While I understand the >> need to want a fork program to touch, or otherwise create an inode, I >> feel >> forking for such an effort is weird and a bit over-engineered. > > Well, while one prefers a system to boot as quickly as reasonably > possible, > it's not like startup is particularly performance-critical. This is > another > place where I feel that clarity more than compensates for (very minor) > slowness, > particularly when coupled with the fact that the cost of a fork()/exec() > is > overwhelmed by the cost of cranking up some of the heavy-weight daemons. > > It seems to me that you're looking at things from a very "hacky" > perspective. > That is, it seems that you know a lot of shortcuts that add a bit of speed > here and there and that's what you're trying to apply. (Please correct me > if I'm wrong.) I would suggest that you look at the startup scripts > somewhat > differently, by asking yourself what is _broken_ there. I've seen at > least a > couple of suggestions along this line in reply to you. The mkdir usage > isn't > really broken, it seems to me. While I'm by no stretch of the imagination > an > expert regarding the rc scripts (they work and I ignore them), there are > others > around here that are, and they can, I am certain, give you some relevant, > useful and very challenging suggestions. > -- > Frank Mayhar frank@exit.com http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 06:11:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7895C16A41F for ; Tue, 2 Aug 2005 06:11:12 +0000 (GMT) (envelope-from karel@inetis.com) Received: from inetis.com (cpe-212-18-40-64.adsl.amis.net [212.18.40.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99FE543D45 for ; Tue, 2 Aug 2005 06:11:11 +0000 (GMT) (envelope-from karel@inetis.com) Received: from [192.168.0.14] ([192.168.0.14]) by inetis.com with MailEnable ESMTP; Tue, 02 Aug 2005 08:10:35 +0200 Message-ID: <42EF0E5C.9080802@inetis.com> Date: Tue, 02 Aug 2005 08:10:36 +0200 From: Karel Miklav User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> In-Reply-To: <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD desktop? 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, 02 Aug 2005 06:11:12 -0000 ray@redshift.com wrote: > Okay, good to hear. I love FreeBSD - I dumped Linux redhat a couple > of years ago and moved all of our servers over to FreeBSD and just > love it. I really want to be able to make FreeBSD my desktop and it > seems like i should be able to get it up and running and configured > like SUSE or Redhat or Xandros or something along those lines with a > little work. I was switching to FreeBSD for five years. First my web server, then notebook and finally home computer. It was obviously not easy, but the desire to live in a consistent world drove me. And what can I say now: well, my wife and kids don't complain, I only need to learn one platform and being up-to-date is easy. What a tremendous relief! Some hints: gnome, mozila, openoffice, wmi, xterm, qemu, mplayer... -- Regards, Karel Miklav From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 06:13:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB51916A41F for ; Tue, 2 Aug 2005 06:13:08 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 630CF43D45 for ; Tue, 2 Aug 2005 06:13:08 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 1AD5397871; Mon, 1 Aug 2005 23:13:08 -0700 (PDT) Message-Id: <3.0.1.32.20050801231310.00a5f7e8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Mon, 01 Aug 2005 23:13:10 -0700 To: Karel Miklav From: ray@redshift.com In-Reply-To: <42EF0E5C.9080802@inetis.com> References: <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD desktop? 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, 02 Aug 2005 06:13:08 -0000 At 08:10 AM 8/2/2005 +0200, Karel Miklav wrote: | ray@redshift.com wrote: | > Okay, good to hear. I love FreeBSD - I dumped Linux redhat a couple | > of years ago and moved all of our servers over to FreeBSD and just | > love it. I really want to be able to make FreeBSD my desktop and it | > seems like i should be able to get it up and running and configured | > like SUSE or Redhat or Xandros or something along those lines with a | > little work. | | I was switching to FreeBSD for five years. First my web server, then | notebook and finally home computer. It was obviously not easy, but the | desire to live in a consistent world drove me. And what can I say now: | well, my wife and kids don't complain, I only need to learn one | platform and being up-to-date is easy. What a tremendous relief! | | Some hints: gnome, mozila, openoffice, wmi, xterm, qemu, mplayer... Thanks Karel. I got my FreeBSD desktop up and running. It's on X window and gnome. I am not sure about setting up the window manager, but may try that later. I did re-compile the kernel for SMP and strip it down a bit. I also compiled/installed GAIM, gimp, putty and firefox from ports. Ray From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 06:19:56 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5D1916A41F for ; Tue, 2 Aug 2005 06:19:56 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BBED43D45 for ; Tue, 2 Aug 2005 06:19:54 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id 3E9141B8762; Tue, 2 Aug 2005 15:19:53 +0900 (JST) Date: Tue, 2 Aug 2005 15:19:53 +0900 From: YONETANI Tomokazu To: diz@linuxpowered.com Message-ID: <20050802061953.GA964@les.ath.cx> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 06:19:56 -0000 On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote: > I'm sorry for the previous patch, so here is at least one item that really > bugs me that isn't obfuscation. In short, I don't see any reason to fork > some process to simply "touch" a file (is a filesystem writable) when > built-in shell i/o does this: > > --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > @@ -48,8 +48,8 @@ > [Nn][Oo]) > ;; > *) > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > - rmdir /tmp/.diskless > + if ( > /tmp/.diskless 2> /dev/null); then > + rm /tmp/.diskless > else > if [ -h /tmp ]; then > echo "*** /tmp is a symlink to a non-writable area!" > Try this as a non-root user, reboot the system and see what happens: $ ln -s /bin/rm /tmp/.diskless From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 06:29:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C0416A41F for ; Tue, 2 Aug 2005 06:29:39 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D78C43D45 for ; Tue, 2 Aug 2005 06:29:39 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from sinanica.bg.datamax (sinanica.bg.datamax [192.168.10.1]) by jengal.datamax.bg (Postfix) with QMQP id 7ACB987C8; Tue, 2 Aug 2005 09:29:37 +0300 (EEST) Received: (nullmailer pid 31765 invoked by uid 1004); Tue, 02 Aug 2005 06:29:37 -0000 Date: Tue, 2 Aug 2005 09:29:37 +0300 From: Vasil Dimov To: diz@linuxpowered.com Message-ID: <20050802062937.GA31485@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 06:29:39 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote: > Howdy hackers, >=20 > I'm sorry for the previous patch, so here is at least one item that really > bugs me that isn't obfuscation. In short, I don't see any reason to fork > some process to simply "touch" a file (is a filesystem writable) when > built-in shell i/o does this: >=20 > --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > @@ -48,8 +48,8 @@ > [Nn][Oo]) > ;; > *) > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > - rmdir /tmp/.diskless > + if ( > /tmp/.diskless 2> /dev/null); then > + rm /tmp/.diskless > else > if [ -h /tmp ]; then > echo "*** /tmp is a symlink to a non-writable are= a!" >=20 The thing you suggest is bloody insecure. Just imagine some baduser doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. I guess this is the reason why directory creation is used instead of file creation. I just wonder why a new shell is forked for this test. Simply if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same thing without forking a new shell that only executes /bin/mkdir Even we can use if [ -d /tmp -a -w /tmp ] ; then or (which is equivalent) if [ -d /tmp ] && [ -w /tmp ] ; then and save external commands (mkdir) execution and directory creation/deletion at all. --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFC7xLOFw6SP/bBpCARAj/dAKCkPbJaiFeHFa3qHSI3W5TLGQOgLQCfdyZk EMb0e+KatXqniG+YgRuNBlw= =y44W -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 09:34:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A44616A41F for ; Tue, 2 Aug 2005 09:34:02 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB4A43D58 for ; Tue, 2 Aug 2005 09:34:00 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j729Xnks029370; Tue, 2 Aug 2005 12:33:49 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j729XnLN001628; Tue, 2 Aug 2005 12:33:49 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j729XmQw001627; Tue, 2 Aug 2005 12:33:48 +0300 (EEST) Date: Tue, 2 Aug 2005 12:33:48 +0300 From: Giorgos Keramidas To: Vasil Dimov Message-ID: <20050802093348.GC1307@beatrix.daedalusnetworks.priv> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802062937.GA31485@sinanica.bg.datamax> Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 09:34:02 -0000 On 2005-08-02 09:29, Vasil Dimov wrote: > > --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > > +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > > @@ -48,8 +48,8 @@ > > [Nn][Oo]) > > ;; > > *) > > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > > - rmdir /tmp/.diskless > > + if ( > /tmp/.diskless 2> /dev/null); then > > + rm /tmp/.diskless > > else > > if [ -h /tmp ]; then > > echo "*** /tmp is a symlink to a non-writable area!" > > The thing you suggest is bloody insecure. Just imagine some baduser > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > I guess this is the reason why directory creation is used instead of > file creation. > > I just wonder why a new shell is forked for this test. Simply if > /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same > thing without forking a new shell that only executes /bin/mkdir I think it's because the current shell is allowed to exit if a command fails while a conditional test like this is run: if mkdir /tmp/foo; then echo foo rmdir /tmp/foo fi and mkdir may fail. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 10:53:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D78916A41F for ; Tue, 2 Aug 2005 10:53:47 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07DC643D45 for ; Tue, 2 Aug 2005 10:53:46 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.0.2] (host46-147.pool8254.interbusiness.it [82.54.147.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id D6A7B57EC; Tue, 2 Aug 2005 12:54:02 +0200 (CEST) Message-ID: <42EF5072.30808@freesbie.org> Date: Tue, 02 Aug 2005 12:52:34 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: vd@datamax.bg References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> In-Reply-To: <20050802062937.GA31485@sinanica.bg.datamax> X-Enigmail-Version: 0.92.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D0996A22CE2F08BE9C123A5" Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 10:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D0996A22CE2F08BE9C123A5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Vasil Dimov wrote: > Even we can use > if [ -d /tmp -a -w /tmp ] ; then > or (which is equivalent) > if [ -d /tmp ] && [ -w /tmp ] ; then > and save external commands (mkdir) execution and directory > creation/deletion at all. You can't use test -w here. The script is checking if there is a read-only filesystem. -w checks only the file flags (according to the man page, at least). -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enig4D0996A22CE2F08BE9C123A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC71B4ymi72IiShysRAn21AKCZupF+JelDzaw8/U9lIcPDwZCUswCeIKZ/ B+ws2afu3CEedeACtqwDuEw= =mY5R -----END PGP SIGNATURE----- --------------enig4D0996A22CE2F08BE9C123A5-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 11:05:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2454416A41F for ; Tue, 2 Aug 2005 11:05:24 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F0C543D45 for ; Tue, 2 Aug 2005 11:05:23 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from sinanica.bg.datamax (sinanica.bg.datamax [192.168.10.1]) by jengal.datamax.bg (Postfix) with QMQP id AC4E387C8; Tue, 2 Aug 2005 14:05:22 +0300 (EEST) Received: (nullmailer pid 86023 invoked by uid 1004); Tue, 02 Aug 2005 11:05:22 -0000 Date: Tue, 2 Aug 2005 14:05:22 +0300 From: Vasil Dimov To: Giorgos Keramidas Message-ID: <20050802110522.GA85997@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <20050802093348.GC1307@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20050802093348.GC1307@beatrix.daedalusnetworks.priv> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 11:05:24 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 12:33:48PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 09:29, Vasil Dimov wrote: > > > --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > > > +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > > > @@ -48,8 +48,8 @@ > > > [Nn][Oo]) > > > ;; > > > *) > > > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > > > - rmdir /tmp/.diskless > > > + if ( > /tmp/.diskless 2> /dev/null); then > > > + rm /tmp/.diskless > > > else > > > if [ -h /tmp ]; then > > > echo "*** /tmp is a symlink to a non-writable= area!" > > > > The thing you suggest is bloody insecure. Just imagine some baduser > > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > > I guess this is the reason why directory creation is used instead of > > file creation. > > > > I just wonder why a new shell is forked for this test. Simply if > > /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same > > thing without forking a new shell that only executes /bin/mkdir >=20 > I think it's because the current shell is allowed to exit if a command > fails while a conditional test like this is run: >=20 > if mkdir /tmp/foo; then > echo foo > rmdir /tmp/foo > fi >=20 > and mkdir may fail. >=20 What do you mean by "allowed to exit"? sh -e? --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFC71NxFw6SP/bBpCARAnu1AJ9VR25ubG5/z1gtBifI5zxLYNkLqACguhpb 9xubc+kaOFADWqquDq5DUUg= =0Uef -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 11:06:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 245AC16A41F for ; Tue, 2 Aug 2005 11:06:34 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87F1A43D49 for ; Tue, 2 Aug 2005 11:06:33 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from sinanica.bg.datamax (sinanica.bg.datamax [192.168.10.1]) by jengal.datamax.bg (Postfix) with QMQP id D7EDC87C8; Tue, 2 Aug 2005 14:06:32 +0300 (EEST) Received: (nullmailer pid 86039 invoked by uid 1004); Tue, 02 Aug 2005 11:06:32 -0000 Date: Tue, 2 Aug 2005 14:06:32 +0300 From: Vasil Dimov To: Dario Freni Message-ID: <20050802110632.GB85997@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <42EF5072.30808@freesbie.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <42EF5072.30808@freesbie.org> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 11:06:34 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > Vasil Dimov wrote: > > Even we can use > > if [ -d /tmp -a -w /tmp ] ; then > > or (which is equivalent) > > if [ -d /tmp ] && [ -w /tmp ] ; then > > and save external commands (mkdir) execution and directory > > creation/deletion at all. >=20 > You can't use test -w here. The script is checking if there is a > read-only filesystem. -w checks only the file flags (according to the > man page, at least). >=20 That's correct, -w cannot be used to check read-only filesystem. --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFC71O2Fw6SP/bBpCARAmMsAKCWFSotlWmFAkqVHEnpmNc2B7L0NwCg3MhS Lxa/W9wvbHrATsKBceCQ67Q= =zFSX -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 11:17:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03EA716A41F for ; Tue, 2 Aug 2005 11:17:47 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A60343D46 for ; Tue, 2 Aug 2005 11:17:46 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 861EF35707 for ; Tue, 2 Aug 2005 13:17:44 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id EEB9A5406; Tue, 2 Aug 2005 13:15:35 +0200 (CEST) Date: Tue, 2 Aug 2005 13:15:35 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050802111535.GA2468@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <42EF5072.30808@freesbie.org> <20050802110632.GB85997@sinanica.bg.datamax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802110632.GB85997@sinanica.bg.datamax> User-Agent: Mutt/1.5.6i Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 11:17:47 -0000 On Tue, Aug 02, 2005 at 02:06:32PM +0300, Vasil Dimov wrote: > On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > > Vasil Dimov wrote: > > > Even we can use > > > if [ -d /tmp -a -w /tmp ] ; then > > > or (which is equivalent) > > > if [ -d /tmp ] && [ -w /tmp ] ; then > > > and save external commands (mkdir) execution and directory > > > creation/deletion at all. > > > > You can't use test -w here. The script is checking if there is a > > read-only filesystem. -w checks only the file flags (according to the > > man page, at least). > > > That's correct, -w cannot be used to check read-only filesystem. Actually, you can. That's not portable behaviour though. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 11:38:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C687B16A420 for ; Tue, 2 Aug 2005 11:38:52 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F21343D4C for ; Tue, 2 Aug 2005 11:38:46 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j72BcbLa025380; Tue, 2 Aug 2005 14:38:37 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j72BcbkW002088; Tue, 2 Aug 2005 14:38:37 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j72Bcaiw002087; Tue, 2 Aug 2005 14:38:36 +0300 (EEST) Date: Tue, 2 Aug 2005 14:38:36 +0300 From: Giorgos Keramidas To: Vasil Dimov Message-ID: <20050802113836.GA2077@beatrix.daedalusnetworks.priv> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <20050802093348.GC1307@beatrix.daedalusnetworks.priv> <20050802110522.GA85997@sinanica.bg.datamax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802110522.GA85997@sinanica.bg.datamax> Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 11:38:52 -0000 On 2005-08-02 14:05, Vasil Dimov wrote: >On Tue, Aug 02, 2005 at 12:33:48PM +0300, Giorgos Keramidas wrote: >>On 2005-08-02 09:29, Vasil Dimov wrote: >>>> *) >>>> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then >>>> - rmdir /tmp/.diskless >>>> + if ( > /tmp/.diskless 2> /dev/null); then >>>> + rm /tmp/.diskless >>>> else >>>> if [ -h /tmp ]; then >>>> echo "*** /tmp is a symlink to a non-writable area!" >>> >>> The thing you suggest is bloody insecure. Just imagine some baduser >>> doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. >>> I guess this is the reason why directory creation is used instead of >>> file creation. >>> >>> I just wonder why a new shell is forked for this test. Simply if >>> /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same >>> thing without forking a new shell that only executes /bin/mkdir >> >> I think it's because the current shell is allowed to exit if a command >> fails while a conditional test like this is run: >> >> if mkdir /tmp/foo; then >> echo foo >> rmdir /tmp/foo >> fi >> >> and mkdir may fail. > > What do you mean by "allowed to exit"? > sh -e? You're right, of course. I forgot the script I was looking at had the -e option enabled. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 13:22:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B61F16A41F for ; Mon, 1 Aug 2005 13:22:26 +0000 (GMT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (71-32-213-112.hlna.qwest.net [71.32.213.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E5043D45 for ; Mon, 1 Aug 2005 13:22:25 +0000 (GMT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.9) with ESMTP id j71DMGYd058644; Mon, 1 Aug 2005 06:22:16 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200508011322.j71DMGYd058644@beastie.mckusick.com> To: Matthew Dillon In-Reply-To: Your message of "Sun, 31 Jul 2005 12:44:16 PDT." Date: Mon, 01 Aug 2005 06:22:08 -0700 From: Kirk McKusick X-Mailman-Approved-At: Tue, 02 Aug 2005 12:21:06 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Possible softupdates bug when a indirect block buffer is reused 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, 01 Aug 2005 13:22:26 -0000 This has been a long nagging problem that was finally tracked down and fixed by Stephan Uphoff . See revision 1.182 on 2005/07/31 to sys/ufs/ffs/ffs_softdep.c. Kirk McKusick =-=-=-=-=-=-= Date: Sun, 31 Jul 2005 11:40:32 -0700 (PDT) From: Matthew Dillon To: Kirk McKusick Cc: freebsd-hackers@freebsd.org Subject: Possible softupdates bug when a indirect block buffer is reused X-ASK-Info: Whitelist match [from dillon@apollo.backplane.com] (2005/07/31 11:40:52) Hi Kirk, hackers! I'm trying to track down a bug that is causing a buffer to be left in a locked state and then causes the filesystem to lock up because of that. The symptoms are that a heavily used filesystem suddenly starts running out of space. It isn't due to deleted files with open descriptors, it's due to the syncer getting stuck in a getblk state. This is in DragonFly, but I can't find anything DFlyish wrong so I'm beginning to think it may be an actual bug in softupdates. I have wound up with a situation where a getblk()'d bp has been associated with a indirdep dependancy, i.e. stored in indirdep->ir_savebp, but is never released. When something like the syncer comes along and tries to access it, it locks up, and this of course leads to inodes not getting cleared and the filesystem eventually runs out of space when a lot of files are being created and deleted. What has got me really confused is that the buffer in question seems to wind up with a D_INDIRDEP dependancy that points back to itself. Here's the situation from a live gdb. Here is where the syncer is stuck: (kgdb) back #0 lwkt_switch () at thread2.h:95 #1 0xc02a8a79 in tsleep (ident=0x0, flags=0, wmesg=0xc04eadb0 "getblk", timo=0) at /usr/src-125beta/sys/kern/kern_synch.c:428 #2 0xc02956bb in acquire (lkp=0xc758b4e0, extflags=33554464, wanted=1536) at /usr/src-125beta/sys/kern/kern_lock.c:127 #3 0xc0295a92 in lockmgr (lkp=0xc758b4e0, flags=33620002, interlkp=0x0, td=0xd68f6400) at /usr/src-125beta/sys/kern/kern_lock.c:354 #4 0xc02d6828 in getblk (vp=0xc71b3058, blkno=94440240, size=8192, slpflag=0, slptimeo=0) at thread.h:79 #5 0xc02d4404 in bread (vp=0xc71b3058, blkno=0, size=0, bpp=0x0) at /usr/src-125beta/sys/kern/vfs_bio.c:567 #6 0xc03f24fe in indir_trunc (ip=0xe048fc0c, dbn=94440240, level=1, lbn=2060, countp=0xe048fbf8) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2221 #7 0xc03f22df in handle_workitem_freeblocks (freeblks=0xe2fcef98) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2138 #8 0xc03f0462 in process_worklist_item (matchmnt=0x0, flags=0) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:726 #9 0xc03f026c in softdep_process_worklist (matchmnt=0x0) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:625 #10 0xc02e5ff3 in sched_sync () at /usr/src-125beta/sys/kern/vfs_sync.c:244 #11 0xc0294863 in kthread_create_stk (func=0, arg=0x0, tdp=0xff800000, stksize=0, fmt=0x0) at /usr/src-125beta/sys/kern/kern_kthread.c:104 (kgdb) The buffer it is stuck on: (kgdb) print bp $62 = (struct buf *) 0xc758b4b8 (kgdb) print *bp $63 = { b_hash = { le_next = 0x0, le_prev = 0xc7391348 }, b_vnbufs = { tqe_next = 0xc739b890, tqe_prev = 0xc76f32b8 }, b_freelist = { tqe_next = 0xc768d610, tqe_prev = 0xc0565ac0 }, b_act = { tqe_next = 0x0, tqe_prev = 0x0 }, b_flags = 536870912, <<<<<<<<< 0x20000000 (getblk with no bread, etc) b_qindex = 0, b_xflags = 2 '\002', b_lock = { lk_interlock = { t_cpu = 0xff800000, t_reqcpu = 0xff800000, t_unused01 = 0 }, lk_flags = 2098176, lk_sharecount = 0, lk_waitcount = 1, lk_exclusivecount = 1, lk_prio = 0, lk_wmesg = 0xc04eadb0 "getblk", lk_timo = 0, lk_lockholder = 0xfffffffe }, b_error = 0, b_bufsize = 8192, b_runningbufspace = 0, b_bcount = 8192, b_resid = 0, b_dev = 0xde0f0e38, b_data = 0xcf824000 "¨\205Ð\002", b_kvabase = 0xcf824000 "¨\205Ð\002", b_kvasize = 16384, b_lblkno = 94440240, b_blkno = 94440240, b_offset = 48353402880, b_iodone = 0, b_iodone_chain = 0x0, b_vp = 0xc71b3058, b_dirtyoff = 0, b_dirtyend = 0, b_pblkno = 87503631, b_saveaddr = 0x0, b_driver1 = 0x0, b_caller1 = 0x0, b_pager = { pg_spc = 0x0, pg_reqpage = 0 }, b_cluster = { cluster_head = { tqh_first = 0x0, tqh_last = 0xc768d6bc ---Type to continue, or q to quit--- }, cluster_entry = { tqe_next = 0x0, tqe_prev = 0xc768d6bc } }, b_xio = { xio_pages = 0xc758b584, xio_npages = 2, xio_offset = 0, xio_bytes = 0, xio_flags = 0, xio_error = 0, xio_internal_pages = {0xc34e5870, 0xc4aeb2b4, 0x0 } }, b_dep = { lh_first = 0xc7045040 }, b_chain = { parent = 0x0, count = 0 } } As you can see from b_flags, which is 0x20000000, the buffer has been getblk()'d but not bread() or anything else. It is the typical state that occurs when a buffer is placed in an indirdep->ir_savebp state in setup_allocindir_phase2(). The buffer's dependancy looks like this: (kgdb) print bp $65 = (struct buf *) 0xc758b4b8 (kgdb) print *(struct indirdep *)bp->b_dep.lh_first $66 = { ir_list = { wk_list = { le_next = 0x0, le_prev = 0xc758b604 }, wk_type = 5, wk_state = 33025 <<<<<<<<<<<<< ATTACHED|GOINGAWAY|ONWORKLIST }, ir_saveddata = 0xdeadc0de "", ir_savebp = 0xc758b4b8, <<<<<<<<<<<<< points back to itself ir_donehd = { lh_first = 0x0 }, ir_deplisthd = { lh_first = 0x0 } } (kgdb) As you can see, the buffer's dependancy seems to point to itself. As you may know, ir_savebp buffers are left in a locked state, so a buffer that has gotten into this situation winds up being permanently deadlocked. This is on DragonFly, but I can't find anything else wrong. This is on a filesystem running a myrid of jails which is constantly creating and deleting files in parallel... so buffers are being reused quite often. It takes about a week of this heavy activity for the bug to rear its ugly head. It's fairly difficult to reproduce (takes about a week to reproduce). When the problem does occur the system remains functional... the disk device continues to work, the filesystem continues to work, except for any blockages that chain down to the particular block that has deadlocked (usually the syncer, but as time goes by more parts of the system will deadlock). It IS possible to run a live gdb when the situation is caught early enough. I am trying to figure out how the buffer manages to get into this self-locked state. I'm pretty much stuck once I get to the deallocate_dependancies() procedure. This procedure seems to be trying to move a D_INDIRDEP dependancy from the passed bp into the buffer pointed to by ir_savebp. As far as I can tell this is what is creating the situation that makes the buffer's dependancy self-referential and deadlocks the syncer. I have noticed a number of FreeBSD bug reports related to blocking in getblk or to softupdates. I don't know if this is a similar problem but it's worth Ccing freebsd-hackers on it as well. My user reports that the problem also occurs on FreeBSD 4.10 and 4.11, on uniprocessor builds (other builds and 5.x/6.x have not been tested). I took a look at the 4.x and 6.x softupdates code and didn't see any commits that might address the problem. This adds weight to the likelihood of it being a softupdates bug of some sort, possibly still present in 6.x. -Matt From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:02:48 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D9F16A41F for ; Mon, 1 Aug 2005 18:02:48 +0000 (GMT) (envelope-from igor.shmukler@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6970643D45 for ; Mon, 1 Aug 2005 18:02:47 +0000 (GMT) (envelope-from igor.shmukler@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so690995nzd for ; Mon, 01 Aug 2005 11:02:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PPhtxqTVGfVQBMGpBCZUCnru+HU+1aqFyfZbfijvRUvg4YNVkhykOLSTyOar1JrbFxHbz5vTf3IEQqtlqHQQqLiuyHwdzrpU9ShHDALX60Y+kSeIzxLQSUuvlCEQmYRSxqsKgHHjZBR9SPINAfgsZikTxLsej1syEy5DvHV7Z4s= Received: by 10.36.37.12 with SMTP id k12mr4762913nzk; Mon, 01 Aug 2005 11:02:46 -0700 (PDT) Received: by 10.36.119.12 with HTTP; Mon, 1 Aug 2005 11:02:46 -0700 (PDT) Message-ID: <6533c1c905080111026f1f07ca@mail.gmail.com> Date: Mon, 1 Aug 2005 14:02:46 -0400 From: Igor Shmukler To: Matthew Dillon In-Reply-To: <200507211926.j6LJQ55D071115@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6533c1c9050721121030016b7d@mail.gmail.com> <200507211926.j6LJQ55D071115@apollo.backplane.com> X-Mailman-Approved-At: Tue, 02 Aug 2005 12:21:06 +0000 Cc: hackers@freebsd.org, fs@freebsd.org Subject: Re: per file lock list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:02:48 -0000 Matt, Thank you very much for response. This is a general solution, but it not sufficient for our needs. I guess I should have been more clear while explaining what we need. We want list of these locks for a group of processes. We made an implementation based on your suggestion, but there is one proble= m... Unfortunately this method does not return all shared locks for a range. For example, if several processes have placed a shared lock on a range [1000 - 2000], F_GETLK returns a flock structure where l_pid field contains a pid of process that takes the lock first. While, we want to know all processes that takes this lock. Is there any way to retrieve such information without using of internal kernel structures (inode information)? Thank you in advance, igor On 7/21/05, Matthew Dillon wrote: > :Hi, > : > :We have a question: how to get all POSIX locks for a given file? > :.. > : > :As far as I know, existing API does not allow to retrieve all file > :locks. Therefore, we need to use kernel internal structures to get all > :... > :So the question: is there an elegant way to get the lock list for a give= n file? > : > :Thank you in advance. >=20 > You can use F_GETLK to iterate through all posix locks held on a file= . > From man fcntl: >=20 > F_GETLK Get the first lock that blocks the lock description point= ed to > by the third argument, arg, taken as a pointer to a struc= t > flock (see above). The information retrieved overwrites = the > information passed to fcntl() in the flock structure. If= no > lock is found that would prevent this lock from being cre= ated, > the structure is left unchanged by this function call exc= ept > for the lock type which is set to F_UNLCK. >=20 > So what you do is you specify a lock description that covers the whol= e > file and call F_GETLK. You then use the results to modify the lock > description to a range that starts just past the returned lock > for the next call. You continue iterating until F_GETLK tells you th= at > there are no more locks. >=20 > -Matt > Matthew Dillon > > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 02:30:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FDDC16A41F for ; Tue, 2 Aug 2005 02:30:14 +0000 (GMT) (envelope-from mwm-dated-1123813795.109329@mired.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F31343D48 for ; Tue, 2 Aug 2005 02:30:14 +0000 (GMT) (envelope-from mwm-dated-1123813795.109329@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 3316A219B1D for ; Mon, 1 Aug 2005 19:30:14 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j722UBvr061807 for ; Mon, 1 Aug 2005 19:30:13 -0700 (PDT) (envelope-from mwm-dated-1123813795.109329@mired.org) Received: (qmail 74620 invoked by uid 1001); 2 Aug 2005 02:29:55 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Mon, 01 Aug 2005 22:29:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17134.55971.274966.717525@bhuda.mired.org> Date: Mon, 1 Aug 2005 22:29:55 -0400 To: Michael Carlson X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer X-Mailman-Approved-At: Tue, 02 Aug 2005 12:21:06 +0000 Cc: freebsd-hackers@freebsd.org, ray@redshift.com Subject: (no subject) 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, 02 Aug 2005 02:30:14 -0000 Subject: Re: FreeBSD desktop? In-Reply-To: <1122924209.19849.18.camel@wushu.llnl.gov> References: <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <1122924209.19849.18.camel@wushu.llnl.gov> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Bcc: mwm-local@localhost X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ --text follows this line-- In <1122924209.19849.18.camel@wushu.llnl.gov>, Michael Carlson typed: > But if you dont want to wait a couple of days, XFCE is probably the > lightest Window Manager. Not a chance. It uses gtk, which is bigger than lwm (/usr/ports/x11-wm/lwm) all by itself. And lwm isn't the lightest WM around - it's just the one I'm familiar with. The catch with the real lightweight window managers is that you configure them with cc. But if small and fast is what you want, they're the ticket. If you've been using Windows, you might prefer qvwm (/usr/ports/x11-wm/qvwm), which is a Windows 95/98/NT like window manager. I don't see one that emulates XP, and a quick google only turns up XPde, which appears to be a dead. If you think window management is to important to be left to such a low-bandwidth device as a mouse(*), then you might try ratpoison (/usr/ports/x11-wm/ratpoison). It's not for everyone, but it *really* confuses Mac and Windows users. Personally, I prefer plpwm (an example manager in /usr/ports/x11-wm/plwm), but I wrote it. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 13:08:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9D8016A41F for ; Tue, 2 Aug 2005 13:08:14 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 426F043D49 for ; Tue, 2 Aug 2005 13:08:14 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from sinanica.bg.datamax (sinanica.bg.datamax [192.168.10.1]) by jengal.datamax.bg (Postfix) with QMQP id 2128D87C8 for ; Tue, 2 Aug 2005 16:08:13 +0300 (EEST) Received: (nullmailer pid 23329 invoked by uid 1004); Tue, 02 Aug 2005 13:08:12 -0000 Date: Tue, 2 Aug 2005 16:08:12 +0300 From: Vasil Dimov To: freebsd-hackers@freebsd.org Message-ID: <20050802130812.GA23261@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <42EF5072.30808@freesbie.org> <20050802110632.GB85997@sinanica.bg.datamax> <20050802111535.GA2468@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20050802111535.GA2468@britannica.bec.de> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i Subject: Re: [patch] rc.d/tmp (silly mkdir usage) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 13:08:14 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 01:15:35PM +0200, Joerg Sonnenberger wrote: > On Tue, Aug 02, 2005 at 02:06:32PM +0300, Vasil Dimov wrote: > > On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > > > Vasil Dimov wrote: > > > > Even we can use > > > > if [ -d /tmp -a -w /tmp ] ; then > > > > or (which is equivalent) > > > > if [ -d /tmp ] && [ -w /tmp ] ; then > > > > and save external commands (mkdir) execution and directory > > > > creation/deletion at all. > > >=20 > > > You can't use test -w here. The script is checking if there is a > > > read-only filesystem. -w checks only the file flags (according to the > > > man page, at least). > > >=20 > > That's correct, -w cannot be used to check read-only filesystem. >=20 > Actually, you can. That's not portable behaviour though. >=20 Well, look what I discovered: # mount |grep read-only /usr/ports on /mnt/ar0s2d/usr/ports5 (nullfs, local, read-only) # sh -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' # bash -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' writeable # One should really not rely on this. --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFC73A8Fw6SP/bBpCARAl+RAJ9XxERDhYhKFrPwIisF2seD0cQHKwCgyvGT Iu2nX5+E1GiolRIsZSOFh8Y= =fHyP -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 13:25:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D52616A41F for ; Tue, 2 Aug 2005 13:25:58 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D25BA43D45 for ; Tue, 2 Aug 2005 13:25:57 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 5A67B35707 for ; Tue, 2 Aug 2005 15:25:54 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 597FB5406; Tue, 2 Aug 2005 15:23:44 +0200 (CEST) Date: Tue, 2 Aug 2005 15:23:43 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050802132343.GA3012@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <42EF5072.30808@freesbie.org> <20050802110632.GB85997@sinanica.bg.datamax> <20050802111535.GA2468@britannica.bec.de> <20050802130812.GA23261@sinanica.bg.datamax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802130812.GA23261@sinanica.bg.datamax> User-Agent: Mutt/1.5.6i Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 13:25:58 -0000 On Tue, Aug 02, 2005 at 04:08:12PM +0300, Vasil Dimov wrote: > On Tue, Aug 02, 2005 at 01:15:35PM +0200, Joerg Sonnenberger wrote: > > On Tue, Aug 02, 2005 at 02:06:32PM +0300, Vasil Dimov wrote: > > > On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > > > > Vasil Dimov wrote: > > > > > Even we can use > > > > > if [ -d /tmp -a -w /tmp ] ; then > > > > > or (which is equivalent) > > > > > if [ -d /tmp ] && [ -w /tmp ] ; then > > > > > and save external commands (mkdir) execution and directory > > > > > creation/deletion at all. > > > > > > > > You can't use test -w here. The script is checking if there is a > > > > read-only filesystem. -w checks only the file flags (according to the > > > > man page, at least). > > > > > > > That's correct, -w cannot be used to check read-only filesystem. > > > > Actually, you can. That's not portable behaviour though. > > > > Well, look what I discovered: As I said, it is not portable. > > # mount |grep read-only > /usr/ports on /mnt/ar0s2d/usr/ports5 (nullfs, local, read-only) > # sh -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' > # bash -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' > writeable I'd say this is a bug in the bash builtin :-) Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 13:28:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC5BF16A41F for ; Tue, 2 Aug 2005 13:28:27 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCE743D45 for ; Tue, 2 Aug 2005 13:28:27 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from sinanica.bg.datamax (sinanica.bg.datamax [192.168.10.1]) by jengal.datamax.bg (Postfix) with QMQP id 4A53387C8; Tue, 2 Aug 2005 16:28:26 +0300 (EEST) Received: (nullmailer pid 23465 invoked by uid 1004); Tue, 02 Aug 2005 13:28:26 -0000 Date: Tue, 2 Aug 2005 16:28:26 +0300 From: Vasil Dimov To: Giorgos Keramidas Message-ID: <20050802132826.GB23261@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <20050802093348.GC1307@beatrix.daedalusnetworks.priv> <20050802110522.GA85997@sinanica.bg.datamax> <20050802113836.GA2077@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <20050802113836.GA2077@beatrix.daedalusnetworks.priv> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 13:28:28 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 02:38:36PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 14:05, Vasil Dimov wrote: > >On Tue, Aug 02, 2005 at 12:33:48PM +0300, Giorgos Keramidas wrote: > >>On 2005-08-02 09:29, Vasil Dimov wrote: > >>>> *) > >>>> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > >>>> - rmdir /tmp/.diskless > >>>> + if ( > /tmp/.diskless 2> /dev/null); then > >>>> + rm /tmp/.diskless > >>>> else > >>>> if [ -h /tmp ]; then > >>>> echo "*** /tmp is a symlink to a non-writabl= e area!" > >>> > >>> The thing you suggest is bloody insecure. Just imagine some baduser > >>> doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > >>> I guess this is the reason why directory creation is used instead of > >>> file creation. > >>> > >>> I just wonder why a new shell is forked for this test. Simply if > >>> /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same > >>> thing without forking a new shell that only executes /bin/mkdir > >> > >> I think it's because the current shell is allowed to exit if a command > >> fails while a conditional test like this is run: > >> > >> if mkdir /tmp/foo; then > >> echo foo > >> rmdir /tmp/foo > >> fi > >> > >> and mkdir may fail. > > > > What do you mean by "allowed to exit"? > > sh -e? >=20 > You're right, of course. I forgot the script I was looking at had the -e > option enabled. >=20 Hmmz, I don't think /etc/rc.d/tmp is started with sh -e. Anyway even if it is, this will not cause sh to exit if mkdir fails. =66rom sh(1): -e errexit Exit immediately if any untested command fails in non-interactive mode. The exit status of a command is considered to be explic- itly tested if the command is used to control an if, elif, while, # sh -e -c 'if mkdir /a/b ; then echo t ; else echo f ; fi ; echo still ali= ve' mkdir: /a: No such file or directory f still alive # And even more - the braces () would not save us if the command were intested because the forked shell exits with the exit status of the last command executed (e.g. if mkdir fails it will fail too): # sh -e -c '( mkdir /a/b ) ; echo still alive' mkdir: /a: No such file or directory # So what is the point of doing "if ( mkdir ... ) ; then" instead of "if mkdir ... ; then"? Did I miss something... --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFC73T5Fw6SP/bBpCARAldOAJ9GqwJuWtD3qhI8VBru68vvH6VOugCgy6gJ fGabF22MCrpv8LvO4w8RB6M= =KClg -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 16:48:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5322B16A41F for ; Tue, 2 Aug 2005 16:48:55 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4566B43D5F for ; Tue, 2 Aug 2005 16:48:48 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 54974264279; Tue, 2 Aug 2005 11:47:22 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21477-02; Tue, 2 Aug 2005 11:47:20 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id D1CEF264053; Tue, 2 Aug 2005 11:47:19 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Tue, 2 Aug 2005 11:47:19 -0500 (CDT) Message-ID: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> In-Reply-To: <20050802062937.GA31485@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> Date: Tue, 2 Aug 2005 11:47:19 -0500 (CDT) From: diz@linuxpowered.com To: vd@datamax.bg User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 16:48:55 -0000 > On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote: >> Howdy hackers, >> >> I'm sorry for the previous patch, so here is at least one item that >> really >> bugs me that isn't obfuscation. In short, I don't see any reason to fork >> some process to simply "touch" a file (is a filesystem writable) when >> built-in shell i/o does this: >> >> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 >> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 >> @@ -48,8 +48,8 @@ >> [Nn][Oo]) >> ;; >> *) >> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then >> - rmdir /tmp/.diskless >> + if ( > /tmp/.diskless 2> /dev/null); then >> + rm /tmp/.diskless >> else >> if [ -h /tmp ]; then >> echo "*** /tmp is a symlink to a non-writable >> area!" >> > > The thing you suggest is bloody insecure. Just imagine some baduser > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > I guess this is the reason why directory creation is used instead of > file creation. Well these notions have nothing todo with the way it works, but they are interesting still. I would imagine a dir could be linked too if somebody managed to insert a rc.d script in that was ordered sufficiently early enough to do the evil tasks you are thinking about. Even if mktemp(1) were available at this stage, I wouldn't use it here. > > I just wonder why a new shell is forked for this test. Simply > if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then > would do the same thing without forking a new shell that only executes > /bin/mkdir Let me be clear about this, the ONLY reason mkdir is used here is because touch is under /usr somewhere which isn't even mounted at this point (assuming /usr is mounted seperatly, as is the case on nfs diskless systems). So we are left with what is availabile in /bin, /sbin, /rescue. Therefore mkdir was used as a work-around. What I'm saying is this entire thought process is overly-engineered when the shell can simply "touch" a file with stdout or stderr. This is indeed the most minor of optimizations. > > Even we can use > if [ -d /tmp -a -w /tmp ] ; then > or (which is equivalent) > if [ -d /tmp ] && [ -w /tmp ] ; then > and save external commands (mkdir) execution and directory > creation/deletion at all. > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 17:28:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C89016A41F for ; Tue, 2 Aug 2005 17:28:51 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34B2543D45 for ; Tue, 2 Aug 2005 17:28:51 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j72HSPN3001276; Tue, 2 Aug 2005 10:28:25 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j72HSPPj001275; Tue, 2 Aug 2005 10:28:25 -0700 Date: Tue, 2 Aug 2005 10:28:25 -0700 From: Brooks Davis To: diz@linuxpowered.com Message-ID: <20050802172825.GA19107@odin.ac.hmc.edu> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-hackers@freebsd.org, vd@datamax.bg Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 17:28:51 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 11:47:19AM -0500, diz@linuxpowered.com wrote: > > On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote: > >> Howdy hackers, > >> > >> I'm sorry for the previous patch, so here is at least one item that > >> really > >> bugs me that isn't obfuscation. In short, I don't see any reason to fo= rk > >> some process to simply "touch" a file (is a filesystem writable) when > >> built-in shell i/o does this: > >> > >> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > >> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > >> @@ -48,8 +48,8 @@ > >> [Nn][Oo]) > >> ;; > >> *) > >> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > >> - rmdir /tmp/.diskless > >> + if ( > /tmp/.diskless 2> /dev/null); then > >> + rm /tmp/.diskless > >> else > >> if [ -h /tmp ]; then > >> echo "*** /tmp is a symlink to a non-writable > >> area!" > >> > > > > The thing you suggest is bloody insecure. Just imagine some baduser > > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > > I guess this is the reason why directory creation is used instead of > > file creation. >=20 > Well these notions have nothing todo with the way it works, but they are > interesting still. I would imagine a dir could be linked too if somebody > managed to insert a rc.d script in that was ordered sufficiently early > enough to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. No, mkdir won't act through the link so it's the best option here: $ rm nonexistant $ ls nonexistant ls: nonexistant: No such file or directory $ ln -s nonexistant n1 $ mkdir n1 mkdir: n1: File exists $ ls nonexistant ls: nonexistant: No such file or directory $ > n1 $ ls n1 n1 $ ls nonexistant nonexistant $ echo foobar >> nonexistant $ cat nonexistant foobar $ > n1 $ cat nonexistant $ mkdir n1 mkdir: n1: File exists $ > > I just wonder why a new shell is forked for this test. Simply > > if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then > > would do the same thing without forking a new shell that only executes > > /bin/mkdir >=20 > Let me be clear about this, the ONLY reason mkdir is used here is because > touch is under /usr somewhere which isn't even mounted at this point > (assuming /usr is mounted seperatly, as is the case on nfs diskless > systems). So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this entire > thought process is overly-engineered when the shell can simply "touch" a > file with stdout or stderr. This is indeed the most minor of > optimizations. Nope. $ rm nonexistant $ touch n1 $ ls nonexistant nonexistant -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC7602XY6L6fI4GtQRAsYfAJ95VzuMq+d2Nkik+fKBAnhe5QP/zwCcDroa MaQuqIZp3hgBELHrm36ODEI= =7ssP -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 17:44:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C427016A41F for ; Tue, 2 Aug 2005 17:44:49 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 527CC43D55 for ; Tue, 2 Aug 2005 17:44:49 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id BEEB42B4E6; Tue, 2 Aug 2005 12:44:48 -0500 (CDT) Date: Tue, 2 Aug 2005 12:44:45 -0500 From: Craig Boston To: diz@linuxpowered.com Message-ID: <20050802174445.GA47508@nowhere> Mail-Followup-To: Craig Boston , diz@linuxpowered.com, vd@datamax.bg, freebsd-hackers@freebsd.org References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, vd@datamax.bg Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 17:44:49 -0000 On Tue, Aug 02, 2005 at 11:47:19AM -0500, diz@linuxpowered.com wrote: > Well these notions have nothing todo with the way it works, but they are > interesting still. I would imagine a dir could be linked too if somebody > managed to insert a rc.d script in that was ordered sufficiently early > enough to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. A link could also be left over from before the boot. rc.d/tmp runs before cleartmp. > Let me be clear about this, the ONLY reason mkdir is used here is > because touch is under /usr somewhere which isn't even mounted at this > point (assuming /usr is mounted seperatly, as is the case on nfs > diskless systems). No, touch has different behavior than mkdir. Whether it was done intentionally or just happens to be the case because /usr is not available, mkdir is the most secure and robust way to go, because it covers all of the cases: 1) /tmp/.diskless doesn't exist -> A directory .diskless is created, which is then removed 2) /tmp/.diskless is a link to a file -> mkdir fails because "File exists" 3) /tmp/.diskless is a link to a directory -> mkdir succeeds but does nothing because -p was specified. The link is then removed. 4) /tmp/.diskless is a link to a nonexistent path or name -> mkdir fails (even with -p) because it can't follow the link: "No such file or directory" 5) /tmp/.diskless exists and is a file -> mkdir fails: "File exists" 6) /tmp/.diskless exists and is a directory -> mkdir succeeds. Later, /tmp/.diskless is removed _only_ if it is empty. Even though touch doesn't change file contents, it could potentially be abused to change the timestamp on an arbitrary file if a link were left in /tmp. The only way to securely use touch or ">" would be to rm -f /tmp/.diskless first, and that is a potentially destructive operation on the off chance the administrator created a file called /tmp/.diskless. It's a very remote chance yes, but why Creating a file called that may cause undesired effects such as mounting an mfs /tmp when you didn't want one, but it won't cause any data loss. > So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this > entire thought process is overly-engineered when the shell can simply > "touch" a file with stdout or stderr. This is indeed the most minor of > optimizations. It's not a minor optimization if it changes the semantics of what happens. > is very dangerous because it could nuke a random file if a symlink exists. Even >> or touch can mess with timestamps or create files that don't exist, all with the power of root. Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 17:49:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9C7D16A41F for ; Tue, 2 Aug 2005 17:49:52 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 855C343D48 for ; Tue, 2 Aug 2005 17:49:52 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 548622B4E6; Tue, 2 Aug 2005 12:49:52 -0500 (CDT) Date: Tue, 2 Aug 2005 12:49:50 -0500 From: Craig Boston To: diz@linuxpowered.com, vd@datamax.bg, freebsd-hackers@freebsd.org Message-ID: <20050802174949.GB47508@nowhere> Mail-Followup-To: Craig Boston , diz@linuxpowered.com, vd@datamax.bg, freebsd-hackers@freebsd.org References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> <20050802174445.GA47508@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802174445.GA47508@nowhere> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 17:49:52 -0000 Sigh, that's what I get for editing before I finish writing. On Tue, Aug 02, 2005 at 12:44:45PM -0500, Craig Boston wrote: > It's a very remote chance yes, but why ...but why take that chance when mkdir works perfectly fine? Chances are mkdir will be used at some point during the rc.d startup anyway, so forking a process for an executable in the cache (or bringing it into the cache so it can be used later) is a negligible performance loss, especially when it only happens once. Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 17:54:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E635616A41F for ; Tue, 2 Aug 2005 17:54:47 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B145143D45 for ; Tue, 2 Aug 2005 17:54:47 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 52B479791D for ; Tue, 2 Aug 2005 10:54:47 -0700 (PDT) Message-Id: <3.0.1.32.20050802105450.00a547c8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Tue, 02 Aug 2005 10:54:50 -0700 To: freebsd-hackers@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: GTK+ 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, 02 Aug 2005 17:54:48 -0000 Does anyone on the hackers list develop in GTK+ ? I was thinking about trying my hand at some applications for BSD and would like to make contact with anyone else who programs for FreeBSD using the GTK frame work. Thanks. Ray From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 19:11:25 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9962316A41F; Tue, 2 Aug 2005 19:11:25 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B1C43D45; Tue, 2 Aug 2005 19:11:25 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id j72JBOna097156; Tue, 2 Aug 2005 15:11:24 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id j72JBNFx097155; Tue, 2 Aug 2005 15:11:23 -0400 (EDT) (envelope-from afields) Date: Tue, 2 Aug 2005 15:11:23 -0400 From: Allan Fields To: "Ronnel P. Maglasang" Message-ID: <20050802191123.GC230@afields.ca> References: <42E9BC12.2050401@infoweapons.com> <20050729065357.GA617@darkness.comp.waw.pl> <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net> <42EEDABE.7080402@infoweapons.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: <42EEDABE.7080402@infoweapons.com> User-Agent: Mutt/1.4i Cc: Alexander Leidinger , freebsd-geom , Pawel Jakub Dawidek , freebsd-hackers Subject: Re: booting gbde-encrypted filesystem 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, 02 Aug 2005 19:11:25 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 10:30:22AM +0800, Ronnel P. Maglasang wrote: > What I had in mind is perhaps I could find a way to > enter the passphrase at the loader prompt, or configure > the loader to get the passphrase from an external > device or hardcoded the passphrase in the bootloader(really > insecure). I understand you model which is to have something required to ensure the disks cannot be read w/o physical token. Theoretically the loader could allow you to fetch some memory address and insert it into a boot variable. If you just want to ensure a token is required to enable access to a machine you could add something in the root-FS patch which reads directly from the hardware device, though this is before the full device infrastructure is bootstrapped IRC. What about the idea of adding support for HSM and TPMs? Hardware keystores and other similar authentication mechanisms which push a key into a secure memory accessible by the crypto API might be the answer. I am looking at similar solutions. My idea is to enable remote authentication through a secure means. So there are multiple options: to secure console access. * Some IPMI hardware has an ethernet accessible console, that can then be routed through a secure tunnel. * There is the idea of ethercons if it can be extended to support encryption. * A serial console can be accessed through another machine securely This one has been around since a few years back, but the below patch brings it closer to being workable. > Alexander Leidinger wrote: >=20 > >Pawel Jakub Dawidek wrote: > > > >>This is not not possible with current GBDE. > >>I've patches which allows this here: > >> > >> http://people.freebsd.org/~pjd/patches/gbde.patch > > > > > >I fail to see how this allows an encryted root-FS, it doesn't add gbde > >support to boot0(ext) or to the loader. It needs access to an unencrypted > >kernel. I don't think this is what Ronnel had in mind (overlooking the= =20 > >fact > >that his suggestion to save the passphrase in the loader is insecure). An unencrypted kernel can be read off of another device and then used to mount the encrypted root. > >Bye, > >Alexander. > > -- = = =20 Allan Fields (afields) - Ottawa, Canada (45"10'N 75"56'W) = = =20 Himeji Systems http://himejisystems.com = = =20 Afields Research/AFRSL http://afields.ca=20 --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQFC78Va90UNcjm0VUERAiJQAJ0aSaKz1Jjpb7tpJy4U/8pjbmRITACgnXhk NYXLREie0vwpa+/Zd3/ery8= =JLPk -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 20:29:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4670C16A426 for ; Tue, 2 Aug 2005 20:29:11 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE42643D45 for ; Tue, 2 Aug 2005 20:29:10 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j72KTAoC076018 for ; Tue, 2 Aug 2005 13:29:10 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j72KTAqG013754 for ; Tue, 2 Aug 2005 13:29:10 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j72KT9jq013753; Tue, 2 Aug 2005 13:29:09 -0700 (PDT) (envelope-from frank) Date: Tue, 2 Aug 2005 13:29:09 -0700 From: Frank Mayhar To: freebsd-hackers@freebsd.org Message-Id: <20050802132909.064d8260.frank@exit.com> In-Reply-To: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> Organization: Exit Consulting X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1001/Tue Aug 2 01:22:39 2005 on tinker.exit.com X-Virus-Status: Clean Subject: Re: [patch] rc.d/tmp (silly mkdir usage) 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, 02 Aug 2005 20:29:11 -0000 On Tue, 2 Aug 2005 11:47:19 -0500 (CDT) diz@linuxpowered.com wrote: > "When all you've got is a hammer, everything looks like a nail." Sorry, maybe it didn't have to be said. I tried, though, I did. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 22:22:10 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 083D016A41F for ; Tue, 2 Aug 2005 22:22:10 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.tele2.se [212.247.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B31E43D53 for ; Tue, 2 Aug 2005 22:22:09 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-217-203-26.daxnet.no ([193.217.203.26] verified) by mailfe09.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 223986074 for freebsd-hackers@freebsd.org; Wed, 03 Aug 2005 00:22:06 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 3 Aug 2005 00:23:04 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508030023.04748.hselasky@c2i.net> Subject: How to do proper locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 22:22:10 -0000 Hi, I am looking for a safe way to access structures that can be freed. The solution I am looking for must not: - hinder scaleability - lead to use of a single lock - lead to lock order reversal Here is the solution I have landed on so far: First I plan to make a reference count manager that has the following extern functions: u_int32_t *ref_alloc(); // will allocate a reference count void ref_free(u_int32_t *); // will free a reference count and increment it. // Note that the pointer passed to this function // is still valid after its call u_int32_t ref_atomic_read(u_int32_t *); // will read the value // of a reference count void ref_atomic_increment(u_int32_t *); // will increment the value // of a reference count Assume that we have the following structure: struct my_struct { struct mtx *p_mtx; u_int32_t *p_ref; u_int8_t my_data[256]; }; At some point this structure is allocated: static struct my_struct *ptr; mtx_lock(lock_A); if(ptr == NULL) { ptr = malloc(...); if(ptr) { ptr->p_ref = ref_alloc(); ptr->p_mtx = mtx_alloc(); } } mtx_unlock(lock_A); At some other point it is freed: mtx_lock(lock_A); ptr_copy = ptr; ptr = NULL; mtx_unlock(lock_A); if(ptr_copy) { mtx_lock(ptr_copy->p_mtx); // we want to hold this lock // to block the callback while // incrementing refcount ref_free(ptr_copy->p_ref); // will increment the refcount mtx_unlock(ptr_copy->p_mtx); mtx_free(ptr_copy->p_mtx); // Note: mutex is still valid after this! free(ptr_copy); } Then at the last point we want to access this structure, but we don't want to hold "lock_A", but rather "ptr->p_mtx", to increase performance. FIRST_PART: mtx_lock(lock_A); if(ptr) { p_ref_copy = ptr->p_ref; ref_value = ref_atomic_read(ptr->p_ref); p_mtx_copy = ptr->p_mtx; } else { p_ref_copy = NULL; } mtx_unlock(lock_A); SECOND_PART: if(p_ref_copy) { mtx_lock(p_mtx_copy); if(ref_value == ref_atomic_read(p_ref_copy)) { /* this structure is still allocated */ CALLBACK_CODE_HERE: } else { /* this structure has been freed */ } mtx_unlock(p_mtx_copy); } To access a memory structure safely, one needs three parameters, according to my theory: "p_ref_copy", "ref_value", "p_mtx_copy". Then I thought that one might prestore these, so that the "FIRST_PART" can be skipped, left with only the "SECOND_PART". Then I thought that the "SECOND_PART" could be implemented by existing callbacks, so that we stay out of trouble. Any comments ? (Hence todays computers are so fast, one might want to use a 64-bit reference count. So after some billion years my model will fail, but one will probably reboot long before that :-) --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 01:41:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A57B016A41F for ; Wed, 3 Aug 2005 01:41:19 +0000 (GMT) (envelope-from rittera@cc.wwu.edu) Received: from titan.cc.wwu.edu (titan.cc.wwu.edu [140.160.240.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB2743D48 for ; Wed, 3 Aug 2005 01:41:19 +0000 (GMT) (envelope-from rittera@cc.wwu.edu) Received: (from nobody@localhost) by titan.cc.wwu.edu (8.11.7p1+Sun/8.11.7) id j731fI117285; Tue, 2 Aug 2005 18:41:18 -0700 (PDT) From: Alan Ritter X-Authentication-Warning: titan.cc.wwu.edu: nobody set sender to rittera@cc.wwu.edu using -f Received: from 63.226.220.24 (SquirrelMail authenticated user rittera) by www.ac.wwu.edu with HTTP; Tue, 2 Aug 2005 18:41:18 -0700 (PDT) Message-ID: <62833.63.226.220.24.1123033278.squirrel@www.ac.wwu.edu> Date: Tue, 2 Aug 2005 18:41:18 -0700 (PDT) To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: [Fwd: Porting FreeBSD NDIS to NetBSD/nmb_fddirxindicate_func()] 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, 03 Aug 2005 01:41:19 -0000 Oops, there is no tech-kern@freebsd.org. I hope this is the correct list for this message :-) ---------------------------- Original Message ---------------------------- Subject: Porting FreeBSD NDIS to NetBSD/nmb_fddirxindicate_func() From: "Alan Ritter" Date: Tue, August 2, 2005 4:26 pm To: wpaul@windriver.com Cc: tech-kern@netbsd.org tech-kern@freebsd.org -------------------------------------------------------------------------- Hi, I'm trying to port the FreeBSD NDIS code to NetBSD as part of Google's "Summer of Code" project (http://code.google.com/summerofcode.html). I'm having a little problem right now, when the attach function calls ndis_init_nic(), which calls the MiniportInitalize() function from the binary Windows driver for my network card (I got this working on FreeBSD) it blows up on the following instruction: call DWORD PTR [eax+380] After playing around with the debugger a bit I'm quite certain that eax is a pointer to the ndis_miniport_block, and 380 is the offset of the nmb_fddirxindicate_func() field within it. All there is at this address, however is 0x0: (gdb) x/8a $eax + 380 0xc15b2d7c: 0x0 0x0 0x0 0x0 0xc15b2d8c: 0xc0745955 0xc07459ad 0x0 0xc0745a32 I'm assuming that this should have been initialized somewhere, but I can't find any place in the code where nmb_fddirxindicate_func() is referenced. Maybe it is supposed to be initialized inside the binary Windows driver? I also tried jumping past the offending instruction, and there appeared to be more calls to uninitialized functions in the ndis_miniport_block(). Anyway, I just thought I'd check and see if you knew more about the nmb_fddirxindicate_func() member of the ndis_miniport_block structure. Thanks. P.S. here's some pointers to more information: My blog for the project: http://ndis-netbsd.blogspot.com/ Links to my sources online: http://cvs.sourceforge.net/viewcvs.py/netbsd-soc/ndis/ The project's webpage: http://netbsd-soc.sourceforge.net/projects/ndis/ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 02:31:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D01516A41F for ; Wed, 3 Aug 2005 02:31:23 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.28]) by mx1.FreeBSD.org (Postfix) with SMTP id E5AA543D46 for ; Wed, 3 Aug 2005 02:31:21 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 29888 invoked from network); 3 Aug 2005 02:31:20 -0000 Received: from maxwell2.pacific.net.sg (203.120.90.192) by smtpgate2.pacific.net.sg with SMTP; 3 Aug 2005 02:31:19 -0000 Received: from [192.168.0.107] ([210.24.246.110]) by maxwell2.pacific.net.sg with ESMTP id <20050803023119.GULW28012.maxwell2.pacific.net.sg@[192.168.0.107]>; Wed, 3 Aug 2005 10:31:19 +0800 Message-ID: <42F02C4D.8040703@pacific.net.sg> Date: Wed, 03 Aug 2005 10:30:37 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801043607.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801051007.00a5aeb0@pop.redshift.com> <3.0.1.32.20050801231310.00a5f7e8@pop.redshift.com> In-Reply-To: <3.0.1.32.20050801231310.00a5f7e8@pop.redshift.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Karel Miklav Subject: Re: FreeBSD desktop? 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, 03 Aug 2005 02:31:23 -0000 Hi, ray@redshift.com wrote: > At 08:10 AM 8/2/2005 +0200, Karel Miklav wrote: > | ray@redshift.com wrote: > Thanks Karel. I got my FreeBSD desktop up and running. It's on X window and > gnome. I am not sure about setting up the window manager, but may try that You have already one window manager running. Gnome uses its own default windows manager which name I forgot but can you many others. Just stick to it as long as you are happy with it. If you later feel that Gnome as a bit fat, you then can start using other Gnome compatible window managers. This gives you the option to switch between Gnome and your new window manager and it also gives you the option to tell Gnome to use that window manager. Get used now to your 'new' desktop and scout out what possibilities it has. Erich From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 05:15:51 2005 Return-Path: X-Original-To: freebsd-hackers@www.freebsd.org Delivered-To: freebsd-hackers@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6D016A41F for ; Wed, 3 Aug 2005 05:15:51 +0000 (GMT) (envelope-from gba@undef.net) Received: from juanita.undef.net (undef.net [216.218.240.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B411C43D48 for ; Wed, 3 Aug 2005 05:15:50 +0000 (GMT) (envelope-from gba@undef.net) Received: (qmail 15074 invoked from network); 2 Aug 2005 22:15:50 -0700 Received: from adsl-69-237-156-188.dsl.irvnca.pacbell.net (HELO ?172.29.29.100?) (gba@69.237.156.188) by 0 (qmail 1.03 + ejcp v14) with SMTP; 2 Aug 2005 22:15:50 -0700 Message-ID: <42F053EC.2060705@undef.net> Date: Tue, 02 Aug 2005 22:19:40 -0700 From: Greg Albrecht User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@lists.freebsd.org, t12@undef.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 5.3 scheduler problem reborn in 5.4-rel-p5? 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, 03 Aug 2005 05:15:51 -0000 in searching for an answer to my problem, i came across this thread, to which there doesn't seem to have been a resolve: http://www.monkey.org/freebsd/archive/freebsd-hackers/200504/msg00007.html i must say that my problem is almost identical, per my dump: http://undef.net/2005-08-02-dump.txt 'sio' is compiled into my kernel, although there was no serial in use at the time of my crash. FreeBSD juanita.undef.net 5.4-RELEASE-p5 FreeBSD 5.4-RELEASE-p5 #1: Mon Jul 25 14:26:34 PDT 2005 gba@juanita.undef.net:/usr/obj/usr/src/sys/JUANITA i386 need more details? thanks, -g -- Greg Albrecht (gba@undef.net) * -0700 GMT/UTC http://undef.net * +1 213 447 3089 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 08:01:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2A9316A41F for ; Wed, 3 Aug 2005 08:01:46 +0000 (GMT) (envelope-from lists@nbux.com) Received: from smtp3.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F4BF43D45 for ; Wed, 3 Aug 2005 08:01:45 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0308.wanadoo.fr (SMTP Server) with ESMTP id 9BC4020000A8 for ; Wed, 3 Aug 2005 10:01:42 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152-22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf0308.wanadoo.fr (SMTP Server) with ESMTP id 778EB200008F; Wed, 3 Aug 2005 10:01:42 +0200 (CEST) X-ME-UUID: 20050803080142489.778EB200008F@mwinf0308.wanadoo.fr Received: from webmail.nbux.com (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id 48204197DB8; Wed, 3 Aug 2005 10:01:27 +0200 (CEST) Received: from 194.51.215.62 (SquirrelMail authenticated user lists) by webmail.nbux.com with HTTP; Wed, 3 Aug 2005 10:01:27 +0200 (CEST) Message-ID: <19152.194.51.215.62.1123056087.squirrel@webmail.nbux.com> Date: Wed, 3 Aug 2005 10:01:27 +0200 (CEST) From: "Christophe Yayon" To: freebsd-bugs@freebsd.org, freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at nbux.com Cc: Subject: freebsd 4.11-stable strange problem dl360g4 partial freeze 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, 03 Aug 2005 08:01:47 -0000 Hi all, I have just installed a new (but good old) freebsd 4.11-stable on a HP DL360G4 and i have a very strange issue : when i do a simple command like 'find /' or 'dmesg' or a 'ls' in a directory with lot of files ; the command is pausing ... I explain, the result of the command begin and afer few result lines, it pausing (like a partial freeze of 1 or 2 seconds) and continue, and pausing again, and then continue... I have tried to recompile a new kernel and world (from stable of yesterday) but i have the same woes. I also try to truss, but no strange messages, no log no kernel messages... I have tried on the same server the 5.4-STABLE (with other disks) and i have not this problem... But i have to install a 4.11 version, because of commercial software... Is it a specific issue with freebsd 4 ? How can i do to debug it ? Do you have any informations about this ? Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 08:31:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EDC116A41F for ; Wed, 3 Aug 2005 08:31:35 +0000 (GMT) (envelope-from lists@nbux.com) Received: from smtp9.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3163A43D72 for ; Wed, 3 Aug 2005 08:31:29 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0908.wanadoo.fr (SMTP Server) with ESMTP id B5EF21C00142 for ; Wed, 3 Aug 2005 10:31:26 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152-22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf0908.wanadoo.fr (SMTP Server) with ESMTP id 808051C0013C for ; Wed, 3 Aug 2005 10:31:26 +0200 (CEST) X-ME-UUID: 20050803083126526.808051C0013C@mwinf0908.wanadoo.fr Received: from webmail.nbux.com (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id C3048197F37 for ; Wed, 3 Aug 2005 10:30:58 +0200 (CEST) Received: from 194.51.215.62 (SquirrelMail authenticated user lists) by webmail.nbux.com with HTTP; Wed, 3 Aug 2005 10:30:58 +0200 (CEST) Message-ID: <29928.194.51.215.62.1123057858.squirrel@webmail.nbux.com> Date: Wed, 3 Aug 2005 10:30:58 +0200 (CEST) From: "Christophe Yayon" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at nbux.com Subject: freebsd 4.11-stable strange problem dl360g4 partial freeze 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, 03 Aug 2005 08:31:35 -0000 Hi all, I have just installed a new (but good old) freebsd 4.11-stable on a HP DL360G4 and i have a very strange issue : when i do a simple command like 'find /' or 'dmesg' or a 'ls' in a directory with lot of files ; the command is pausing ... I explain, the result of the command begin and afer few result lines, it pausing (like a partial freeze of 1 or 2 seconds) and continue, and pausing again, and then continue... I have tried to recompile a new kernel and world (from stable of yesterday) but i have the same woes. I also try to truss, but no strange messages, no log no kernel messages... I have tried on the same server the 5.4-STABLE (with other disks) and i have not this problem... But i have to install a 4.11 version, because of commercial software... Is it a specific issue with freebsd 4 ? How can i do to debug it ? Do you have any informations about this ? Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 16:39:04 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1CD016A41F for ; Wed, 3 Aug 2005 16:39:03 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA0CD43D64 for ; Wed, 3 Aug 2005 16:38:59 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.3/8.13.1) with ESMTP id j73Gcam7032455 for ; Wed, 3 Aug 2005 18:38:36 +0200 (CEST) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.3/8.13.1/Submit) with ESMTP id j73GcaW2032452 for ; Wed, 3 Aug 2005 18:38:36 +0200 (CEST) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Wed, 3 Aug 2005 18:38:36 +0200 (CEST) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: hackers@freebsd.org Message-ID: <20050803183010.X32344@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: gjournal public alpha release 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, 03 Aug 2005 16:39:04 -0000 Hi! I'm announcing the first public version of the gjournal GEOM class :) The code is here: http://ivoras.sharanet.org/gjournal.tgz, together with a README file (reproduced below). I'd like to hear as many testing and bug reports as possible :) ---- The README file: What is it ---------- It's a journaling layer in GEOM subsystem. The intention is to provide devices (on which maybe filesystems are hosted) with data journaling capabilities. This is my first geom class, and also my first significant piece of kernel programming, so there are bound to be errors from my inexperience. The code is tested though, and it shouldn't crumble too often. :) More information is available at: http://wikitest.freebsd.org/moin.cgi/gjournal What does it do --------------- gjournal connectes ("consumes") two devices - one is the "data device" that is the target for journaling, and the other is "journal device" on which data is journaled. For every write request, its data is written on the journal device, and after some time transferred to the data device. Why use it ---------- The principal benefit of this is that the writes to the journal device are done sequentially and are much faster than direct, scattered writes to the data device. Another benefit, not implemented yet, is that it can be used in a "delayed-commit" mode, aka "Copy-on-write", where the data is stored in journal but not automatically commited to data device. This allows for dangerous experimenting on the data (maybe filesystem, with fsck), and then deciding later whether to commit the changes to data device or discard them. What works in this version -------------------------- This is alpha version software. Don't use in production setup. * journaling with automatic commit * automatic recovery of the journal on crash I've tested it by hosting a filesystem on the journaled device and copying various files to and from, so it should work well at least for light loads without panicking the kernel when you look at it :) Notes ~~~~~ * Since each and every write request is recorded verbatim in the journal, together with some system data (overhead), the journal device should be big. Based on current preliminary testing, I'd recommend something like 500MB to 1GB. * Making the journal device a md(4) device backed by a file should work, but it's not tested and there could be problems with crash recovery. * Data and journal devices can be on different physical devices, for added speed. * There are some design oddities, like blocking all IO on the device while the entire journal is commited, that won't go away soon, but probably will in a later version. How to use it ------------- Here's an example, step-by-step: * Unpack the archive, chdir to resulting directory * `make` * Symlink resulting .ko file into /boot/kernel/ * `make so` * Symlink resulting .so file into /lib/geom/ * `./gjournal load` * `./gjournal label mydevice /dev/datadevice /dev/journaldevice` * Use resulting /dev/journaled/mydevice for testing * `./gjournal unload` Notes ~~~~~ * It's developed for 5.4-RELEASE but it should work on later versions. * You need full system sources present in the usual location (/usr/src) to build it. * You need kernel with INVARIANTS and INVARIANTS_SUPPORT to run it (or you can modify the Makefile not to define those) * This is alpha quality software. Do not use on production machines and/or data. * I'd like to hear as many reports of testing as possible. If it crashes, I'd appreciate receiving following data: - what you wanted to do - what you did (e.g. commands you executed) - the configuration of your devices (data and journal devices) - is it repeatable? - if it's repeatable, set kern.geom.journal.debug sysctl to 20, and send as much of the last part of the kernel log to me Benchmarks ---------- I did some quick preliminary (and thus non-scientific and non-conclusive) benchmarks, and the results are good: "tar x" = untarring of a (previously cached) tar archive containing /usr/src/sys tree "rm -rf" = doing rm -rf on the untarred tree "raw" = partition without gjournal "gj" = the same partition gjournal-ed on another parition on the same drive "SU" = softupdates "normal" and "sync" are mount methods for UFS (numbers are seconds) Type | tar x | rm -rf ---------------------------------- raw, sync | 25.0 | 8.5 raw, normal| 18.9 | 9.6 raw, SU | 17.9 | 0.6 gj, sync | 23.0 | 7.9 gj, normal | 11.9 | 8.2 These are results in the best case for gjournal, where there's no journal commit phase in the middle of benchmarking. Commit delay can be configured with kern.geom.journal.commit_delay sysctl (in seconds). Unfortunately, the best result (gj, normal) is not crash-resistent. Though the journalling appears to be sound, it seems that FFS/UFS in the "normal" mode (metadata synchronous, data asynchronous) doesn't keep the filesystem always consistent with the writes, so a crash does require fsck on the filesystem. It's maybe also true for "sync" mode only harder to provoke. I'd appreciate any help to explain or solve this, but at the current time it means that this setup (gjournal + UFS) is NOT viable as a replacement for journaling filesystem. Acknowledgments --------------- This work is sponsored by Google via Summer of Code project. Menthors are Poul-Henning Kamp and Pawel Jakub Dawidek . -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 17:26:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A781716A440 for ; Wed, 3 Aug 2005 17:26:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4996143D45 for ; Wed, 3 Aug 2005 17:26:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 03 Aug 2005 13:41:16 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, hselasky@c2i.net Date: Wed, 3 Aug 2005 13:21:31 -0400 User-Agent: KMail/1.8 References: <200508030023.04748.hselasky@c2i.net> In-Reply-To: <200508030023.04748.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508031321.32276.jhb@FreeBSD.org> Cc: Subject: Re: How to do proper locking 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, 03 Aug 2005 17:26:39 -0000 On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > Hi, > > I am looking for a safe way to access structures that can be freed. The > solution I am looking for must not: > > - hinder scaleability > - lead to use of a single lock > - lead to lock order reversal These aren't a very clear set of requirements. Note that you can't hold a lock across malloc(), so your allocation code isn't safe. You can try taking at look at some existing refcounted structures such as ucreds, p_args, etc. or looking at structures held in a global list like proc. What actual problem are you trying to solve? How does code obtain references to my_struct objects? Are they hung off another object that has a lock? Are they in a global list? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 18:06:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51B9416A41F for ; Wed, 3 Aug 2005 18:06:33 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AF843D48 for ; Wed, 3 Aug 2005 18:06:32 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j739PQ6Y017902; Wed, 3 Aug 2005 02:25:40 -0700 (PDT) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j72Asagw007432; Tue, 2 Aug 2005 03:54:36 -0700 (PDT) (envelope-from www) Date: Tue, 2 Aug 2005 03:54:36 -0700 (PDT) Message-Id: <200508021054.j72Asagw007432@marlena.vvi.at> To: andy@triera.net From: "ALeine" Cc: freebsd-hackers@freebsd.org Subject: Re: Sound problem 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, 03 Aug 2005 18:06:33 -0000 andy@triera.net wrote: > I am using FreeBSD 5.4. I have installed sound modules from > kernel and everything work OK. But then I installed mplayer and > when I play movie sound is weird. I know how actors should sound > and they don't sound as they should. If I play same file under Win, > then the sound is ok. Has anybody same problem, and where could > problem lay? You may want to set the kernel variable hw.snd.pcm0.vchans to 0 and tune other hw.snd.* variables with sysctl(8). In the future you may want to include more details (like the output of `cat /dev/sndstat`) and consider posting to a more appropriate list (such as freebsd-questions) first. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 18:06:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5855216A420 for ; Wed, 3 Aug 2005 18:06:33 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id A899043D46 for ; Wed, 3 Aug 2005 18:06:32 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j739PQ7C017900; Wed, 3 Aug 2005 02:25:40 -0700 (PDT) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j72B39tv007542; Tue, 2 Aug 2005 04:03:09 -0700 (PDT) (envelope-from www) Date: Tue, 2 Aug 2005 04:03:09 -0700 (PDT) Message-Id: <200508021103.j72B39tv007542@marlena.vvi.at> To: andy@triera.net From: "ALeine" Cc: freebsd-hackers@freebsd.org Subject: Re: Sound problem 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, 03 Aug 2005 18:06:33 -0000 andy@triera.net wrote: > I am using FreeBSD 5.4. I have installed sound modules from > kernel and everything work OK. But then I installed mplayer > and when I play movie sound is weird. I know how actors should > sound and they don't sound as they should. If I play same file > under Win, then the sound is ok. Has anybody same problem, and > where could problem lay? You may want to set the kernel variable hw.snd.pcm0.vchans to 0 and tune other hw.snd.* kernel variables with sysctl(8). In the future you may also want to include more details (like the output of `cat /dev/sndstat`) and consider posting to a more appropriate list (like freebsd-questions) first. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 00:59:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BA6D16A41F for ; Thu, 4 Aug 2005 00:59:19 +0000 (GMT) (envelope-from aentgood@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB8E143D46 for ; Thu, 4 Aug 2005 00:59:18 +0000 (GMT) (envelope-from aentgood@gmail.com) Received: by wproxy.gmail.com with SMTP id i22so298104wra for ; Wed, 03 Aug 2005 17:59:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=uTwca/hrcr1IvbjUTb+Ksk9lzXvzrvKKVPdjWsxTJQOrt9z9qAlFqSG1tslQIFsxUPK2TKKIWA3zLNDOje597Djry/Qpm7yRj8FT4Ilc1GuH44uDmy11eOhOILJTsMQRjc5e1sm7P02Q5dXyDDCdwB5XZrv5mIpin8nD01y0n8U= Received: by 10.54.36.43 with SMTP id j43mr1049802wrj; Wed, 03 Aug 2005 17:59:18 -0700 (PDT) Received: by 10.54.69.15 with HTTP; Wed, 3 Aug 2005 17:59:18 -0700 (PDT) Message-ID: <7603e5d805080317593a046eec@mail.gmail.com> Date: Thu, 4 Aug 2005 00:59:18 +0000 From: Wouter van Rooij To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: perl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wouter van Rooij List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 00:59:19 -0000 Hello, At the first place, sorry for my bad English. My question is:=20 How can you, when you're writing a perl program, make a input () hidden, so that when someone is typing an input in the following program is hidden: #!/usr/bin/perl print "Your name:"; $name =3D I would like to get the input like this: ******** Thank you, Wouter van Rooij From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 01:53:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCDDD16A41F for ; Thu, 4 Aug 2005 01:53:06 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BBAD43D45 for ; Thu, 4 Aug 2005 01:53:03 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au (ppp217-188.lns1.adl2.internode.on.net [203.122.217.188]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j741r0Z1027845; Thu, 4 Aug 2005 11:23:01 +0930 (CST) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by midget.dons.net.au (8.13.4/8.13.3) with ESMTP id j741qrAI075041 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 4 Aug 2005 11:23:00 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org, Wouter van Rooij Date: Thu, 4 Aug 2005 11:22:43 +0930 User-Agent: KMail/1.8.1 References: <7603e5d805080317593a046eec@mail.gmail.com> In-Reply-To: <7603e5d805080317593a046eec@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11949180.DWzjXIB0Op"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508041122.50087.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 203.122.217.188 Cc: Subject: Re: perl 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, 04 Aug 2005 01:53:07 -0000 --nextPart11949180.DWzjXIB0Op Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 04 August 2005 10:29, Wouter van Rooij wrote: > My question is: > How can you, when you're writing a perl program, make a input > () hidden, so that when someone is typing an input in the > following program is hidden: > #!/usr/bin/perl > print "Your name:"; > $name =3D > I would like to get the input like this: ******** This is a Perl question, not a FreeBSD one.. You might want to look up stty and -echo.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart11949180.DWzjXIB0Op Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC8XTx5ZPcIHs/zowRAm0HAKCpTG8WCalKOAg2ZY94O8ISiHnU0ACgqx8w FVqSmrsXz1DkHxOZSQsSTIQ= =taGw -----END PGP SIGNATURE----- --nextPart11949180.DWzjXIB0Op-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 04:36:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54FAC16A41F for ; Thu, 4 Aug 2005 04:36:28 +0000 (GMT) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id C734343D45 for ; Thu, 4 Aug 2005 04:36:25 +0000 (GMT) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.13.3/8.13.3) with ESMTP id j744aOGs025836; Wed, 3 Aug 2005 22:36:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.13.3/8.13.3/Submit) with ESMTP id j744aOhu025833; Wed, 3 Aug 2005 22:36:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 3 Aug 2005 22:36:24 -0600 (MDT) From: Warren Block To: Wouter van Rooij In-Reply-To: <7603e5d805080317593a046eec@mail.gmail.com> Message-ID: <20050803223527.N25657@wonkity.com> References: <7603e5d805080317593a046eec@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (wonkity.com [127.0.0.1]); Wed, 03 Aug 2005 22:36:24 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: perl 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, 04 Aug 2005 04:36:28 -0000 On Thu, 4 Aug 2005, Wouter van Rooij wrote: > At the first place, sorry for my bad English. > My question is: > How can you, when you're writing a perl program, make a input > () hidden, so that when someone is typing an input in the > following program is hidden: > #!/usr/bin/perl > print "Your name:"; > $name = > I would like to get the input like this: ******** man -P 'less +/password' perlfaq8 -Warren Block * Rapid City, South Dakota USA From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 07:21:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED29F16A41F for ; Thu, 4 Aug 2005 07:21:37 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from ariel.yandex.ru (ariel.yandex.ru [213.180.200.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9276D43D45 for ; Thu, 4 Aug 2005 07:21:37 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from YAMAIL (ariel.yandex.ru) by mail.yandex.ru id ; Thu, 4 Aug 2005 11:21:29 +0400 Date: Thu, 4 Aug 2005 11:21:29 +0400 (MSD) From: "Felix-KM" Sender: Felix-KM@yandex.ru Message-Id: <42F1C1F9.000001.17496@ariel.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: Felix-KM@yandex.ru To: freebsd-hackers@freebsd.org X-Source-Ip: 82.179.191.126 X-Originating-Ip: unknown Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: (no subject) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felix-KM@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 07:21:38 -0000 Hello. Help me please to understand how the function bus_teardown_intr() works. I have a device driver containing following code: #define DEVICE2SOFTC(device) ((struct dev_softc *)device_get_softc(device)) static void dev_intr(void *arg); struct dev_softc { ... int rid_irq; struct resource* res_irq; void *intr_cookie; ... }; static int dev_attach(device_t device) { ... dev_sc->rid_irq = 0; dev_sc->res_irq = bus_alloc_resource_any(device, SYS_RES_IRQ, &(dev_sc->rid_irq), RF_SHAREABLE|RF_ACTIVE); if (dev_sc->res_irq == NULL) { uprintf("!!! Could not map interrupt !!!\n"); goto fail; } if (bus_setup_intr(device, dev_sc->res_irq, INTR_TYPE_TTY, dev_intr, dev_sc, &dev_sc->intr_cookie)) { uprintf("!!! Could not setup irq !!!\n"); goto fail; } ... fail: return ENXIO; } static int dev_detach(device_t device) { struct dev_softc *dev_sc = DEVICE2SOFTC(device); destroy_dev(dev_sc->device); if (bus_teardown_intr(device, dev_sc->res_irq, dev_sc->intr_cookie) != 0); printf("bus_teardown_intr ERROR !!!\n"); bus_release_resource(device, SYS_RES_IRQ, dev_sc->rid_irq, dev_sc->res_irq); ... return 0; } static void dev_intr(void *arg) { struct dev_softc *dev_sc = (struct dev_softc *)arg; ... } When the driver is loaded the following message is shown: dev0 port 0x9800-0x980f,0x9400-0x947f irq 16 at device 10.0 on pci1 i.e., as I understand, resourses are allocated normally. But when the driver is being unloaded the following message appear: bus_teardown_intr ERROR !!! What have I done wrong? Hint me please how to use bus_teardown_intr() function correctly? From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 07:29:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91C5416A41F for ; Thu, 4 Aug 2005 07:29:09 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from mfront7.yandex.ru (mfront7.yandex.ru [213.180.200.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE56943D45 for ; Thu, 4 Aug 2005 07:29:08 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from YAMAIL (mfront7.yandex.ru) by mail.yandex.ru id ; Thu, 4 Aug 2005 11:28:46 +0400 Date: Thu, 4 Aug 2005 11:28:46 +0400 (MSD) From: "Felix-KM" Sender: Felix-KM@yandex.ru Message-Id: <42F1C3AE.000003.07372@mfront7.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: Felix-KM@yandex.ru To: freebsd-hackers@freebsd.org In-Reply-To: <42F1C1F9.000001.17496@ariel.yandex.ru> References: <42F1C1F9.000001.17496@ariel.yandex.ru> X-Source-Ip: 82.179.191.126 X-Originating-Ip: unknown Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 8bit Subject: bus_teardown_intr() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felix-KM@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 07:29:09 -0000 Sorry, I forgot to indicate the theme. >Hello. >Help me please to understand how the function bus_teardown_intr() works. >I have a device driver containing following code: > >#define DEVICE2SOFTC(device) ((struct dev_softc *)device_get_softc(device)) > >static void dev_intr(void *arg); > >struct dev_softc { > ... > int rid_irq; > struct resource* res_irq; > void *intr_cookie; > ... >}; > >static int >dev_attach(device_t device) >{ > ... > > dev_sc->rid_irq = 0; > dev_sc->res_irq = bus_alloc_resource_any(device, SYS_RES_IRQ, > &(dev_sc->rid_irq), RF_SHAREABLE|RF_ACTIVE); > if (dev_sc->res_irq == NULL) > { > uprintf("!!! Could not map interrupt !!!\n"); > goto fail; > } > > if (bus_setup_intr(device, dev_sc->res_irq, INTR_TYPE_TTY, > dev_intr, dev_sc, &dev_sc->intr_cookie)) > { > uprintf("!!! Could not setup irq !!!\n"); > goto fail; > } > > ... > >fail: > return ENXIO; >} > >static int >dev_detach(device_t device) >{ > struct dev_softc *dev_sc = DEVICE2SOFTC(device); > > destroy_dev(dev_sc->device); > > if (bus_teardown_intr(device, dev_sc->res_irq, dev_sc->intr_cookie) != 0); > printf("bus_teardown_intr ERROR !!!\n"); > > bus_release_resource(device, SYS_RES_IRQ, dev_sc->rid_irq, > dev_sc->res_irq); > ... > > return 0; >} > >static void >dev_intr(void *arg) >{ > struct dev_softc *dev_sc = (struct dev_softc *)arg; > > ... >} > >When the driver is loaded the following message is shown: > >dev0 port 0x9800-0x980f,0x9400-0x947f irq 16 at device 10.0 on pci1 > >i.e., as I understand, resourses are allocated normally. > >But when the driver is being unloaded the following message appear: > >bus_teardown_intr ERROR !!! > >What have I done wrong? Hint me please how to use bus_teardown_intr() >function correctly? >_______________________________________________ >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" -- ñÎÄÅËÓ.ìÅÎÔÁ - ÌÀÂÉÍÙÅ ÂÌÏÇÉ É ÎÏ×ÏÓÔÉ ÎÁ ÏÄÎÏÍ ÓÁÊÔÅ http://lenta.yandex.ru/ From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 07:51:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2261D16A41F for ; Thu, 4 Aug 2005 07:51:57 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB9443D46 for ; Thu, 4 Aug 2005 07:51:56 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 2FE4A8D722; Thu, 4 Aug 2005 09:51:51 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17512-05; Thu, 4 Aug 2005 09:51:46 +0200 (CEST) Received: from firewall.demig (p5083A50A.dip0.t-ipconnect.de [80.131.165.10]) by server.absolute-media.de (Postfix) with ESMTP id 449628DF2E; Thu, 4 Aug 2005 09:51:46 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j747mOGl051496; Thu, 4 Aug 2005 09:48:24 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: , Date: Thu, 4 Aug 2005 09:48:23 +0200 Message-ID: <000001c598c8$e4045ee0$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <42F1C1F9.000001.17496@ariel.yandex.ru> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: Subject: RE: (no subject) 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, 04 Aug 2005 07:51:57 -0000 > #define DEVICE2SOFTC(device) ((struct dev_softc > *)device_get_softc(device)) > > static void dev_intr(void *arg); > > struct dev_softc { > ... > int rid_irq; > struct resource* res_irq; > void *intr_cookie; > ... > }; > > static int > dev_attach(device_t device) > { > ... > > dev_sc->rid_irq = 0; > dev_sc->res_irq = bus_alloc_resource_any(device, SYS_RES_IRQ, > &(dev_sc->rid_irq), > RF_SHAREABLE|RF_ACTIVE); > if (dev_sc->res_irq == NULL) > { > uprintf("!!! Could not map interrupt !!!\n"); > goto fail; > } > > if (bus_setup_intr(device, dev_sc->res_irq, INTR_TYPE_TTY, > dev_intr, dev_sc, &dev_sc->intr_cookie)) > { > uprintf("!!! Could not setup irq !!!\n"); > goto fail; > } > > ... > > fail: > return ENXIO; > } > > static int > dev_detach(device_t device) > { > struct dev_softc *dev_sc = DEVICE2SOFTC(device); > > destroy_dev(dev_sc->device); > > if (bus_teardown_intr(device, dev_sc->res_irq, > dev_sc->intr_cookie) != 0); !!!! Do you see that semicolon? !!!! Norbert > printf("bus_teardown_intr ERROR !!!\n"); > > bus_release_resource(device, SYS_RES_IRQ, dev_sc->rid_irq, > > dev_sc->res_irq); > ... > > return 0; > } > > static void > dev_intr(void *arg) > { > struct dev_softc *dev_sc = (struct dev_softc *)arg; > > ... > } > > When the driver is loaded the following message is shown: > > dev0 port 0x9800-0x980f,0x9400-0x947f irq 16 at device 10.0 on pci1 > > i.e., as I understand, resourses are allocated normally. > > But when the driver is being unloaded the following message appear: > > bus_teardown_intr ERROR !!! > > What have I done wrong? Hint me please how to use bus_teardown_intr() > function correctly? > _______________________________________________ > 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 Thu Aug 4 10:18:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5378A16A41F for ; Thu, 4 Aug 2005 10:18:54 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from mfront8.yandex.ru (mfront8.yandex.ru [213.180.200.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB8F643D45 for ; Thu, 4 Aug 2005 10:18:53 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from YAMAIL (mfront8.yandex.ru) by mail.yandex.ru id ; Thu, 4 Aug 2005 14:18:33 +0400 Date: Thu, 4 Aug 2005 14:18:33 +0400 (MSD) From: "Felix-KM" Sender: Felix-KM@yandex.ru Message-Id: <42F1EB79.000002.18984@mfront8.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: Felix-KM@yandex.ru To: NKoch@demig.de In-Reply-To: <000001c598c8$e4045ee0$4801a8c0@ws-ew-3.W2KDEMIG> References: <000001c598c8$e4045ee0$4801a8c0@ws-ew-3.W2KDEMIG> X-Source-Ip: 82.179.191.126 X-Originating-Ip: unknown Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: RE: (no subject) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felix-KM@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 10:18:54 -0000 >> #define DEVICE2SOFTC(device) ((struct dev_softc >> *)device_get_softc(device)) >> >> static void dev_intr(void *arg); >> >> struct dev_softc { >> ... >> int rid_irq; >> struct resource* res_irq; >> void *intr_cookie; >> ... >> }; >> >> static int >> dev_attach(device_t device) >> { >> ... >> >> dev_sc->rid_irq = 0; >> dev_sc->res_irq = bus_alloc_resource_any(device, SYS_RES_IRQ, >> &(dev_sc->rid_irq), >> RF_SHAREABLE|RF_ACTIVE); >> if (dev_sc->res_irq == NULL) >> { >> uprintf("!!! Could not map interrupt !!!\n"); >> goto fail; >> } >> >> if (bus_setup_intr(device, dev_sc->res_irq, INTR_TYPE_TTY, >> dev_intr, dev_sc, &dev_sc->intr_cookie)) >> { >> uprintf("!!! Could not setup irq !!!\n"); >> goto fail; >> } >> >> ... >> >> fail: >> return ENXIO; >> } >> >> static int >> dev_detach(device_t device) >> { >> struct dev_softc *dev_sc = DEVICE2SOFTC(device); >> >> destroy_dev(dev_sc->device); >> >> if (bus_teardown_intr(device, dev_sc->res_irq, >> dev_sc->intr_cookie) != 0); > >!!!! Do you see that semicolon? !!!! > > >Norbert > > Oops... I am ashamed for my inattention... Thank you very much... From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 11:40:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6E3B16A41F; Thu, 4 Aug 2005 11:40:03 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFE8943D45; Thu, 4 Aug 2005 11:40:02 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-217-207-214.daxnet.no ([193.217.207.214] verified) by mailfe09.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 224678406; Thu, 04 Aug 2005 13:39:59 +0200 From: Hans Petter Selasky To: John Baldwin Date: Thu, 4 Aug 2005 13:40:57 +0200 User-Agent: KMail/1.7 References: <200508030023.04748.hselasky@c2i.net> <200508031321.32276.jhb@FreeBSD.org> In-Reply-To: <200508031321.32276.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200508041340.58851.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 11:40:04 -0000 On Wednesday 03 August 2005 19:21, John Baldwin wrote: > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > Hi, > > > > I am looking for a safe way to access structures that can be freed. The > > solution I am looking for must not: > > > > - hinder scaleability > > - lead to use of a single lock > > - lead to lock order reversal There is one more thing. When the structure is freed it should not block waiting for any reference counts. > > These aren't a very clear set of requirements. If you think about the situation of accessing a structure in parallell with freeing it, and want to do it 100 percent safe, you will see that you have to do some kind of test before accessing this structure to see if it is still present. So how should this test look like if you want to keep the points I've listed above in mind? > Note that you can't hold a > lock across malloc(), so your allocation code isn't safe. I was thinking that the M_NOWAIT flag was passed malloc(). Else in this case, I think it is safe to unlock/lock "lock_A" when malloc is called. > You can try taking at look at some existing refcounted structures such > as ucreds, p_args, etc. or looking at structures held in a global list > like proc. It looks to me like some parent lock is held, or that these structures are only accessed from a single thread, to prevent synchronization problems. This is a copy and paste from the kernel sources: struct ucred * crhold(struct ucred *cr) { The problem is, what happens if the kernel switches thread right here, and then the other thread calls "crfree()" on this structure, that will "free()" memory pointed to by "cr". Then the first line of code below will access freed memory, and then we are going for a segment fault or worse. mtx_lock(cr->cr_mtxp); cr->cr_ref++; mtx_unlock(cr->cr_mtxp); return (cr); } So this is what I want this routine and alike to look like: struct cr_callback_args { struct ucred *cr; struct mtx *p_mtx; u_int32_t refcount_copy, u_int32_t *p_refcount; }; struct ucred * crhold(struct cr_ballback_args *args) { mtx_lock(args->p_mtx); if(args->refcount_copy == ref_atomic_read(args->p_refcount)) { /* the structure pointed to by "args->cr" is still valid */ /* maybe we don't need the refcount below, but instead * can return with this structure locked, hence the * reference count will be incremented before * "args->cr" is freed, and after that the test * above will fail. */ args->cr->cr_ref++; } mtx_lock(args->p_mtx); return (args->cr); } > What actual problem are you trying to solve? Generic callbacks: - setting up timers. Make sure that callback is never called after that timer has been stopped. - setting up devices. Make sure that read/write/ioctl/poll callbacks are never called after that the device has been freed. - setting up interrupts. Make sure that interrupt routine is never called after that it is been teared down. And more. There are lots of situations in the kernel that run into the same scheme, without a proper solution. In my initial suggestion, I suggested that there be a "ref_atomic_increment()" routine, but I think it is better without. Then every time one needs to increment the refcount, one has to go through a ref_free/ref_alloc loop. The idea is that "ref_free()" will detect when the refcount is equal to (u_int32_t)(-1) and put the refount on a trash list. Then ideally one never recycles "used up" refcounts. > How does code obtain references to my_struct objects? For example when you set up a timer, you pass the pointer to the structure that the callback is going to access. struct my_struct *sc = ...; callout_reset(&callback, 1*hz, &my_callback, sc); > Are they hung off another object that has > a lock? Usually, but the "parent" lock cannot help much. > Are they in a global list? Yes and no. Sometimes these structures have roots in structures that are freed too, in the same manner, but at the bottom there is a static and global list. Was this what you meant? -- HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 12:08:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B300B16A41F; Thu, 4 Aug 2005 12:08:33 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24AE343D45; Thu, 4 Aug 2005 12:08:33 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3F182.dip.t-dialin.net [84.163.241.130] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1E0eWU2RQS-0008CH; Thu, 04 Aug 2005 14:08:30 +0200 From: Max Laier To: freebsd-hackers@freebsd.org, hselasky@c2i.net Date: Thu, 4 Aug 2005 14:08:14 +0200 User-Agent: KMail/1.8 References: <200508030023.04748.hselasky@c2i.net> <200508031321.32276.jhb@FreeBSD.org> <200508041340.58851.hselasky@c2i.net> In-Reply-To: <200508041340.58851.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6576948.aXnCKbuJDp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508041408.22226.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: How to do proper locking 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, 04 Aug 2005 12:08:33 -0000 --nextPart6576948.aXnCKbuJDp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 04 August 2005 13:40, Hans Petter Selasky wrote: > This is a copy and paste from the kernel sources: > > struct ucred * > crhold(struct ucred *cr) > { > The problem is, what happens if the kernel switches thread right here, and > then the other thread calls "crfree()" on this structure, that will > "free()" memory pointed to by "cr". Then the first line of code below will > access freed memory, and then we are going for a segment fault or worse. > > mtx_lock(cr->cr_mtxp); > cr->cr_ref++; > mtx_unlock(cr->cr_mtxp); > return (cr); > } It seems that you are misunderstanding the concept of reference counting. = The=20 idea is to have a reference as long as you are handing around the object. = In=20 order to call crhold() you must already hold a reference to the credential.= =20 This will prevent the credential structure to vanish and allow you to pass= =20 the credential to another consumer that now can assume to hold a reference = of=20 it's own. If you can access your objects from a external list, you have to hold a glo= bal=20 lock that protects: 1) Sanity of the list 2) Free operations to the member objects If you access the objects via the list/tree/whatsoever "most of the time" -= =20 refcounting isn't for you. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart6576948.aXnCKbuJDp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC8gU2XyyEoT62BG0RArv0AKCBQaMH99vb7IL5aIvbd/7Sj7UvJgCfZHzs jY5t4ZoLCl602BUTeBbg+Z4= =xfxh -----END PGP SIGNATURE----- --nextPart6576948.aXnCKbuJDp-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 3 14:03:37 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC51616A420; Wed, 3 Aug 2005 14:03:37 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96EF243D60; Wed, 3 Aug 2005 14:03:31 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50] (may be forged)) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j73DtfPD004134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2005 15:55:42 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42F0CCD5.9090200@portaone.com> Date: Wed, 03 Aug 2005 16:55:33 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.2/1002/Wed Aug 3 12:29:36 2005 on www.portaone.com X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=ham version=3.0.0 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on www.portaone.com X-Mailman-Approved-At: Thu, 04 Aug 2005 12:22:30 +0000 Cc: Subject: Sub-optimal libc's read-ahead buffering behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 14:03:37 -0000 Hi, I have found the scenario in which our libc behaves utterly suboptimally. Consider the following piece of code reads and processes every other 512-bytes block in a file (error handling intentionally omitted): FILE *f; int i; char buf[512]; f = fopen(...); for (i = 0; feof(f) == 0; i++) { fread(buf, sizeof(buf), 1, f); do_process(buf); fseek(f, i * 2 * sizeof(buf), SEEK_SET); } What I have discovered in this case is that libc reads 4096 bytes from the file for *each* fread(3) call, despite the fact that it can only do one actual read(2) for every fourth fread(3) and satisfy the rest from the internal buffer (4096 bytes). However, if I replace fseek(3) with just another dummy fread(3) everything works as expected - libc does only one read for every 8 fread(3) calls (4 dummy and 4 real). Is it something which should be fixed or are there some subtle reasons for the current behaviour? Following is piece of code which illustrates the problem: #include #include int main(int argc, char **argv) { FILE *f; int i; char buf[512]; f = fopen("/dev/zero", "r"); for (i = 0; i < 16; i++) { fread(buf, sizeof(buf), 1, f); if (argc == 1) fread(buf, sizeof(buf), 1, f); else fseek(f, i * 2 * sizeof(buf), SEEK_SET); } exit(0); } When run with zero arguments relevant truss output looks like: open("/dev/zero",0x0,0666) = 3 (0x3) fstat(3,0xbfbfe900) = 0 (0x0) readlink("/etc/malloc.conf",0xbfbfe8c0,63) ERR#2 'No such file or directory' issetugid() = 0 (0x0) mmap(0x0,4096,(0x3)PROT_READ|PROT_WRITE,(0x1002)MAP_ANON|MAP_PRIVATE,-1,0x0) = 1209335808 (0x48150000) break(0x804b000) = 0 (0x0) break(0x804c000) = 0 (0x0) ioctl(3,TIOCGETA,0xbfbfe940) ERR#19 'Operation not supported by device' read(0x3,0x804b000,0x1000) = 4096 (0x1000) read(0x3,0x804b000,0x1000) = 4096 (0x1000) read(0x3,0x804b000,0x1000) = 4096 (0x1000) read(0x3,0x804b000,0x1000) = 4096 (0x1000) exit(0x0) While when I am specifying some argument it becomes: open("/dev/zero",0x0,0666) = 3 (0x3) fstat(3,0xbfbfe900) = 0 (0x0) readlink("/etc/malloc.conf",0xbfbfe8c0,63) ERR#2 'No such file or directory' issetugid() = 0 (0x0) mmap(0x0,4096,(0x3)PROT_READ|PROT_WRITE,(0x1002)MAP_ANON|MAP_PRIVATE,-1,0x0) = 1209335808 (0x48150000) break(0x804b000) = 0 (0x0) break(0x804c000) = 0 (0x0) ioctl(3,TIOCGETA,0xbfbfe940) ERR#19 'Operation not supported by device' read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x0,SEEK_SET) = 0 (0x0) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x400,SEEK_SET) = 1024 (0x400) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x800,SEEK_SET) = 2048 (0x800) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0xc00,SEEK_SET) = 3072 (0xc00) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x1000,SEEK_SET) = 4096 (0x1000) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x1400,SEEK_SET) = 5120 (0x1400) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x1800,SEEK_SET) = 6144 (0x1800) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x1c00,SEEK_SET) = 7168 (0x1c00) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x2000,SEEK_SET) = 8192 (0x2000) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x2400,SEEK_SET) = 9216 (0x2400) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x2800,SEEK_SET) = 10240 (0x2800) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x2c00,SEEK_SET) = 11264 (0x2c00) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x3000,SEEK_SET) = 12288 (0x3000) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x3400,SEEK_SET) = 13312 (0x3400) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x3800,SEEK_SET) = 14336 (0x3800) read(0x3,0x804b000,0x1000) = 4096 (0x1000) lseek(3,0x3c00,SEEK_SET) = 15360 (0x3c00) exit(0x0) The output speaks for itself (32 syscalls instead of 4)! -Maxim From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 14:25:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29E0E16A473 for ; Thu, 4 Aug 2005 14:25:30 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3E2543D45 for ; Thu, 4 Aug 2005 14:25:29 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 04 Aug 2005 10:40:03 -0400 From: John Baldwin To: hselasky@c2i.net Date: Thu, 4 Aug 2005 09:53:58 -0400 User-Agent: KMail/1.8 References: <200508030023.04748.hselasky@c2i.net> <200508031321.32276.jhb@FreeBSD.org> <200508041340.58851.hselasky@c2i.net> In-Reply-To: <200508041340.58851.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508040953.59316.jhb@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking 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, 04 Aug 2005 14:25:30 -0000 On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote: > On Wednesday 03 August 2005 19:21, John Baldwin wrote: > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > > Hi, > > > > > > I am looking for a safe way to access structures that can be freed. The > > > solution I am looking for must not: > > > > > > - hinder scaleability > > > - lead to use of a single lock > > > - lead to lock order reversal > > There is one more thing. When the structure is freed it should not block > waiting for any reference counts. > > > These aren't a very clear set of requirements. > > If you think about the situation of accessing a structure in parallell with > freeing it, and want to do it 100 percent safe, you will see that you have > to do some kind of test before accessing this structure to see if it is > still present. So how should this test look like if you want to keep the > points I've listed above in mind? > > > Note that you can't hold a > > lock across malloc(), so your allocation code isn't safe. > > I was thinking that the M_NOWAIT flag was passed malloc(). Else in this > case, I think it is safe to unlock/lock "lock_A" when malloc is called. > > > You can try taking at look at some existing refcounted structures such > > as ucreds, p_args, etc. or looking at structures held in a global list > > like proc. > > It looks to me like some parent lock is held, or that these structures are > only accessed from a single thread, to prevent synchronization problems. You hold a parent lock (which is what your lock_A is if you think about it) while you bump the reference count, yes. > This is a copy and paste from the kernel sources: > > struct ucred * > crhold(struct ucred *cr) > { > The problem is, what happens if the kernel switches thread right here, and > then the other thread calls "crfree()" on this structure, that will > "free()" memory pointed to by "cr". Then the first line of code below will > access freed memory, and then we are going for a segment fault or worse. > > mtx_lock(cr->cr_mtxp); > cr->cr_ref++; > mtx_unlock(cr->cr_mtxp); > return (cr); > } crhold() is always called when the caller knows that it has a reference to cr that can't go away. Thus, in the case of p_ucred, one holds the associated PROC_LOCK() while doing crhold(). After the crhold() you can drop the proc lock, so that lock is only held for a very short period of time. You then have your own reference to the cred structure that is valid until you call crfree(). In the case of curthread->td_ucred, the reference is valid until curthread releases it on a cred update at the start of a syscall, so your reference is valid without needing locks for the life of a syscall. The key here is that you solve this problem at a higher level, not within the structure itself. > > What actual problem are you trying to solve? > > Generic callbacks: > > - setting up timers. Make sure that callback is never called after that > timer has been stopped. See callout_stop() and callout_drain(). callout_drain() won't return until the callout has both been stopped and has finished executing if it was already in progress. > - setting up devices. Make sure that read/write/ioctl/poll callbacks are > never called after that the device has been freed. This is managed with refcounts on the dev_t object by devfs. Once you call destroy_dev() devfs manages the rest. > - setting up interrupts. Make sure that interrupt routine is never called > after that it is been teared down. bus_teardown_intr() already does this. > And more. There are lots of situations in the kernel that run into the same > scheme, without a proper solution. Are there any other places you can think of that don't handle this already? The approach FreeBSD's kernel has taken is to solve this problem by duplicating a lot of checks all over the place for each data structure, but to solve it in the primitives themselves instead (hence callout_drain(), bus_teardown_intr(), destroy_dev(), etc.) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 16:49:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18B6E16A41F; Thu, 4 Aug 2005 16:49:13 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.tele2.se [212.247.155.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 523CF43D53; Thu, 4 Aug 2005 16:49:11 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-216-44-27.daxnet.no ([193.216.44.27] verified) by mailfe10.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 232054857; Thu, 04 Aug 2005 18:49:08 +0200 From: Hans Petter Selasky To: Max Laier Date: Thu, 4 Aug 2005 18:50:04 +0200 User-Agent: KMail/1.7 References: <200508030023.04748.hselasky@c2i.net> <200508041340.58851.hselasky@c2i.net> <200508041408.22226.max@love2party.net> In-Reply-To: <200508041408.22226.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508041850.06607.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 16:49:13 -0000 On Thursday 04 August 2005 14:08, Max Laier wrote: > On Thursday 04 August 2005 13:40, Hans Petter Selasky wrote: > > This is a copy and paste from the kernel sources: > > > > struct ucred * > > crhold(struct ucred *cr) > > { > > The problem is, what happens if the kernel switches thread right here, > > and then the other thread calls "crfree()" on this structure, that will > > "free()" memory pointed to by "cr". Then the first line of code below > > will access freed memory, and then we are going for a segment fault or > > worse. > > > > mtx_lock(cr->cr_mtxp); > > cr->cr_ref++; > > mtx_unlock(cr->cr_mtxp); > > return (cr); > > } > > It seems that you are misunderstanding the concept of reference counting. > The idea is to have a reference as long as you are handing around the > object. In order to call crhold() you must already hold a reference to the > credential. This will prevent the credential structure to vanish and allow > you to pass the credential to another consumer that now can assume to hold > a reference of it's own. Maybe "crhold()" is not exactly what I am after. From what I can see, we are speaking about two different refcount systems: - crhold()/crfree() is incrementing/decrementing the refcount to indicate the total number of references hold. - I am only incrementing the refcount at object destruction, to make sure that the last refcount value cannot be used again, to get access to the object. > > If you can access your objects from a external list, you have to hold a > global lock that protects: > 1) Sanity of the list > 2) Free operations to the member objects Yes, that is what I am doing, but there is a problem. Here is another pseudo-code example on what I'm trying to get a solution for: struct mtx global; struct my_object { struct mtx *mtx; u_int8_t some_data[256]; struct my_object *next; } *m; /* Here is the enforced locking order, which * makes most sense to me: * * 1. m->mtx * 2. global */ void() thread_1() { struct my_object *m; sleep(&global); lock(global); /* * to access this object * we dequeue it from a * one-way linked list: */ m = dequeue_object(); mtx = m->mtx; unlock(global); wakeup(m); sleep(m); /* What makes this so special is that * the object pointed to by "m" is owned * by "thread_2". When that thread * exits the object is gone. * * A big problem is that one cannot * hold any lock right here, to * block "thread_2" from freeing the * object, due to the enforced locking * order. Switching locking order * does not change anything. */ lock(mtx); /* When the CPU gets here a check * is neccesary to ensure that the * other thread has not freed the * object pointed to by "m". */ if(refcount_copy == some_atomic_read) { /* object is still here */ } unlock(mtx); return; } void thread_2() { struct my_object *m; m = malloc(sizeof(*m)); if(m == NULL) return; m->mtx = mtx_alloc(); lock(global); enqueue_object(m); unlock(global); wakeup(&global); sleep(m); lock(global); remove_object_from_list_if_present(m); unlock(global); lock(mtx); /* * XXX increase some refcount atomically * XXX even if we are locked */ unlock(mtx); free(m); wakeup(m); return; } > > If you access the objects via the list/tree/whatsoever "most of the time" - > refcounting isn't for you. > If you use a single lock, you don't need refcounting. But if you use two locks, like in this example, and you have more than one source of object destruction, refcounting is required. Do you see that more than one thread can be about to destroy the object at the same time? --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 16:49:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 813F416A42C; Thu, 4 Aug 2005 16:49:19 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B5A43D53; Thu, 4 Aug 2005 16:49:18 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-216-44-27.daxnet.no ([193.216.44.27] verified) by mailfe03.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 242237402; Thu, 04 Aug 2005 18:49:15 +0200 From: Hans Petter Selasky To: John Baldwin Date: Thu, 4 Aug 2005 18:50:12 +0200 User-Agent: KMail/1.7 References: <200508030023.04748.hselasky@c2i.net> <200508041340.58851.hselasky@c2i.net> <200508040953.59316.jhb@FreeBSD.org> In-Reply-To: <200508040953.59316.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508041850.14253.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 16:49:19 -0000 On Thursday 04 August 2005 15:53, John Baldwin wrote: > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote: > > On Wednesday 03 August 2005 19:21, John Baldwin wrote: > > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > > > Hi, > > > > > > > > I am looking for a safe way to access structures that can be freed. > > > > The solution I am looking for must not: > > > > > > > > - hinder scaleability > > > > - lead to use of a single lock > > > > - lead to lock order reversal > > > > There is one more thing. When the structure is freed it should not block > > waiting for any reference counts. > > > > crhold() is always called when the caller knows that it has a reference to > cr that can't go away. Thus, in the case of p_ucred, one holds the > associated PROC_LOCK() while doing crhold(). After the crhold() you can > drop the proc lock, so that lock is only held for a very short period of > time. You then have your own reference to the cred structure that is valid > until you call crfree(). In the case of curthread->td_ucred, the reference > is valid until curthread releases it on a cred update at the start of a > syscall, so your reference is valid without needing locks for the life of a > syscall. The key here is that you solve this problem at a higher level, > not within the structure itself. Yes, this works with mbufs, crhold() and alike, where one doesn't actually free the object until the refcount reaches zero. But I am speaking about destroying an object while the refcount is non-zero. Do you see the difference? There are two ways to handle this: 1) blocking: wait until the refcount reaches zero. 2) nonblocking: increment some other refcount that the callback checks before accessing any data. Do you agree that method 2 is going to: - avoid deadlock - avoid use of sx-locks, locks that allow calls to msleep(), to keep synchronization while destroying objects with refcounts. When calling functions like "callout_stop()", it is likely that one is holding a lock to prevent other code from calling "callout_start()" on the same callback before "callout_stop()" has been called. Now, if "callout_stop()" sleeps, the lock that is held while calling this function, must allow calls msleep(). So this must be an sx-lock (see "man sx"). Now if one routine sleeps, then any callers of this routine must sleep too. So this affects the synchronization of the whole system. Isn't nonblocking operation preferred over blocking operation? > > > > What actual problem are you trying to solve? > > > > Generic callbacks: > > > > - setting up timers. Make sure that callback is never called after that > > timer has been stopped. > > See callout_stop() and callout_drain(). callout_drain() won't return until > the callout has both been stopped and has finished executing if it was > already in progress. The callback can be called after that "callout_stop()" has been called! You can use _callout_stop_safe(), but the problem is that it will sleep, waiting for "the other thread" to finish. The solution I have described, makes this process non-blocking, which means that one can hold a lock while calling callout_stop() which must be an advantage. > > > - setting up devices. Make sure that read/write/ioctl/poll callbacks are > > never called after that the device has been freed. > > This is managed with refcounts on the dev_t object by devfs. Once you call > destroy_dev() devfs manages the rest. No, the callback functions read/write/ioctl/poll can be called after that "destroy_dev()" has been called. > > > - setting up interrupts. Make sure that interrupt routine is never called > > after that it is been teared down. > > bus_teardown_intr() already does this. I'm sure it is the same here. If the interrupt handler doesn't have its own lock then, I think the interrupt callback can be called after that "bus_teardown_intr()" has been called. > > > And more. There are lots of situations in the kernel that run into the > > same scheme, without a proper solution. > > Are there any other places you can think of that don't handle this already? I am thinking about all the device drivers that create devices in /dev/ that can be detache, and that really never checks anything before accessing the softc: int ulptread(struct cdev *dev, struct uio *uio, int flags) { struct ulpt_softc *sc; int error; USB_GET_SC(ulpt, ULPTUNIT(dev), sc); XXX XXX here can be an segmentation fault where sc == NULL XXX if (sc->sc_dying) return (EIO); sc->sc_refcnt++; error = ulpt_do_read(sc, uio, flags); if (--sc->sc_refcnt < 0) usb_detach_wakeup(USBDEV(sc->sc_dev)); return (error); } > The approach FreeBSD's kernel has taken is to solve this problem by > duplicating a lot of checks all over the place for each data structure, but > to solve it in the primitives themselves instead (hence callout_drain(), > bus_teardown_intr(), destroy_dev(), etc.) Yes, but why are the implementations based on blocking operation, hence this is not required? What I want is that the kernel provides some routine that can do locking based on a structure like below. Also the kernel must provide some routines to allocate, free and read a refcount. struct callback_args { void *sc; struct mtx *p_mtx; u_int32_t refcount_copy; u_int32_t *p_refcount; }; Then I want routines like "callout_reset()", "make_dev()", "bus_setup_intr()" and so on, to pass these four parameters to the callback function, either directly, or like a pointer to this structure. --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 18:17:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B66B716A41F for ; Thu, 4 Aug 2005 18:17:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 153D543D45 for ; Thu, 4 Aug 2005 18:17:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 04 Aug 2005 14:31:36 -0400 From: John Baldwin To: hselasky@c2i.net Date: Thu, 4 Aug 2005 14:15:55 -0400 User-Agent: KMail/1.8 References: <200508030023.04748.hselasky@c2i.net> <200508040953.59316.jhb@FreeBSD.org> <200508041850.14253.hselasky@c2i.net> In-Reply-To: <200508041850.14253.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508041415.56140.jhb@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking 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, 04 Aug 2005 18:17:02 -0000 On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote: > On Thursday 04 August 2005 15:53, John Baldwin wrote: > > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote: > > > On Wednesday 03 August 2005 19:21, John Baldwin wrote: > > > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > > > > Hi, > > > > > > > > > > I am looking for a safe way to access structures that can be freed. > > > > > The solution I am looking for must not: > > > > > > > > > > - hinder scaleability > > > > > - lead to use of a single lock > > > > > - lead to lock order reversal > > > > > > There is one more thing. When the structure is freed it should not > > > block waiting for any reference counts. > > > > crhold() is always called when the caller knows that it has a reference > > to cr that can't go away. Thus, in the case of p_ucred, one holds the > > associated PROC_LOCK() while doing crhold(). After the crhold() you can > > drop the proc lock, so that lock is only held for a very short period of > > time. You then have your own reference to the cred structure that is > > valid until you call crfree(). In the case of curthread->td_ucred, the > > reference is valid until curthread releases it on a cred update at the > > start of a syscall, so your reference is valid without needing locks for > > the life of a syscall. The key here is that you solve this problem at a > > higher level, not within the structure itself. > > Yes, this works with mbufs, crhold() and alike, where one doesn't actually > free the object until the refcount reaches zero. But I am speaking about > destroying an object while the refcount is non-zero. Do you see the > difference? > > There are two ways to handle this: > > 1) blocking: wait until the refcount reaches zero. > > 2) nonblocking: increment some other refcount that the > callback checks before accessing any data. > > > Do you agree that method 2 is going to: > > - avoid deadlock > - avoid use of sx-locks, locks that allow calls to msleep(), > to keep synchronization while destroying objects > with refcounts. Not always. :) > When calling functions like "callout_stop()", it is likely that one is > holding a lock to prevent other code from calling "callout_start()" on the > same callback before "callout_stop()" has been called. Now, if > "callout_stop()" sleeps, the lock that is held while calling this function, > must allow calls msleep(). So this must be an sx-lock (see "man sx"). Now > if one routine sleeps, then any callers of this routine must sleep too. So > this affects the synchronization of the whole system. > > Isn't nonblocking operation preferred over blocking operation? You can call callout_stop() while holding the lock, then do a callout_drain() later when you are prepared to block. This is what I'm doing with ethernet drivers right now that typically call callout_stop in their foo_stop() routine so detach looks like: FOO_LOCK(sc); foo_stop(sc); // calls callout_stop() FOO_UNLOCK(sc); callout_drain(&sc->foo_stat_ch); > The callback can be called after that "callout_stop()" has been called! > > You can use _callout_stop_safe(), but the problem is that it will sleep, > waiting for "the other thread" to finish. The solution I have described, > makes this process non-blocking, which means that one can hold a lock while > calling callout_stop() which must be an advantage. See above. > > > - setting up devices. Make sure that read/write/ioctl/poll callbacks > > > are never called after that the device has been freed. > > > > This is managed with refcounts on the dev_t object by devfs. Once you > > call destroy_dev() devfs manages the rest. > > No, the callback functions read/write/ioctl/poll can be called after that > "destroy_dev()" has been called. Nope. Evert call to read/write/ioctl bumps a reference count on the underlying dev_t and destroy_dev() blocks until the reference count drops to zero. > > > - setting up interrupts. Make sure that interrupt routine is never > > > called after that it is been teared down. > > > > bus_teardown_intr() already does this. > > I'm sure it is the same here. If the interrupt handler doesn't have its own > lock then, I think the interrupt callback can be called after that > "bus_teardown_intr()" has been called. Nope. The interrupt code checks if the ithread is running and if so it flags the handler for removal and blocks to let the ithread remove the handler and then wake it up. > > > And more. There are lots of situations in the kernel that run into the > > > same scheme, without a proper solution. > > > > Are there any other places you can think of that don't handle this > > already? > > I am thinking about all the device drivers that create devices in /dev/ > that can be detache, and that really never checks anything before accessing > the softc: As above, since they use destroy_dev() they are already ok. > > The approach FreeBSD's kernel has taken is to solve this problem by > > duplicating a lot of checks all over the place for each data structure, > > but to solve it in the primitives themselves instead (hence > > callout_drain(), bus_teardown_intr(), destroy_dev(), etc.) > > Yes, but why are the implementations based on blocking operation, hence > this is not required? > > > > What I want is that the kernel provides some routine that can do locking > based on a structure like below. Also the kernel must provide some routines > to allocate, free and read a refcount. > > struct callback_args { > void *sc; > struct mtx *p_mtx; > u_int32_t refcount_copy; > u_int32_t *p_refcount; > }; > > Then I want routines like "callout_reset()", "make_dev()", > "bus_setup_intr()" and so on, to pass these four parameters to the callback > function, either directly, or like a pointer to this structure. You are just going to move the blocking behavior into contention on your locks, you aren't going to actually remove it anywhere, and since all users of the structures have to do more checking at runtime, I think you will end up increasing overhead. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 19:06:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A335816A41F; Thu, 4 Aug 2005 19:06:13 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id B88CD43D45; Thu, 4 Aug 2005 19:06:12 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 4 Aug 2005 20:05:22 +0100 (BST) Date: Thu, 4 Aug 2005 20:05:21 +0100 From: David Malone To: Hans Petter Selasky Message-ID: <20050804190521.GA28831@walton.maths.tcd.ie> References: <200508030023.04748.hselasky@c2i.net> <200508041340.58851.hselasky@c2i.net> <200508040953.59316.jhb@FreeBSD.org> <200508041850.14253.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508041850.14253.hselasky@c2i.net> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking 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, 04 Aug 2005 19:06:13 -0000 On Thu, Aug 04, 2005 at 06:50:12PM +0200, Hans Petter Selasky wrote: > 2) nonblocking: increment some other refcount that the > callback checks before accessing any data. I think people usually call this something like a "generation count". This sort of scheme used to be used for vnodes in FreeBSD. If you look through the archives for people talking about type-stable storage, you'll probably find some details. David. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 20:52:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31B8916A41F; Thu, 4 Aug 2005 20:52:43 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 493EB43D49; Thu, 4 Aug 2005 20:52:41 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-217-207-176.daxnet.no ([193.217.207.176] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 242015485; Thu, 04 Aug 2005 22:52:38 +0200 From: Hans Petter Selasky To: John Baldwin Date: Thu, 4 Aug 2005 22:53:32 +0200 User-Agent: KMail/1.7 References: <200508030023.04748.hselasky@c2i.net> <200508041850.14253.hselasky@c2i.net> <200508041415.56140.jhb@FreeBSD.org> In-Reply-To: <200508041415.56140.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508042253.34165.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 20:52:43 -0000 On Thursday 04 August 2005 20:15, John Baldwin wrote: > On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote: > > On Thursday 04 August 2005 15:53, John Baldwin wrote: > > > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote: > > > > On Wednesday 03 August 2005 19:21, John Baldwin wrote: > > > > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > > > > > Hi, > > > > > > > > > > > > I am looking for a safe way to access structures that can be > > > > > > freed. The solution I am looking for must not: > > > > > > > > > > > > - hinder scaleability > > > > > > - lead to use of a single lock > > > > > > - lead to lock order reversal > > > > > > > > There is one more thing. When the structure is freed it should not > > > > block waiting for any reference counts. > > > > > > crhold() is always called when the caller knows that it has a reference > > > to cr that can't go away. Thus, in the case of p_ucred, one holds the > > > associated PROC_LOCK() while doing crhold(). After the crhold() you > > > can drop the proc lock, so that lock is only held for a very short > > > period of time. You then have your own reference to the cred structure > > > that is valid until you call crfree(). In the case of > > > curthread->td_ucred, the reference is valid until curthread releases it > > > on a cred update at the start of a syscall, so your reference is valid > > > without needing locks for the life of a syscall. The key here is that > > > you solve this problem at a higher level, not within the structure > > > itself. > > > > Yes, this works with mbufs, crhold() and alike, where one doesn't > > actually free the object until the refcount reaches zero. But I am > > speaking about destroying an object while the refcount is non-zero. Do > > you see the difference? > > > > There are two ways to handle this: > > > > 1) blocking: wait until the refcount reaches zero. > > > > 2) nonblocking: increment some other refcount that the > > callback checks before accessing any data. > > > > > > Do you agree that method 2 is going to: > > > > - avoid deadlock > > - avoid use of sx-locks, locks that allow calls to msleep(), > > to keep synchronization while destroying objects > > with refcounts. > > Not always. :) > > > When calling functions like "callout_stop()", it is likely that one is > > holding a lock to prevent other code from calling "callout_start()" on > > the same callback before "callout_stop()" has been called. Now, if > > "callout_stop()" sleeps, the lock that is held while calling this > > function, must allow calls msleep(). So this must be an sx-lock (see "man > > sx"). Now if one routine sleeps, then any callers of this routine must > > sleep too. So this affects the synchronization of the whole system. > > > > Isn't nonblocking operation preferred over blocking operation? > > You can call callout_stop() while holding the lock, then do a > callout_drain() later when you are prepared to block. This is what I'm > doing with ethernet drivers right now that typically call callout_stop in > their foo_stop() routine so detach looks like: > > FOO_LOCK(sc); > foo_stop(sc); // calls callout_stop() > FOO_UNLOCK(sc); > callout_drain(&sc->foo_stat_ch); > This is only going to work if you are detaching. But consider the following: FOO_LOCK(sc); callout_stop(); callout_start(); FOO_UNLOCK(sc); Your solution is only spinning halfway around. What I say is that you need some more parameters passed to callbacks, so that one can check if it has been cancelled before proceeding. > > > No, the callback functions read/write/ioctl/poll can be called after that > > "destroy_dev()" has been called. > > Nope. Every call to read/write/ioctl bumps a reference count on the > underlying dev_t and destroy_dev() blocks until the reference count drops > to zero. Yes, I see that "dev_refthread()" and "dev_relthread()" are called from "devfs_xxx()", but "destroy_dev()" will not wait for these refcounts to reach zero unless the "d_purge" field is initialized in "struct cdevsw". And I cannot see that "prep_cdevs()" is setting any default value for this field. So by default "destroy_dev()" is non-blocking which is right. I am a bit lazy today, so I did: cat `find /usr/src/sys/dev/*` | grep d_purge And got two hits. This feature is not used at all. > > > > > What I want is that the kernel provides some routine that can do locking > > based on a structure like below. Also the kernel must provide some > > routines to allocate, free and read a refcount. > > > > struct callback_args { > > void *sc; > > struct mtx *p_mtx; > > u_int32_t refcount_copy; > > u_int32_t *p_refcount; > > }; > > > > Then I want routines like "callout_reset()", "make_dev()", > > "bus_setup_intr()" and so on, to pass these four parameters to the > > callback function, either directly, or like a pointer to this structure. > > You are just going to move the blocking behavior into contention on your > locks, you aren't going to actually remove it anywhere Yes, that is correct, but from what I understand it is inherently more efficient to wait for a mutex of type "struct mtx", than it is to use msleep/wakeup, which is the current way of doing it, according to "man sx". > , and since all users > of the structures have to do more checking at runtime I don't think so. > , I think you will end up increasing overhead. Let's consider a real example, for example "devfs_read_f()": devfs_read_f(...) { dev_refthread(dev); error = dsw->d_read(dev, uio, ioflag); dev_relthread(dev); return (error); } Per "devfs_read_f()" one has got to lock/unlock two times. It involves two refcount reads and two refcount writes, which means that the CPU cache will be invalidated. Now consider my proposal. There is no more need for dev_refthread/dev_relthread. Instead the callback, "d_read()" will do the checking. This consist of: d_read() { mtx_lock(args->mtx); if(args->refcount_copy == atomic_read(args->refcount_p)) { /* valid */ } mtx_unlock(args->mtx); return; } Per "devfs_read_f()" one has got to lock/unlock one time. It involves two refcount reads and no refcount writes. Well, isn't this 200 percent faster? The only overhead is that the "args" structure must be copied into the file-descriptor of the current thread while holding some global lock. But once that is done, there is no need to lock this global lock again. So if one reads from a device more times than one opens it, it is going to pay off. To cut down on the number of locks in the kernel, external routines accessing "dev" should get a copy of "args" while holding a global lock. Then use the "args" to lock "dev". If it fails, due to some paralell thread calling "dev_destroy()", just repeat. So this "args" structure I suggest, is like a ticket to get valid access to some callback, and should be copied to the callers that need this access. The following looks like a nice way to implement this: if(enter_callback(args)) { /* valid */ exit_callback(args); /* free to do other things */ if(enter_callback(args)) { /* still valid - only one check required */ exit_callback(args); } } So what do you think ? --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 00:55:12 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0108516A41F for ; Fri, 5 Aug 2005 00:55:12 +0000 (GMT) (envelope-from thib@mi.is) Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43AD343D45 for ; Fri, 5 Aug 2005 00:55:11 +0000 (GMT) (envelope-from thib@mi.is) Received: from caulfield ([85.220.68.8] [85.220.68.8]) by quasar.skima.is; Fri, 5 Aug 2005 00:55:09 Z Date: Fri, 5 Aug 2005 00:55:43 +0000 From: "Thordur I. Bjornsson" To: hackers@freebsd.org Message-Id: <20050805005543.5bd947f2.thib@mi.is> Organization: n/a X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Checking sysctl values from within the kernel. 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, 05 Aug 2005 00:55:12 -0000 Hello list. If I want to check a sysctl value from within the kernel (e.g. an KLD), should I use the system calls described in sysctl(3) ? If not, what is the propper way to do so ? And if it is and I want to do error checking e.g: if((sysctl(name, namelen, &val, NULL, 0)) != 0) { "Error in call to sysctl(3) blah blah blah"; } What would be the correct way to report,stop, &c ? This is propaply depentand on what I'm doing so... If this is A&A I'm sorry for the noize, I have not been able to find anything on google/archives. (It's late ;) -- Thordur I. Humppa! From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 4 15:04:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3294316A41F for ; Thu, 4 Aug 2005 15:04:06 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B9843D48 for ; Thu, 4 Aug 2005 15:04:05 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id j74F45s6095950 for ; Thu, 4 Aug 2005 08:04:05 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j74F45eQ095949 for freebsd-hackers@freebsd.org; Thu, 4 Aug 2005 08:04:05 -0700 (PDT) (envelope-from sgk) Date: Thu, 4 Aug 2005 08:04:05 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Message-ID: <20050804150405.GA95916@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 05 Aug 2005 12:28:30 +0000 Subject: Number of significand bits in long double? 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, 04 Aug 2005 15:04:06 -0000 Can someone confirm or refute that the working number of bits in the significand of long double type is 53 on i386? -- Steve From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 02:44:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F96E16A41F; Fri, 5 Aug 2005 02:44:32 +0000 (GMT) (envelope-from dmwassman@cox.net) Received: from eastrmmtao03.cox.net (eastrmmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F3E543D45; Fri, 5 Aug 2005 02:44:32 +0000 (GMT) (envelope-from dmwassman@cox.net) Received: from smtp.east.cox.net ([172.18.52.54]) by eastrmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with SMTP id <20050805024429.PWWN8255.eastrmmtao03.cox.net@smtp.east.cox.net>; Thu, 4 Aug 2005 22:44:29 -0400 X-Mailer: Openwave WebEngine, version 2.8.15 (webedge20-101-1103-20040528) From: To: , Date: Thu, 4 Aug 2005 22:44:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20050805024429.PWWN8255.eastrmmtao03.cox.net@smtp.east.cox.net> X-Mailman-Approved-At: Fri, 05 Aug 2005 12:28:30 +0000 Cc: Subject: WinXP and FreeBSD configuration 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: Fri, 05 Aug 2005 02:44:32 -0000 Hello all, OK it is now day three and I have given up. This will be a long one just to warn you now. I have a 320 GiB HD and a 5 GiB HD. The 320 is faster than the 5 (yes, it is that old). I want to dual boot WinXP and FreeBSD. The main issue is that I don't want to put the FreeBSD buried behind 100G FAT partition as I would like to have the swap closer to the edge of the HD. I use the 5 G to transfer files and such, especially when changing the OS on a partition. I prefer not to use it a a boot as it is only 5400 and I would have to put the CDROM on either it as prime boot and slow it more or on the 320 and slow it down. This seems like a simple problem but it has not turned out that way. First, I tried to install windows on the first 2G partition then tried to install freebsd as follows ad0s0 NTFS 2G #Windows Boot ad0s1 FreeBSD 2G #FreeBSD Boot/Swap ad0s3 FAT 20G #Windows ad0s4 FreeBSD 298G #FreeBSD Now when I finished installing WinXP I could boot with no problems but after installing FreeBSD, I get a BSOD when trying to boot WinXP. I looked thru google, FreeBSD, and Microsoft for a possible answer. No. Everyone seems to just put all of WinXP on the first partition and then FreeBSD or Linux. I think thats fine for a 20, 30 or even 80 GiB HD but I think there will be a performance issue with the boot and swap so deep on the HD. Next, I tried to reinstall WinXP but when I get the the diskpart section, I only see one partition of 130G (diskpart cannot get past the 128G limit). There is no other partitions, not even the FAT labeled partition. Now I am getting frustrated. Next I tried Ranish Partition Manager (great PM by the way, 30 possible primaries). I set it as follows 1 FAT 2G #Windows Boot 2 unused 2G #To be FreeBSD 3 FAT 20G #Windows 4 unused 298G #To be FreeBSD. I used RPM to format the two FAT partitions. Then installed WinXP. WinXP see the two FAT partitions, the first one I format to NTFS and continue the install. After reboot, WinXP boots fine. Then I again try to install FreeBSD and reboot to WinXP to low and behold, the BSOD. Now I am MAD. Next, I used RPM to edit the MBR list so the 2 FAT partitions are 1 and 2 respectively. This fools the WinXP Install but again I get the BSOD after I install FreeBSD. I have also tried to install RPM loader with the last complete cylinder for the boot manager to no avail. I am now about ready to play hackysack with my HD. Since then I have tried several variations of these themes, diskpart, fdisk and/or RPM in varying order but every time I get a BSOD or a single partition in WinXP install. I would love to be able to put another partition between the FreeBSD boot partition and the Windows partition for a different OS (possible Solaris) using RPM to boot the more than 4 primes this will create but I don't dare until this is solved. I have tried to reach zen to control my skyrocketing rage but have failed to reach enlightenment after my second keyboard was pounded into legos. Any idea how to do this. I prefer not to have to use the 5G as a boot disk but will have to if I can't get this working. The most frustrating thing is it should just work. I could easily do this with any other OS other than MS crap. Why does WinXP care what I do with the other prime partitions or how this can possible affect them, I am at a complete loss. At least, I think I understand simple tech work as how HD's work but I could be wrong. Thanks for the help in advance, David From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 13:15:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0C7E16A423 for ; Fri, 5 Aug 2005 13:15:43 +0000 (GMT) (envelope-from DAntrushin@mail.ru) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA59E43D49 for ; Fri, 5 Aug 2005 13:15:42 +0000 (GMT) (envelope-from DAntrushin@mail.ru) Received: from [81.3.158.68] (port=47329 helo=[129.159.124.237]) by mx2.mail.ru with esmtp id 1E122y-000LfN-00; Fri, 05 Aug 2005 17:15:36 +0400 Message-ID: <42F36675.2090602@mail.ru> Date: Fri, 05 Aug 2005 17:15:33 +0400 From: Denis Antrushin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Kargl References: <20050804150405.GA95916@troutmask.apl.washington.edu> In-Reply-To: <20050804150405.GA95916@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 13:15:44 -0000 Steve Kargl wrote: > Can someone confirm or refute that the working number > of bits in the significand of long double type is 53 > on i386? > Yes, this is what IEEE 754 requires. (See http://docs.sun.com/source/806-3568/ncg_goldberg.html, section 'The IEEE Standard') From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 14:50:52 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C918B16A41F for ; Fri, 5 Aug 2005 14:50:52 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D1343D49 for ; Fri, 5 Aug 2005 14:50:52 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j75Eok4j029663; Fri, 5 Aug 2005 09:50:46 -0500 (CDT) (envelope-from dan) Date: Fri, 5 Aug 2005 09:50:46 -0500 From: Dan Nelson To: "Thordur I. Bjornsson" Message-ID: <20050805145046.GB78669@dan.emsphone.com> References: <20050805005543.5bd947f2.thib@mi.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050805005543.5bd947f2.thib@mi.is> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 14:50:52 -0000 In the last episode (Aug 05), Thordur I. Bjornsson said: > If I want to check a sysctl value from within the kernel (e.g. an > KLD), should I use the system calls described in sysctl(3) ? > > If not, what is the propper way to do so ? Since most sysctls are direct mappings onto integer variables in the kernel, just check the variable directly. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 15:33:17 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D281B16A420 for ; Fri, 5 Aug 2005 15:33:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85FEA43D49 for ; Fri, 5 Aug 2005 15:33:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j75FegWO063814; Fri, 5 Aug 2005 09:40:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42F386B2.1010108@samsco.org> Date: Fri, 05 Aug 2005 09:33:06 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Nelson References: <20050805005543.5bd947f2.thib@mi.is> <20050805145046.GB78669@dan.emsphone.com> In-Reply-To: <20050805145046.GB78669@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: hackers@freebsd.org Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 15:33:17 -0000 Dan Nelson wrote: > In the last episode (Aug 05), Thordur I. Bjornsson said: > >>If I want to check a sysctl value from within the kernel (e.g. an >>KLD), should I use the system calls described in sysctl(3) ? >> >>If not, what is the propper way to do so ? > > > Since most sysctls are direct mappings onto integer variables in the > kernel, just check the variable directly. > Most of those integer values are also declared static, so they won't be visible to external code, especially not kld's. There is no easy way to do this. I'm sure that you could hack up some code to simulate a sysctl syscall from within the kernel, but that would be really really gross, evil, and wrong. What values are you trying to get at? Would it make more sense to export them via real accessor functions? Scott From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 15:54:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 567DB16A41F for ; Fri, 5 Aug 2005 15:54:30 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B619A43D72 for ; Fri, 5 Aug 2005 15:54:25 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 05 Aug 2005 12:09:01 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 5 Aug 2005 11:01:32 -0400 User-Agent: KMail/1.8 References: <20050805005543.5bd947f2.thib@mi.is> <20050805145046.GB78669@dan.emsphone.com> In-Reply-To: <20050805145046.GB78669@dan.emsphone.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200508051101.33927.jhb@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Dan Nelson Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 15:54:30 -0000 On Friday 05 August 2005 10:50 am, Dan Nelson wrote: > In the last episode (Aug 05), Thordur I. Bjornsson said: > > If I want to check a sysctl value from within the kernel (e.g. an > > KLD), should I use the system calls described in sysctl(3) ? > > > > If not, what is the propper way to do so ? > > Since most sysctls are direct mappings onto integer variables in the > kernel, just check the variable directly. There's also a kernel_sysctl() function available in the kernel for in-kernel access to sysctls. You might have to lookup the OID for a given name yourself though. Actually, there's a kernel_sysctlbyname() as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 16:02:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 934BD16A41F for ; Fri, 5 Aug 2005 16:02:58 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 89CA743D49 for ; Fri, 5 Aug 2005 16:02:57 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail invoked by alias); 05 Aug 2005 16:02:56 -0000 Received: from unknown (EHLO klamath) [212.204.44.203] by mail.gmx.net (mp024) with SMTP; 05 Aug 2005 18:02:56 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: dmwassman@cox.net In-Reply-To: <20050805024429.PWWN8255.eastrmmtao03.cox.net@smtp.east.cox.net> References: <20050805024429.PWWN8255.eastrmmtao03.cox.net@smtp.east.cox.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LIuoz/yuofCXM/aDWJIv" Date: Fri, 05 Aug 2005 18:02:52 +0200 Message-Id: <1123257773.1029.18.camel@klamath.syndrom23.de> Mime-Version: 1.0 X-Mailer: Evolution 2.3.5.1 FreeBSD GNOME Team Port X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: WinXP and FreeBSD configuration 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: Fri, 05 Aug 2005 16:02:58 -0000 --=-LIuoz/yuofCXM/aDWJIv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-08-04 at 22:44 -0400, dmwassman@cox.net wrote: > Hello all, >=20 > OK it is now day three and I have given up. This will be a long=20 > one just to warn you now.=20 >=20 [...] > First, I tried to install windows on the first 2G partition then=20 > tried to install freebsd as follows=20 > ad0s0 NTFS 2G #Windows Boot > ad0s1 FreeBSD 2G #FreeBSD Boot/Swap > ad0s3 FAT 20G #Windows > ad0s4 FreeBSD 298G #FreeBSD=09 >=20 > Now when I finished installing WinXP I could boot with no problems=20 > but after installing FreeBSD, I get a BSOD when trying to boot WinXP.=20 > I looked thru google, FreeBSD, and Microsoft for a possible answer.=20 > No. Everyone seems to just put all of WinXP on the first partition=20 > and then FreeBSD or Linux. I think thats fine for a 20, 30 or even=20 > 80 GiB HD but I think there will be a performance issue with the=20 > boot and swap so deep on the HD. Hi, I would say this is a Windows problem. Old Windows certainly had the=20 habit of only reading the partition table up to the first non-windows partition.=20 Looks like WinXP still does the same. But as your only reason for trying for days to get this to work is a possible performance loss, you may perhaps want to try to measure this loss and see if it warrants days of work against Windows. Best regards, -- Andreas --=20 was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ --=-LIuoz/yuofCXM/aDWJIv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC842sYucd7Ow1ygwRAjbsAKCLh6r/OK/JNSjNijMbSNoMt6/UIACfUuhA oJUNQ9BcIT7ZLHleoVbCVOM= =iTPq -----END PGP SIGNATURE----- --=-LIuoz/yuofCXM/aDWJIv-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 16:04:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4D5116A41F for ; Fri, 5 Aug 2005 16:04:27 +0000 (GMT) (envelope-from thib@mi.is) Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B21043D68 for ; Fri, 5 Aug 2005 16:04:16 +0000 (GMT) (envelope-from thib@mi.is) Received: from caulfield ([85.220.64.242] [85.220.64.242]) by quasar.skima.is; Fri, 5 Aug 2005 16:04:14 Z Date: Fri, 5 Aug 2005 16:04:15 +0000 From: "Thordur I. Bjornsson" To: freebsd-hackers@freebsd.org Message-Id: <20050805160415.44b0b05e.thib@mi.is> In-Reply-To: <42F386B2.1010108@samsco.org> References: <20050805005543.5bd947f2.thib@mi.is> <20050805145046.GB78669@dan.emsphone.com> <42F386B2.1010108@samsco.org> Organization: n/a X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 16:04:27 -0000 On Fri, 05 Aug 2005 09:33:06 -0600 Scott Long wrote: > Dan Nelson wrote: > > > In the last episode (Aug 05), Thordur I. Bjornsson said: > > > >>If I want to check a sysctl value from within the kernel (e.g. an > >>KLD), should I use the system calls described in sysctl(3) ? > >> > >>If not, what is the propper way to do so ? > > > > > > Since most sysctls are direct mappings onto integer variables in the > > kernel, just check the variable directly. > > > > Most of those integer values are also declared static, so they won't > be visible to external code, especially not kld's. > > There is no easy way to do this. I'm sure that you could hack up some > code to simulate a sysctl syscall from within the kernel, but that > would be really really gross, evil, and wrong. What values are you > trying to get at? Would it make more sense to export them via real > accessor functions? > > Scott I thought that would be a proplem. I'm trying to see the value of net.inet.tcp.drop_synfin . I could always just use the #ifdef TCP_DROP_SYNFIN wich gets set with the kernel option but that does not mean that the sysctl is set and the user/admin want's to drop SYNFIN packet's. Since I'm a novice/newbie when it comes to "kernel" programming any tips will be really good. I'll continue to search for this. PS: If you don't mind, what is a "real accessor function" ? -- Thordur I. Humppa! From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 16:38:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC85316A41F for ; Fri, 5 Aug 2005 16:38:13 +0000 (GMT) (envelope-from DAntrushin@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id C432A43D45 for ; Fri, 5 Aug 2005 16:38:12 +0000 (GMT) (envelope-from DAntrushin@mail.ru) Received: from [81.3.158.68] (port=11625 helo=[129.159.124.237]) by mx3.mail.ru with esmtp id 1E15Cy-000LGe-00; Fri, 05 Aug 2005 20:38:08 +0400 Message-ID: <42F395D8.5020200@mail.ru> Date: Fri, 05 Aug 2005 20:37:44 +0400 From: Denis Antrushin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Kargl References: <20050804150405.GA95916@troutmask.apl.washington.edu> <42F36675.2090602@mail.ru> <20050805160219.GB4147@troutmask.apl.washington.edu> In-Reply-To: <20050805160219.GB4147@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 16:38:13 -0000 Steve Kargl wrote: > On Fri, Aug 05, 2005 at 05:15:33PM +0400, Denis Antrushin wrote: > >>Steve Kargl wrote: >> >>>Can someone confirm or refute that the working number >>>of bits in the significand of long double type is 53 >>>on i386? >>> >> >>Yes, this is what IEEE 754 requires. >>(See http://docs.sun.com/source/806-3568/ncg_goldberg.html, >>section 'The IEEE Standard') >> > > BZZZT. > > You're not even close to correct. See Table 1 in the IEEE > 754 standard and then read section 3.4. > Well, you know the answer then ;-) From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 16:44:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 922E916A41F for ; Fri, 5 Aug 2005 16:44:18 +0000 (GMT) (envelope-from thib@mi.is) Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id E466F43D55 for ; Fri, 5 Aug 2005 16:44:17 +0000 (GMT) (envelope-from thib@mi.is) Received: from caulfield ([85.220.64.242] [85.220.64.242]) by quasar.skima.is; Fri, 5 Aug 2005 16:44:16 Z Date: Fri, 5 Aug 2005 16:44:17 +0000 From: "Thordur I. Bjornsson" To: freebsd-hackers@freebsd.org Message-Id: <20050805164417.32edf853.thib@mi.is> In-Reply-To: <200508051101.33927.jhb@FreeBSD.org> References: <20050805005543.5bd947f2.thib@mi.is> <20050805145046.GB78669@dan.emsphone.com> <200508051101.33927.jhb@FreeBSD.org> Organization: n/a X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 16:44:18 -0000 On Fri, 5 Aug 2005 11:01:32 -0400 John Baldwin wrote: > On Friday 05 August 2005 10:50 am, Dan Nelson wrote: > > In the last episode (Aug 05), Thordur I. Bjornsson said: > > > If I want to check a sysctl value from within the kernel (e.g. an > > > KLD), should I use the system calls described in sysctl(3) ? > > > > > > If not, what is the propper way to do so ? > > > > Since most sysctls are direct mappings onto integer variables in the > > kernel, just check the variable directly. > > There's also a kernel_sysctl() function available in the kernel for > in-kernel access to sysctls. You might have to lookup the OID for a > given name yourself though. Actually, there's a > kernel_sysctlbyname() as well. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org Ahh. Cool This is not in any manpage ... I'm trying to understand the first argument to kernel_systcl(), kernel_sysctl(struct thread *td, ... ) This thread, that it takes as an argument is this something that I need to worry about when writing KLD's or could I just pass a NULL pointer ? The proplem is that I do not know/understand how threading works in the kernel. I'll be lookin into that (although pointers are more then welcome ;) -- Thordur I. Humppa! From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 17:24:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38AC516A41F; Fri, 5 Aug 2005 17:24:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C271F43D45; Fri, 5 Aug 2005 17:24:45 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j75HWG9K064365; Fri, 5 Aug 2005 11:32:16 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42F3A0D2.7090402@samsco.org> Date: Fri, 05 Aug 2005 11:24:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050805005543.5bd947f2.thib@mi.is> <20050805145046.GB78669@dan.emsphone.com> <200508051101.33927.jhb@FreeBSD.org> In-Reply-To: <200508051101.33927.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org, Dan Nelson Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 17:24:48 -0000 John Baldwin wrote: > On Friday 05 August 2005 10:50 am, Dan Nelson wrote: > >>In the last episode (Aug 05), Thordur I. Bjornsson said: >> >>>If I want to check a sysctl value from within the kernel (e.g. an >>>KLD), should I use the system calls described in sysctl(3) ? >>> >>>If not, what is the propper way to do so ? >> >>Since most sysctls are direct mappings onto integer variables in the >>kernel, just check the variable directly. > > > There's also a kernel_sysctl() function available in the kernel for in-kernel > access to sysctls. You might have to lookup the OID for a given name > yourself though. Actually, there's a kernel_sysctlbyname() as well. > Shoot, forgot about that function. However, exporting data throughout the kernel via the sysctl interface sounds like poor design. Scott From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 17:34:07 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B832116A41F for ; Fri, 5 Aug 2005 17:34:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE2343D4C for ; Fri, 5 Aug 2005 17:34:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j75HWXiO044921; Fri, 5 Aug 2005 11:32:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 05 Aug 2005 11:33:35 -0600 (MDT) Message-Id: <20050805.113335.27815012.imp@bsdimp.com> To: sgk@troutmask.apl.washington.edu From: "M. Warner Losh" In-Reply-To: <20050804150405.GA95916@troutmask.apl.washington.edu> References: <20050804150405.GA95916@troutmask.apl.washington.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 05 Aug 2005 11:32:34 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 17:34:07 -0000 In message: <20050804150405.GA95916@troutmask.apl.washington.edu> Steve Kargl writes: : Can someone confirm or refute that the working number : of bits in the significand of long double type is 53 : on i386? The number of bits is 53. However, you can get more bits by adding a fpsetprec(FP_PE) at the start of the programs. Otherwise, you get FP_PD by default. Once you do that, things seem to basically work, but I've not run paranoia.c to make sure. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 17:41:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6999716A41F for ; Fri, 5 Aug 2005 17:41:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0A2743E62 for ; Fri, 5 Aug 2005 17:37:09 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j75Hakht082778; Fri, 5 Aug 2005 11:36:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 05 Aug 2005 11:37:48 -0600 (MDT) Message-Id: <20050805.113748.60551134.imp@bsdimp.com> To: DAntrushin@mail.ru From: "M. Warner Losh" In-Reply-To: <42F36675.2090602@mail.ru> References: <20050804150405.GA95916@troutmask.apl.washington.edu> <42F36675.2090602@mail.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 05 Aug 2005 11:36:47 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, sgk@troutmask.apl.washington.edu Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 17:41:26 -0000 In message: <42F36675.2090602@mail.ru> Denis Antrushin writes: : Steve Kargl wrote: : > Can someone confirm or refute that the working number : > of bits in the significand of long double type is 53 : > on i386? : Yes, this is what IEEE 754 requires. : (See http://docs.sun.com/source/806-3568/ncg_goldberg.html, : section 'The IEEE Standard') float and double are defined by the IEEE Standard. long double isn't required to be anything, by the IEEE standard. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 17:42:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08E8616A420 for ; Fri, 5 Aug 2005 17:42:57 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B64B743DB6 for ; Fri, 5 Aug 2005 17:37:40 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 23453 invoked by uid 89); 5 Aug 2005 17:38:12 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 5 Aug 2005 17:38:12 -0000 Received: from 66.166.104.222 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Fri, 5 Aug 2005 11:38:12 -0600 (MDT) Message-ID: <2612.66.166.104.222.1123263492.squirrel@66.166.104.222> In-Reply-To: <20050805024429.PWWN8255.eastrmmtao03.cox.net@smtp.east.cox.net> References: <20050805024429.PWWN8255.eastrmmtao03.cox.net@smtp.east.cox.net> Date: Fri, 5 Aug 2005 11:38:12 -0600 (MDT) From: "Ryan Sommers" To: dmwassman@cox.net User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: WinXP and FreeBSD configuration 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: Fri, 05 Aug 2005 17:42:57 -0000 dmwassman@cox.net said: > ad0s0 NTFS 2G #Windows Boot > ad0s1 FreeBSD 2G #FreeBSD Boot/Swap > ad0s3 FAT 20G #Windows > ad0s4 FreeBSD 298G #FreeBSD > ... extra stuff eliminated ... Why the miniscule 2gb partitions? Honestly, they are pointless. Second, worrying about the performance of boot and swap on a computer with a 320GB harddrive? Again pointless. If you are worried about the performance of your swap space I would rethink running Windows XP because you have way too little RAM. Third, why are you making seperate partitions for boot and swap anyway? >From here on out I'm going to revert to the BSD style where you say partition I will now call it a slice. FreeBSD can reside on a single slice. The BSD disklabel'er divides the FreeBSD slice into partitions, for things like swap, and file-systems. My recommendations to you are as follows: 1) Don't worry about where things are on the disk. You're complicating the hell out of everything and in the end you probably won't notice a difference. If you're that worried about performance invest in multiple SCSI disks and create multiple RAID arrays optimized for performance. 2) Don't worry about making seperate slices (the things you can only make 4 of). 3) Make a single slice for Windows and install it there. It's good to make it the first slice on the disk, but not necessary. Then install FreeBSD to another slice. Let FreeBSD overwrite the MBR with the standard boot manager. This has worked countless times for me. I've always dual booted my laptops with FreeBSD and a Windows OS. Just me .02. If you'd like feel free to contact me personally and I'd be glad to help you get started. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 19:26:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C43D16A420 for ; Fri, 5 Aug 2005 19:26:06 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D32A43D49 for ; Fri, 5 Aug 2005 19:26:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 05 Aug 2005 15:40:46 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 5 Aug 2005 13:08:31 -0400 User-Agent: KMail/1.8 References: <20050805005543.5bd947f2.thib@mi.is> <200508051101.33927.jhb@FreeBSD.org> <20050805164417.32edf853.thib@mi.is> In-Reply-To: <20050805164417.32edf853.thib@mi.is> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508051308.32649.jhb@FreeBSD.org> Cc: Subject: Re: Checking sysctl values from within the kernel. 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, 05 Aug 2005 19:26:06 -0000 On Friday 05 August 2005 12:44 pm, Thordur I. Bjornsson wrote: > On Fri, 5 Aug 2005 11:01:32 -0400 > > John Baldwin wrote: > > On Friday 05 August 2005 10:50 am, Dan Nelson wrote: > > > In the last episode (Aug 05), Thordur I. Bjornsson said: > > > > If I want to check a sysctl value from within the kernel (e.g. an > > > > KLD), should I use the system calls described in sysctl(3) ? > > > > > > > > If not, what is the propper way to do so ? > > > > > > Since most sysctls are direct mappings onto integer variables in the > > > kernel, just check the variable directly. > > > > There's also a kernel_sysctl() function available in the kernel for > > in-kernel access to sysctls. You might have to lookup the OID for a > > given name yourself though. Actually, there's a > > kernel_sysctlbyname() as well. > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > Ahh. Cool > This is not in any manpage ... > > I'm trying to understand the first argument to kernel_systcl(), > kernel_sysctl(struct thread *td, ... ) > > This thread, that it takes as an argument is this something that I need > to worry about when writing KLD's or could I just pass a NULL pointer ? > > The proplem is that I do not know/understand how threading works in the > kernel. I'll be lookin into that (although pointers are more then > welcome ;) Pass curthread as the thread. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 19:26:07 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80E1B16A41F for ; Fri, 5 Aug 2005 19:26:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6D0B43D4C for ; Fri, 5 Aug 2005 19:26:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 05 Aug 2005 15:40:47 -0400 From: John Baldwin To: hselasky@c2i.net Date: Fri, 5 Aug 2005 13:29:14 -0400 User-Agent: KMail/1.8 References: <200508030023.04748.hselasky@c2i.net> <200508041415.56140.jhb@FreeBSD.org> <200508042253.34165.hselasky@c2i.net> In-Reply-To: <200508042253.34165.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508051329.14767.jhb@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking 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, 05 Aug 2005 19:26:07 -0000 On Thursday 04 August 2005 04:53 pm, Hans Petter Selasky wrote: > On Thursday 04 August 2005 20:15, John Baldwin wrote: > > On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote: > > > On Thursday 04 August 2005 15:53, John Baldwin wrote: > > > > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote: > > > > > On Wednesday 03 August 2005 19:21, John Baldwin wrote: > > > > > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I am looking for a safe way to access structures that can be > > > > > > > freed. The solution I am looking for must not: > > > > > > > > > > > > > > - hinder scaleability > > > > > > > - lead to use of a single lock > > > > > > > - lead to lock order reversal > > > > > > > > > > There is one more thing. When the structure is freed it should not > > > > > block waiting for any reference counts. > > > > > > > > crhold() is always called when the caller knows that it has a > > > > reference to cr that can't go away. Thus, in the case of p_ucred, > > > > one holds the associated PROC_LOCK() while doing crhold(). After the > > > > crhold() you can drop the proc lock, so that lock is only held for a > > > > very short period of time. You then have your own reference to the > > > > cred structure that is valid until you call crfree(). In the case of > > > > curthread->td_ucred, the reference is valid until curthread releases > > > > it on a cred update at the start of a syscall, so your reference is > > > > valid without needing locks for the life of a syscall. The key here > > > > is that you solve this problem at a higher level, not within the > > > > structure itself. > > > > > > Yes, this works with mbufs, crhold() and alike, where one doesn't > > > actually free the object until the refcount reaches zero. But I am > > > speaking about destroying an object while the refcount is non-zero. Do > > > you see the difference? > > > > > > There are two ways to handle this: > > > > > > 1) blocking: wait until the refcount reaches zero. > > > > > > 2) nonblocking: increment some other refcount that the > > > callback checks before accessing any data. > > > > > > > > > Do you agree that method 2 is going to: > > > > > > - avoid deadlock > > > - avoid use of sx-locks, locks that allow calls to msleep(), > > > to keep synchronization while destroying objects > > > with refcounts. > > > > Not always. :) > > > > > When calling functions like "callout_stop()", it is likely that one is > > > holding a lock to prevent other code from calling "callout_start()" on > > > the same callback before "callout_stop()" has been called. Now, if > > > "callout_stop()" sleeps, the lock that is held while calling this > > > function, must allow calls msleep(). So this must be an sx-lock (see > > > "man sx"). Now if one routine sleeps, then any callers of this routine > > > must sleep too. So this affects the synchronization of the whole > > > system. > > > > > > Isn't nonblocking operation preferred over blocking operation? > > > > You can call callout_stop() while holding the lock, then do a > > callout_drain() later when you are prepared to block. This is what I'm > > doing with ethernet drivers right now that typically call callout_stop in > > their foo_stop() routine so detach looks like: > > > > FOO_LOCK(sc); > > foo_stop(sc); // calls callout_stop() > > FOO_UNLOCK(sc); > > callout_drain(&sc->foo_stat_ch); > > This is only going to work if you are detaching. But consider the > following: > > FOO_LOCK(sc); > callout_stop(); > callout_start(); > FOO_UNLOCK(sc); > > Your solution is only spinning halfway around. What I say is that you need > some more parameters passed to callbacks, so that one can check if it has > been cancelled before proceeding. Err, there is no callout_start(), but callout_reset() will just reschedule a callout if it's already pending. The consumer of the callout can maintain his own side state that he can check in his callout to handle a state change in between scheduling the callout and the callout running. > > > No, the callback functions read/write/ioctl/poll can be called after > > > that "destroy_dev()" has been called. > > > > Nope. Every call to read/write/ioctl bumps a reference count on the > > underlying dev_t and destroy_dev() blocks until the reference count drops > > to zero. > > Yes, I see that "dev_refthread()" and "dev_relthread()" are called from > "devfs_xxx()", but "destroy_dev()" will not wait for these refcounts to > reach zero unless the "d_purge" field is initialized in "struct cdevsw". > And I cannot see that "prep_cdevs()" is setting any default value for this > field. So by default "destroy_dev()" is non-blocking which is right. > > I am a bit lazy today, so I did: > > cat `find /usr/src/sys/dev/*` | grep d_purge > > And got two hits. This feature is not used at all. Yes, I think that's a bug. It should sleep as long as threadcount is > 0 and dev_relthread() should do a wakeup when the refcount hits zero. I've talked with phk@ about this and we might try that out in HEAD. > > > What I want is that the kernel provides some routine that can do > > > locking based on a structure like below. Also the kernel must provide > > > some routines to allocate, free and read a refcount. > > > > > > struct callback_args { > > > void *sc; > > > struct mtx *p_mtx; > > > u_int32_t refcount_copy; > > > u_int32_t *p_refcount; > > > }; > > > > > > Then I want routines like "callout_reset()", "make_dev()", > > > "bus_setup_intr()" and so on, to pass these four parameters to the > > > callback function, either directly, or like a pointer to this > > > structure. > > > > You are just going to move the blocking behavior into contention on your > > locks, you aren't going to actually remove it anywhere > > Yes, that is correct, but from what I understand it is inherently more > efficient to wait for a mutex of type "struct mtx", than it is to use > msleep/wakeup, which is the current way of doing it, according to "man sx". Well, it depends on what you are doing. Waiting for a device to detach is not a critical path. > > , and since all users > > of the structures have to do more checking at runtime > > I don't think so. > > > , I think you will end up increasing overhead. > > Let's consider a real example, for example "devfs_read_f()": > > devfs_read_f(...) > { > > dev_refthread(dev); > > error = dsw->d_read(dev, uio, ioflag); > > dev_relthread(dev); > > return (error); > } > > Per "devfs_read_f()" one has got to lock/unlock two times. It involves two > refcount reads and two refcount writes, which means that the CPU cache will > be invalidated. Err, refcount operations don't invalidate the CPU cache all by themselves. If there is contention then individual lines might be invalidated, but if your CPUs are contending you're going to lose anyway. > Now consider my proposal. There is no more need for > dev_refthread/dev_relthread. Instead the callback, "d_read()" will do the > checking. This consist of: > > d_read() > { > mtx_lock(args->mtx); > > if(args->refcount_copy == atomic_read(args->refcount_p)) > { > /* valid */ > } > > mtx_unlock(args->mtx); > > return; > } > > Per "devfs_read_f()" one has got to lock/unlock one time. It involves two > refcount reads and no refcount writes. > > Well, isn't this 200 percent faster? Maybe, but another thing you need to consider is "maintainenance" overhead. Device drivers, especially, should be the simplest parts of the kernel to implement because we want to minimize the potential for screw up in that area. Having to trust that the same code is going to be duplicated 40 or 50 times without any errors versus having it done once in a centralized place where it breaks everyone if it is broken is just insane. Otherwise, we might as well go write the whole kernel in assembly so we can tweak every last bit out of it. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 22:31:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6869616A41F; Fri, 5 Aug 2005 22:31:24 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CBF843D55; Fri, 5 Aug 2005 22:31:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j75MTU4Y058626; Fri, 5 Aug 2005 16:29:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 05 Aug 2005 16:30:32 -0600 (MDT) Message-Id: <20050805.163032.133432410.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200508051329.14767.jhb@FreeBSD.org> References: <200508041415.56140.jhb@FreeBSD.org> <200508042253.34165.hselasky@c2i.net> <200508051329.14767.jhb@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 05 Aug 2005 16:29:35 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, hselasky@c2i.net Subject: Re: How to do proper locking 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, 05 Aug 2005 22:31:24 -0000 In message: <200508051329.14767.jhb@FreeBSD.org> John Baldwin writes: : Maybe, but another thing you need to consider is "maintainenance" overhead. : Device drivers, especially, should be the simplest parts of the kernel to : implement because we want to minimize the potential for screw up in that : area. Having to trust that the same code is going to be duplicated 40 or 50 : times without any errors versus having it done once in a centralized place : where it breaks everyone if it is broken is just insane. Otherwise, we might : as well go write the whole kernel in assembly so we can tweak every last bit : out of it. :) History has shown that when you have to rely on 50 copies of something being done right, 48 of them will, in fact, have 49 different things wrong with them. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 23:39:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F32F16A41F; Fri, 5 Aug 2005 23:39:19 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 254D743D45; Fri, 5 Aug 2005 23:39:17 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== Received: from mp-217-203-29.daxnet.no ([193.217.203.29] verified) by mailfe11.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 4205728; Sat, 06 Aug 2005 01:39:14 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Sat, 6 Aug 2005 01:39:55 +0200 User-Agent: KMail/1.7 References: <200508030023.04748.hselasky@c2i.net> <200508042253.34165.hselasky@c2i.net> <200508051329.14767.jhb@FreeBSD.org> In-Reply-To: <200508051329.14767.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508060139.57143.hselasky@c2i.net> Cc: Subject: Re: How to do proper locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 23:39:19 -0000 On Friday 05 August 2005 19:29, John Baldwin wrote: > On Thursday 04 August 2005 04:53 pm, Hans Petter Selasky wrote: > > On Thursday 04 August 2005 20:15, John Baldwin wrote: > > > On Thursday 04 August 2005 12:50 pm, Hans Petter Selasky wrote: > > > > On Thursday 04 August 2005 15:53, John Baldwin wrote: > > > > > On Thursday 04 August 2005 07:40 am, Hans Petter Selasky wrote: > > > > > > On Wednesday 03 August 2005 19:21, John Baldwin wrote: > > > > > > > On Tuesday 02 August 2005 06:23 pm, Hans Petter Selasky wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am looking for a safe way to access structures that can be > > > > > > > > freed. The solution I am looking for must not: > > > > > > > > > > > > > > > > - hinder scaleability > > > > > > > > - lead to use of a single lock > > > > > > > > - lead to lock order reversal > > > > > > > > > This is only going to work if you are detaching. But consider the > > following: > > > > FOO_LOCK(sc); > > callout_stop(); > > callout_start(); > > FOO_UNLOCK(sc); > > > > Your solution is only spinning halfway around. What I say is that you > > need some more parameters passed to callbacks, so that one can check if > > it has been cancelled before proceeding. > > Err, there is no callout_start(), but callout_reset() will just reschedule > a callout if it's already pending. The consumer of the callout can > maintain his own side state that he can check in his callout to handle a > state change in between scheduling the callout and the callout running. Yes, right, but I want this state variable checking to be centralized. On the spark I can think of the following two situations where the state must always be checked: - before calling a callback (like d_read / d_write / d_ioctl / timeouts / usbd_callback ... ) - after returning from sleep > > Now consider my proposal. There is no more need for > > dev_refthread/dev_relthread. Instead the callback, "d_read()" will do the > > checking. This consist of: > > > > d_read() > > { > > mtx_lock(args->mtx); > > > > if(args->refcount_copy == atomic_read(args->refcount_p)) > > { > > /* valid */ > > } > > > > mtx_unlock(args->mtx); > > > > return; > > } > > > > Per "devfs_read_f()" one has got to lock/unlock one time. It involves two > > refcount reads and no refcount writes. > > > > Well, isn't this 200 percent faster? > > Maybe, but another thing you need to consider is "maintainenance" overhead. > Device drivers, especially, should be the simplest parts of the kernel to > implement because we want to minimize the potential for screw up in that > area. Having to trust that the same code is going to be duplicated 40 or > 50 times without any errors versus having it done once in a centralized > place where it breaks everyone if it is broken is just insane. Otherwise, > we might as well go write the whole kernel in assembly so we can tweak > every last bit out of it. :) Yes, you are right, but the problem is, that for most callback systems in the kernel, there is no mechanism that will pre-lock some custom mutex before calling the callback. I am not speaking about adding lines to existing code, but to add one extra parameter to the setup functions, where the mutex that should be locked before calling the callback(s) can be specified. If it is NULL, Giant will be used. The setup functions I have in mind are for example: "make_dev()", "bus_setup_intr()", "callout_reset()" ... and in general all callback systems that look like these. OLD: make_dev(devsw, minor, uid, gid, perms, fmt...) NEW: make_dev(devsw, mtx, minor, uid, gid, perms, fmt...) This increment only refcount system that I want, will be setup automatically by the setup functions, and code is saved in the device drivers. Destruction functions will increment the refcount and so invalidate the old copies of the refcounts, all centralized. Here is my idea of how this can be implemented for the filesystem mounted on /dev : Struct cdev will have a new field of type callback_args: struct cdev { ... struct callback_args si_callback_args; ... }; Maybe we can trim down the callback_args structure to something like this: And maybe we can pick a better name for it. struct callback_args { struct mtx *mtx; u_int32_t *p_refcount; u_int32_t refcount; }; To update the kernel you make a simple script that searches for "make_dev()" and adds one NULL parameters after the first parameter. Look over all the subsitutions to catch any exceptions and that is it. Update the manual. We don't have to rewrite any drivers at all. Keep the code like it is, no changes are needed at all!!! Then one has to update "devfs_read_f()": devfs_read_f() { This first part should be done once, and the result should be stored in some file descriptor that is owned by the thread and needs no locking. mtx_lock(global); struct callback_args cba = dev->si_callback_args; mtx_unlock(global); This is the second part, and as a good rule, the caller is doing the locking. There is only one problem and that is that the callback can call tsleep/msleep. So what we do here is that we extend "struct thread" to contain another field, "struct callback_args *td_cba_p", which we use to pass a hint to tsleep/msleep, about that we are holding a lock: mtx_lock(cba.mtx); if(cba.refcount_copy == atomic_read(cba.refcount_p)) { /* valid */ curthread->td_cba_p = &cba; /* pass hint to next tsleep/msleep */ error = xxx->d_read(); if(curthread->td_cba_p == NULL) { return error; /* lock already exited */ } curthread->td_cba_p = NULL; } else { error = ENXIO; } mtx_unlock(cba.mtx); return error; } Then we have to update msleep(): int new_msleep() { struct callback_args *args = curthread->td_cba_p; int error; if(args) { /* we are holding a lock that we need to exit */ error = old_msleep(... &args->mtx ...); /* here we can save a lot of code by checking * that things are still present like when called, * before returning ! */ if(args->refcount_copy == atomic_read(args->refcount_p)) { // EGONE is a new error enum, that serves this // special case only // error = EGONE; } } else { error = old_msleep(); } return error; } Another consequence of this is that our device driver does not have to contain a single line about "mtx_lock()"/"mtx_unlock()". And then one is saved the worries about having to exit a lock before returning. my_read() { int error; error = tsleep() Look at this. Here we can handle signal interruption, tsleep timeout and device removal in a single check. if(error) return error; return 0; } Then we can also call uiomove() without haveing to worry about exiting any locks. And if anything goes wrong, copyout() will return EGONE, and the function is no longer accessing any freed memory. Holding a lock while calling uiomove() should be allowed, because the lock is preventing the memory uiomove() is writing to/from, from beeing freed. Then one can actually call any function that can sleep, without worrying about exiting any locks. The only thing is that we have to make a note that these functions can exit the currently held lock or maybe we should specify currently active "callback_args". So this is just backwards: mtx_unlock(); ptr = malloc(); mtx_lock(); In 99 percent of the cases malloc will never sleep, and if the call takes some time, we pass a hint to malloc and to this unlock-/lock-ing centralized. That makes the code cleaner. Now how about this: ptr = malloc(); if(ptr == NULL) { /* no memory or EGONE */ if(check_refcount(curthread) == OK) { we can still access any softc } else { just return, nothing more to do } } But in the general case I assume that one can just return immediately if one didn't get the memory that was needed, assuming that the destructor will clean up the softc, hence we are exiting in the middle of a program, with perhaps loose ends. If the malloc() routine finds out that it has to do a lengthy memory search, then it can exit the callback arguments pointed to by "curthread->td_cba_p" and enter those arguments again, checking the refcount, before returning. This way we will never see a single line of mtx_lock/mtx_unlock in the code, in most cases. Well, is it not better to have locking centralized, than decentralized: The functions that sleep must exit/enter the callback args by default. So what do you think about this way of allowing us to hold locks while calling functions that can sleep? Assuming there are "n" callbacks in the kernel. Then there is "2*n" too many lock/unlock lines in the kernel, than strictly necessary. That is a rough calculation. The number might be a little lower, hence not all callbacks need locking. What do you think about having this "check some value before proceeding" also when returning from sleep, centralized? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 04:21:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E43416A41F; Sat, 6 Aug 2005 04:21:17 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE90F43D48; Sat, 6 Aug 2005 04:21:16 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j764LFgl022380; Fri, 5 Aug 2005 23:21:15 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F43AAD.2080208@centtech.com> Date: Fri, 05 Aug 2005 23:21:01 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <42E9A0E7.40703@centtech.com> <42EB9005.8080200@gamersimpact.com> In-Reply-To: <42EB9005.8080200@gamersimpact.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1003/Thu Aug 4 09:43:24 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture 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, 06 Aug 2005 04:21:17 -0000 Ryan Sommers wrote: > Eric Anderson wrote: > >> I've very interested in learning about FreeBSD's implementation of >> vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter >> in the Design and Implmentation of FreeBSD book, and I've read the >> UNIX Filesystems book cover to cover. >> >> What I'd like to see/read/understand, is how FreeBSD in particular is >> put together in this regard, and then I'd like to go about writing a >> very very simple filesystem as a learning excercise. >> >> Can anyone give me some pointers? Would anyone be willing to guide me >> along in my quest by answering questions (off list if preferred, or on >> list), etc? >> >> Thanks in advance for the hints/input! >> Eric >> >> > > Best place would be the source code itself. I think the nullfs > implementation would be a good place (src/sys/fs/nullfs). I thought I > also remembered some little article on writing an FS for freebsd, > finding it is eluding me though. Thanks - I've begun tinkering with a copy of nullfs. If you can find that article, please let me know - I've looked and still cannot track it down. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 04:21:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 623E916A41F; Sat, 6 Aug 2005 04:21:31 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E241243D49; Sat, 6 Aug 2005 04:21:30 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j764Jt7h098313; Fri, 5 Aug 2005 23:20:00 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F43A5D.8050608@centtech.com> Date: Fri, 05 Aug 2005 23:19:41 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALeine References: <200507300642.j6U6ghCF057455@marlena.vvi.at> In-Reply-To: <200507300642.j6U6ghCF057455@marlena.vvi.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture 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, 06 Aug 2005 04:21:31 -0000 ALeine wrote: > Eric Anderson wrote: > >>I've very interested in learning about FreeBSD's implementation >>of vfs/buffer cache/fs archicture. > > > You may want to download the following graphical overview of the > UFS/FFS filesystem that was made by Poul-Henning Kamp earlier > this year, it's very useful: > > http://phk.freebsd.dk/misc/ufs.pdf > > If you want to print it out you'll need 18 sheets of paper. Oh my - that is quite impressive.. phk - thank you! I can't wait to print that out.. (I even wonder if it was generated automatically?) > You may also want to use something like doxygen (devel/doxygen in the > ports tree) to generate source code graphs and make browsing through > source code easier. Another resource that you may find helpful is > Robert Watson's FXR site: > > http://fxr.watson.org I've played with that a bit - quite useful. Thanks for the reminder of it. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 04:24:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF28F16A41F; Sat, 6 Aug 2005 04:24:11 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BB0D43D45; Sat, 6 Aug 2005 04:24:11 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j764NiSR098391; Fri, 5 Aug 2005 23:23:49 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F43B43.9010205@centtech.com> Date: Fri, 05 Aug 2005 23:23:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yfyoufeng@263.net References: <42E9A0E7.40703@centtech.com> <42EB9005.8080200@gamersimpact.com> <1122889920.2885.2.camel@localhost.localdomain> In-Reply-To: <1122889920.2885.2.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture 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, 06 Aug 2005 04:24:12 -0000 yf-263 wrote: > =E5=9C=A8 2005-07-30=E5=85=AD=E7=9A=84 09:34 -0500=EF=BC=8CRyan Sommers= =E5=86=99=E9=81=93=EF=BC=9A >=20 >>Eric Anderson wrote: >> >>>I've very interested in learning about FreeBSD's implementation of=20 >>>vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter= =20 >>>in the Design and Implmentation of FreeBSD book, and I've read the UNI= X=20 >>>Filesystems book cover to cover. >>> >>>What I'd like to see/read/understand, is how FreeBSD in particular is = >>>put together in this regard, and then I'd like to go about writing a=20 >>>very very simple filesystem as a learning excercise. >>> >>>Can anyone give me some pointers? Would anyone be willing to guide me= =20 >>>along in my quest by answering questions (off list if preferred, or on= =20 >>>list), etc? >>> >>>Thanks in advance for the hints/input! >>>Eric >>> >>> >> >>Best place would be the source code itself. I think the nullfs=20 >>implementation would be a good place (src/sys/fs/nullfs). I thought I=20 >>also remembered some little article on writing an FS for freebsd,=20 >>finding it is eluding me though. >=20 >=20 > I'm also doing the same work. Now I'm working on port our data access > library into the FreeBSD kernel space as a vnode hooks. Hope we can hel= p > each others :) Excellent! I'm looking forward to seeing some alpha code to play with :)= I'm still in the R&D mode myself. Eric --=20 ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 05:53:16 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC10716A41F for ; Sat, 6 Aug 2005 05:53:16 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 3FF6843D55 for ; Sat, 6 Aug 2005 05:53:16 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 52733 invoked by uid 399); 6 Aug 2005 05:53:15 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 6 Aug 2005 05:53:15 -0000 Received: (qmail 6126 invoked by uid 399); 6 Aug 2005 05:53:13 -0000 Received: from unknown (HELO ?192.168.1.101?) (dougb@dougbarton.net@69.175.228.47) by mail1.fluidhosting.com with SMTP; 6 Aug 2005 05:53:13 -0000 Message-ID: <42F45048.1070606@FreeBSD.org> Date: Fri, 05 Aug 2005 22:53:12 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD-* files in non-HEAD branches 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, 06 Aug 2005 05:53:17 -0000 Howdy, I'm wondering what the utility of files like FREEBSD-Upgrade and FREEBSD-Xlist which describe how to import stuff in src/contrib in branches other than HEAD. It makes sense to me to remove these files in other brakes, opinions? Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 07:00:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3334016A41F for ; Sat, 6 Aug 2005 07:00:08 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBCE143D45 for ; Sat, 6 Aug 2005 07:00:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 7C9BB208DB4; Sat, 6 Aug 2005 00:00:07 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j76706P3070849; Sat, 6 Aug 2005 00:00:07 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42F45FEE.6050601@elischer.org> Date: Fri, 05 Aug 2005 23:59:58 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: hselasky@c2i.net References: <200508030023.04748.hselasky@c2i.net> <200508042253.34165.hselasky@c2i.net> <200508051329.14767.jhb@FreeBSD.org> <200508060139.57143.hselasky@c2i.net> In-Reply-To: <200508060139.57143.hselasky@c2i.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking 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, 06 Aug 2005 07:00:08 -0000 Hans Petter Selasky wrote: > On Friday 05 August 2005 19:29, John Baldwin wrote: > > > Yes, you are right, but the problem is, that for most callback systems in the > kernel, there is no mechanism that will pre-lock some custom mutex before > calling the callback. Not generally applicable to this case but for example the netgraph callout wrappers handlle netgraph node locking so that teh called function can assume the node it is working on has been locked. It's not applicable because netgraph locking is "different" to locking elsewhere in the kernel due to the nature of netgraph. But havinng a specific callout wrapper for a subsystem does give the ability to do such things. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 07:04:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EF1316A41F for ; Sat, 6 Aug 2005 07:04:09 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E772A43D46 for ; Sat, 6 Aug 2005 07:04:08 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id D2FAEC0AA; Sat, 6 Aug 2005 09:04:07 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id AD614405B; Sat, 6 Aug 2005 09:04:23 +0200 (CEST) Date: Sat, 6 Aug 2005 09:04:23 +0200 From: Jeremie Le Hen To: "Thordur I. Bjornsson" Message-ID: <20050806070422.GW45385@obiwan.tataz.chchile.org> References: <20050805005543.5bd947f2.thib@mi.is> <20050805145046.GB78669@dan.emsphone.com> <42F386B2.1010108@samsco.org> <20050805160415.44b0b05e.thib@mi.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050805160415.44b0b05e.thib@mi.is> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: Checking sysctl values from within the kernel. 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, 06 Aug 2005 07:04:09 -0000 Hi Thordur, > PS: If you don't mind, what is a "real accessor function" ? This is a function acting as a wrapper for accessing an integer declared as static. This function must of course live in the same file. This may be something like this, there may exist neater interfaces though : static int age; int age_accessor(int *get, int set) { if (get != NULL) *get = age; else if (set < 0 || set > 125) return -1; else age = set; return 0; } If `get' is not NULL, this means the caller wants to retrieve the current age value. Else, this means the caller wants to set the age value to a new one : if the latter is lower than 0 and greater than 125, this is an incredible age and the accessor reports an error. Else it sets the new value. I hope this helped. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 09:34:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68F5416A41F; Sat, 6 Aug 2005 09:34:52 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5D9C43D45; Sat, 6 Aug 2005 09:34:51 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j769Yo1P074154; Sat, 6 Aug 2005 12:34:50 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 34506-07; Sat, 6 Aug 2005 12:34:50 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j769YnJs074151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Aug 2005 12:34:50 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j769YnHu026819; Sat, 6 Aug 2005 12:34:49 +0300 (EEST) (envelope-from ru) Date: Sat, 6 Aug 2005 12:34:49 +0300 From: Ruslan Ermilov To: Doug Barton Message-ID: <20050806093449.GH48504@ip.net.ua> References: <42F45048.1070606@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6BvahUXLYAruDZOj" Content-Disposition: inline In-Reply-To: <42F45048.1070606@FreeBSD.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD-* files in non-HEAD branches 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, 06 Aug 2005 09:34:52 -0000 --6BvahUXLYAruDZOj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Aug 05, 2005 at 10:53:12PM -0700, Doug Barton wrote: > I'm wondering what the utility of files like FREEBSD-Upgrade and=20 > FREEBSD-Xlist which describe how to import stuff in src/contrib in branch= es=20 > other than HEAD. It makes sense to me to remove these files in other=20 > brakes, opinions? >=20 At least is makes it easy to view diffs between branches. I'd prefer it if you don't remove them from src/contrib/groff/ and src/contrib/texinfo/ at least that I maintain. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --6BvahUXLYAruDZOj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC9IQ5qRfpzJluFF4RAqXKAKCWnL3lRWv2lhvNN0Dmfnq21CvBVQCfY9wa Ya4/R2nnigWzzm1crrRMyWc= =esfE -----END PGP SIGNATURE----- --6BvahUXLYAruDZOj-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 09:58:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2324416A41F for ; Sat, 6 Aug 2005 09:58:53 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 5086143D46 for ; Sat, 6 Aug 2005 09:58:52 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 68744 invoked by uid 399); 6 Aug 2005 09:58:51 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 6 Aug 2005 09:58:51 -0000 Received: (qmail 27004 invoked by uid 399); 6 Aug 2005 09:58:51 -0000 Received: from unknown (HELO ?192.168.1.101?) (dougb@dougbarton.net@69.175.228.47) by mail1.fluidhosting.com with SMTP; 6 Aug 2005 09:58:51 -0000 Message-ID: <42F489D5.9070405@FreeBSD.org> Date: Sat, 06 Aug 2005 02:58:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <42F45048.1070606@FreeBSD.org> <20050806093449.GH48504@ip.net.ua> In-Reply-To: <20050806093449.GH48504@ip.net.ua> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD-* files in non-HEAD branches 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, 06 Aug 2005 09:58:53 -0000 Ruslan Ermilov wrote: > Hi, > > On Fri, Aug 05, 2005 at 10:53:12PM -0700, Doug Barton wrote: > >>I'm wondering what the utility of files like FREEBSD-Upgrade and >>FREEBSD-Xlist which describe how to import stuff in src/contrib in branches >>other than HEAD. It makes sense to me to remove these files in other >>brakes, opinions? >> > > At least is makes it easy to view diffs between branches. I'd > prefer it if you don't remove them from src/contrib/groff/ and > src/contrib/texinfo/ at least that I maintain. Sorry I wasn't clear, I am only considering removing them from src/contrib/bind9. I wouldn't remove them in other people's areas. Doug From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 11:49:39 2005 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70C8716A41F for ; Sat, 6 Aug 2005 11:49:39 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED6643D5F for ; Sat, 6 Aug 2005 11:49:38 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j76BnaTW023130 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 6 Aug 2005 21:49:36 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j76BnaSR007822 for ; Sat, 6 Aug 2005 21:49:36 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j76BnaED007821 for hackers@FreeBSD.org; Sat, 6 Aug 2005 21:49:36 +1000 (EST) (envelope-from pjeremy) Date: Sat, 6 Aug 2005 21:49:36 +1000 From: Peter Jeremy To: hackers@FreeBSD.org Message-ID: <20050806114935.GB7708@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: Finding an illegal instruction in gnucash/guile 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, 06 Aug 2005 11:49:39 -0000 I recently upgraded gnucash and dependencies and am now getting SIGILL during startup. This originally occurred on 5.3 but I'm getting exactly the same thing running on a recent -CURRENT with a freshly built (from scratch) ports tree. I've tried running gdb on the core dump but the results suggest that gdb is confused. Definitely there's no illegal instruction at the claimed location, though the backtrace doesn't appear trustable (and ISTR that gdb is a bit dodgy on threaded programs). gdb claims the problem is in libguile. I've tried rebuilding it with different CPU and optimisation options (in case I've triggered a gcc bug) but the SIGILL remains. I've had a look through google and not found anything relevant. Does anyone have any suggestions other than rebuilding the ports from scratch with different CPUTYPE and/or CFLAGS? (I'm currently using CPUTYPE=athlon-xp and CFLAGS=-O -g). -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 16:02:21 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9DB416A41F for ; Fri, 5 Aug 2005 16:02:21 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC5743D46 for ; Fri, 5 Aug 2005 16:02:21 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id j75G2KtU004273; Fri, 5 Aug 2005 09:02:20 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j75G2JUx004272; Fri, 5 Aug 2005 09:02:19 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Aug 2005 09:02:19 -0700 From: Steve Kargl To: Denis Antrushin Message-ID: <20050805160219.GB4147@troutmask.apl.washington.edu> References: <20050804150405.GA95916@troutmask.apl.washington.edu> <42F36675.2090602@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F36675.2090602@mail.ru> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Sat, 06 Aug 2005 11:50:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 16:02:22 -0000 On Fri, Aug 05, 2005 at 05:15:33PM +0400, Denis Antrushin wrote: > Steve Kargl wrote: > >Can someone confirm or refute that the working number > >of bits in the significand of long double type is 53 > >on i386? > > > > Yes, this is what IEEE 754 requires. > (See http://docs.sun.com/source/806-3568/ncg_goldberg.html, > section 'The IEEE Standard') > BZZZT. You're not even close to correct. See Table 1 in the IEEE 754 standard and then read section 3.4. -- Steve From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 17:01:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8881216A41F for ; Fri, 5 Aug 2005 17:01:58 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 236BB43D48 for ; Fri, 5 Aug 2005 17:01:58 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id j75H1vJB004760; Fri, 5 Aug 2005 10:01:57 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j75H1vKk004759; Fri, 5 Aug 2005 10:01:57 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Aug 2005 10:01:57 -0700 From: Steve Kargl To: Denis Antrushin Message-ID: <20050805170157.GD4147@troutmask.apl.washington.edu> References: <20050804150405.GA95916@troutmask.apl.washington.edu> <42F36675.2090602@mail.ru> <20050805160219.GB4147@troutmask.apl.washington.edu> <42F395D8.5020200@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F395D8.5020200@mail.ru> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Sat, 06 Aug 2005 11:50:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 17:01:58 -0000 On Fri, Aug 05, 2005 at 08:37:44PM +0400, Denis Antrushin wrote: > Steve Kargl wrote: > >On Fri, Aug 05, 2005 at 05:15:33PM +0400, Denis Antrushin wrote: > > > >>Steve Kargl wrote: > >> > >>>Can someone confirm or refute that the working number > >>>of bits in the significand of long double type is 53 > >>>on i386? > >>> > >> > >>Yes, this is what IEEE 754 requires. > >>(See http://docs.sun.com/source/806-3568/ncg_goldberg.html, > >>section 'The IEEE Standard') > >> > > > >BZZZT. > > > >You're not even close to correct. See Table 1 in the IEEE > >754 standard and then read section 3.4. > > > > Well, you know the answer then ;-) I know what IEEE-754 specifies. I don't know what FreeBSD implements. In particular, float.h misrepresents long double on i386. -- Steve From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 18:01:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5129C16A41F for ; Fri, 5 Aug 2005 18:01:02 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 150E1442D2 for ; Fri, 5 Aug 2005 17:48:39 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id j75Hmahw005054; Fri, 5 Aug 2005 10:48:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j75Hmaec005053; Fri, 5 Aug 2005 10:48:36 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Aug 2005 10:48:36 -0700 From: Steve Kargl To: "M. Warner Losh" Message-ID: <20050805174836.GA4906@troutmask.apl.washington.edu> References: <20050804150405.GA95916@troutmask.apl.washington.edu> <20050805.113335.27815012.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050805.113335.27815012.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Sat, 06 Aug 2005 11:50:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Number of significand bits in long double? 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, 05 Aug 2005 18:01:05 -0000 On Fri, Aug 05, 2005 at 11:33:35AM -0600, M. Warner Losh wrote: > In message: <20050804150405.GA95916@troutmask.apl.washington.edu> > Steve Kargl writes: > : Can someone confirm or refute that the working number > : of bits in the significand of long double type is 53 > : on i386? > > The number of bits is 53. However, you can get more bits by adding a > fpsetprec(FP_PE) at the start of the programs. Otherwise, you get > FP_PD by default. Once you do that, things seem to basically work, > but I've not run paranoia.c to make sure. > I'm writing some of the missing C99 long double math functions (to be contributes to FreeBSD). The code assumes 64 bits in the approximations that I'm using. When I try to run test programs to check the accuracy of my implementations against GMP/MPFR ouput, I can't trust the values of LDBL_* reported from float.h. My test programs now include #ifdef AMD64 #define BITSL 64 #define DIGSL 18 #else #define BITSL 53 #define DIGSL 15 #endif instead of #include and the use of LDBL_MANT_DIG and LDBL_DIG. -- Steve From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 09:50:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 262A916A41F for ; Sat, 6 Aug 2005 09:50:37 +0000 (GMT) (envelope-from aw@aw.gs) Received: from mariah.narpes.com (mariah.narpes.com [213.250.81.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90AD143D48 for ; Sat, 6 Aug 2005 09:50:36 +0000 (GMT) (envelope-from aw@aw.gs) Received: from dynamite.narpes.com ([193.22.86.8]) by mariah.narpes.com with esmtp (Exim 4.30) id 1E1LK3-0005xs-Qv for freebsd-hackers@freebsd.org; Sat, 06 Aug 2005 09:50:31 +0000 Received: from localhost ([127.0.0.1]) by dynamite.narpes.com with esmtp (Exim 4.43) id 1E1LK2-0005LL-B9 for freebsd-hackers@freebsd.org; Sat, 06 Aug 2005 09:50:30 +0000 Date: Sat, 6 Aug 2005 09:50:29 +0000 (GMT) From: "A. Wik" To: freebsd-hackers@freebsd.org Message-ID: <20050806084910.N13128@dynamite.narpes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 06 Aug 2005 11:50:05 +0000 Subject: SB 3DSE ioctl() patch 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, 06 Aug 2005 09:50:37 -0000 (This was originally addressed to Cameron Grant, the author of the files I modified. Unfortunately, my message bounced, and shortly thereafter, I learned that he passed away earlier this year [1]. I hope this forum is an appropriate alternative.) [1] http://lists.nycbug.org/pipermail/talk/2005-March/005014.html **** Hello, I just installed a Soundblaster 16 (DSP v4.16) in my FreeBSD machine, and found no way to enable the 3D stereo enhancement feature that the Linux, DOS and Win9x drivers support. So I looked at the Linux driver sources and decided to add a compatible mixer ioctl() to the FreeBSD driver. That turned out to be a lot more complicated than expected, because there was no existing interface for this kind of hardware-specific ioctls. After extensive reverse-engineering of the FreeBSD driver model (studying the UART and TTY drivers was particularly helpful), and adding a method to the mixer interface, I managed to implement the feature, at least to the extent that it works for me. Perhaps you could take a look at the patch to verify that it doesn't break anything, and consider adding it to the mainstream kernel? The patch and a utility for testing it is available from my FTP site: ftp://vax.narpes.com/users/aw/freebsd-5.3-aw-3dse.diff ftp://vax.narpes.com/users/aw/s3dioctl.c Regards, A. Wik From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 11:43:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B60C516A41F for ; Sat, 6 Aug 2005 11:43:02 +0000 (GMT) (envelope-from mtran@groupwise.swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id F293343D82 for ; Sat, 6 Aug 2005 11:43:01 +0000 (GMT) (envelope-from mtran@groupwise.swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.217]) by mailmonitor.cc.swin.edu.au with NetIQ MailMarshal (v6, 0, 3, 8) id ; Sat, 06 Aug 2005 21:42:59 +1000 Received: from INET-DOM-MTA by groupwise.swin.edu.au with Novell_GroupWise; Sat, 06 Aug 2005 21:42:59 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Sat, 06 Aug 2005 21:42:44 +1000 From: "Minh Tran" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Sat, 06 Aug 2005 11:50:05 +0000 Subject: Kernel code of reseting/ignoring tcp SYN packets 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, 06 Aug 2005 11:43:02 -0000 ** Reply Requested When Convenient ** Hi everyone, I was looking around for the files of Kernel code where SYN messages are = sent, so we can simply inject some code to send back a reset messages or ignore= =20the SYN requests. I was looking at the function ioctl() which takes fd of the tcp socket.=20 As i track the function down, there is also another call to the dev_ioclt= () function where all parameters are passed down.=20 However, i was not sucessful with finding out the description of this dev= _ioclt() function.=20 I am having a bit of trouble in finding out the way of injecting code in = the kernel to deal with SYN packets.=20 I am thinking of using ipfw to either reset or drop SYN packets. Would anyone have some hints on the clean way of injecting some code to d= eal with SYN packets=20 or could you give me some ideas on which files i should look at? I really= =20appreciate that. I saw some promising files in src/sys/netinet but they are not all clear = in my mind. Thanks heaps! Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for th= e use of the addressee. They may contain information that is privileged o= r protected by copyright. If you are not the intended recipient, any diss= emination, distribution, printing, copying or use is strictly prohibited.= =20The University does not warrant that this e-mail and any attachments a= re secure and there is also a risk that it may be corrupted in transmissi= on. It is your responsibility to check any attachments for viruses or def= ects before opening them. If you have received this transmission in error= , please contact us on +61 3 9214 8000 and delete it immediately from you= r system. We do not accept liability in connection with computer virus, d= ata corruption, delay, interruption, unauthorised access or unauthorised = amendment. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 12:20:18 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E356416A41F for ; Sat, 6 Aug 2005 12:20:18 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from alice.et.bocholt.fh-gelsenkirchen.de (alice.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4117943D53 for ; Sat, 6 Aug 2005 12:20:13 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from musashi.et.bocholt.fh-gelsenkirchen.de (musashi.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) by alice.et.bocholt.fh-gelsenkirchen.de (8.12.9/8.12.9) with ESMTP id j76CKAeD021244 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 6 Aug 2005 14:20:11 +0200 Received: from sora.hank.home ([10.8.0.6]) by musashi.et.bocholt.fh-gelsenkirchen.de (8.13.3/8.13.3) with ESMTP id j76CK9kD046619; Sat, 6 Aug 2005 14:20:10 +0200 (CEST) (envelope-from hank@et.bocholt.fh-gelsenkirchen.de) Received: from localhost (localhost.hank.home [127.0.0.1]) by sora.hank.home (8.13.3/8.13.3) with ESMTP id j76CLexZ008206; Sat, 6 Aug 2005 14:21:40 +0200 (CEST) (envelope-from hank@sora.hank.home) Message-Id: <200508061221.j76CLexZ008206@sora.hank.home> To: Peter Jeremy In-Reply-To: Message from Peter Jeremy of "Sat, 06 Aug 2005 21:49:36 +1000." <20050806114935.GB7708@cirb503493.alcatel.com.au> Date: Sat, 06 Aug 2005 14:21:40 +0200 From: Dirk GOUDERS X-Scanned-By: MIMEDefang 2.43 Cc: hackers@freebsd.org Subject: Re: Finding an illegal instruction in gnucash/guile 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, 06 Aug 2005 12:20:19 -0000 > gdb claims the problem is in libguile. I've tried rebuilding it with > different CPU and optimisation options (in case I've triggered a gcc > bug) but the SIGILL remains. > > I've had a look through google and not found anything relevant. > > Does anyone have any suggestions other than rebuilding the ports from > scratch with different CPUTYPE and/or CFLAGS? (I'm currently using > CPUTYPE=athlon-xp and CFLAGS=-O -g). I had a similar (if not the same) problem on a 4.11-STABLE machine. Actually, I am running gnucash on two different 4.11-STABLE machines -- on one, it worked, on the other, where I installed it some days ago it didn't. Then, I cvsup'ed both machines and the first port I installed on both was gnucash (the only difference betweeen the two machines was the order the ports were installed) and now, it works on both machines. This information seemed too few to me to file a PR but maybe it helps you. Dirk From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 12:53:26 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E7C916A41F for ; Sat, 6 Aug 2005 12:53:26 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF5043D46 for ; Sat, 6 Aug 2005 12:53:25 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id D8F84C06E for ; Sat, 6 Aug 2005 14:53:24 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 0435D405B; Sat, 6 Aug 2005 14:53:40 +0200 (CEST) Date: Sat, 6 Aug 2005 14:53:40 +0200 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Message-ID: <20050806125340.GA45385@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: sed s///i 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, 06 Aug 2005 12:53:26 -0000 Hi, I would like to implement the 'i' flag for the 's' command in sed(1). This flag would mean that the match must be case insensitive. I'm not willing to implement this to conform to GNU sed(1), I just find it very handy : s/[Ff][Oo][Oo]/bar/ would become s/foo/bar/i Before I start modifying the code, I would like if it is something that has chances to get commited or not, although SUSv3 doesn't talk about this flag. I also need to add that this change would be a little intrusive in the code. Actually the regular expression gets compiled, then the substitute string and finally flags are handled. Thus this would require scanning flags before compiling the regular expression. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 14:54:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D497B16A41F for ; Sat, 6 Aug 2005 14:54:34 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1D08943D46 for ; Sat, 6 Aug 2005 14:54:33 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail invoked by alias); 06 Aug 2005 14:54:32 -0000 Received: from p54A44075.dip0.t-ipconnect.de (EHLO [192.168.1.35]) [84.164.64.117] by mail.gmx.net (mp024) with SMTP; 06 Aug 2005 16:54:32 +0200 X-Authenticated: #1954550 Message-ID: <42F4CF1D.5000501@gmx.de> Date: Sat, 06 Aug 2005 16:54:21 +0200 From: "Philip S. Schulz" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------010500080506060201080403" X-Y-GMX-Trusted: 0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pthreads problem 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, 06 Aug 2005 14:54:35 -0000 This is a multi-part message in MIME format. --------------010500080506060201080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! From the what's-wrong-with-my-code department... I'm having trouble with two threads accessing a queue. One thread writes to it while the other one reads from the queue. I'd like the consumer to run until the main thread (which is the producer) decides that the consumer thread should exit. Let me show you some example code to illustrate what I'm currently doing. The consumer runs in an endless loop until it is being cancelled by the main thread using pthread_cancel(): void *thread_routine(void *args) { while (1) { pthread_mutex_lock(&m); if (len == 0) pthread_cond_wait(¬empty, &m); printf("consumer: %i\n", --len); pthread_cond_signal(¬full); if (len == 0) pthread_cond_signal(&isempty); pthread_mutex_unlock(&m); } return (NULL); } I belive the only cancellation point here is pthread_cond_wait(), so the main thread cancels the consumer while it is waiting on the notempty condition and the mutex m will not be destroyable. pthread_mutex_lock(&m); if (len > 0) { printf("Waiting for consumer...\n"); pthread_cond_wait(&isempty, &m); } pthread_mutex_unlock(&m); pthread_cancel(t); pthread_join(t, NULL); pthread_cond_destroy(¬full); pthread_cond_destroy(¬empty); pthread_cond_destroy(&isempty); error = pthread_mutex_destroy(&m); if (error) printf("%s\n", strerror(error)); If the main thread holds the mutex over both the pthread_cancel() and pthread_join() calls, a deadlock occurs where the consumer waits on the notempty condition and the main thread waits on the consumer: pthread_cancel(t); pthread_join(t, NULL); pthread_mutex_unlock(&m); So, what is the best way to solve this problem? Introduce a variable for the while-loop like "while (running) { .. }"? Have the consumer poll if there is data in the queue? I hope somebody can help me. TIA, Phil. P.S:: Attached is the full example. --------------010500080506060201080403-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 14:59:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52A6B16A41F for ; Sat, 6 Aug 2005 14:59:54 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C6A3243D49 for ; Sat, 6 Aug 2005 14:59:53 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail invoked by alias); 06 Aug 2005 14:59:52 -0000 Received: from p54A44075.dip0.t-ipconnect.de (EHLO [192.168.1.35]) [84.164.64.117] by mail.gmx.net (mp010) with SMTP; 06 Aug 2005 16:59:52 +0200 X-Authenticated: #1954550 Message-ID: <42F4D05F.9020807@gmx.de> Date: Sat, 06 Aug 2005 16:59:43 +0200 From: "Philip S. Schulz" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Philip S. Schulz" References: <42F4CF1D.5000501@gmx.de> In-Reply-To: <42F4CF1D.5000501@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org Subject: Re: pthreads problem 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, 06 Aug 2005 14:59:54 -0000 Philip S. Schulz wrote: > > P.S:: Attached is the full example. > Oh, well, apparently I'm too dumb to use my mail reader correctly... it is at http://aliue.homeunix.net:8000/threads.c Phil. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 16:02:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EB9016A41F for ; Sat, 6 Aug 2005 16:02:20 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 939BB43D69 for ; Sat, 6 Aug 2005 16:02:18 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 6 Aug 2005 17:02:16 +0100 (IST) To: hselasky@c2i.net In-Reply-To: Your message of "Sat, 06 Aug 2005 01:39:55 +0200." <200508060139.57143.hselasky@c2i.net> Date: Sat, 06 Aug 2005 17:02:16 +0100 From: Ian Dowse Message-ID: <200508061702.aa50464@nowhere.iedowse.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How to do proper locking 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, 06 Aug 2005 16:02:20 -0000 In message <200508060139.57143.hselasky@c2i.net>, Hans Petter Selasky writes: >Yes, you are right, but the problem is, that for most callback systems in the >kernel, there is no mechanism that will pre-lock some custom mutex before >calling the callback. > >I am not speaking about adding lines to existing code, but to add one extra >parameter to the setup functions, where the mutex that should be locked >before calling the callback(s) can be specified. If it is NULL, Giant will be >used. > >The setup functions I have in mind are for example: "make_dev()", >"bus_setup_intr()", "callout_reset()" ... and in general all callback systems >that look like these. Note that FreeBSD's callout subsystem does already have such a mechanism. Just use callout_init_mtx() and the specified mutex will be acquired before the callback is invoked. See callout(9) for more details. Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 19:37:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24AC716A41F for ; Sat, 6 Aug 2005 19:37:46 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 924FE43D46 for ; Sat, 6 Aug 2005 19:37:45 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 80273 invoked from network); 6 Aug 2005 19:37:44 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 6 Aug 2005 19:37:44 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 6 Aug 2005 14:37:42 -0500 (CDT) From: Mike Silbersack To: Minh Tran In-Reply-To: Message-ID: <20050806143524.S835@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel code of reseting/ignoring tcp SYN packets 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, 06 Aug 2005 19:37:46 -0000 On Sat, 6 Aug 2005, Minh Tran wrote: > Would anyone have some hints on the clean way of injecting some code to deal with SYN packets > or could you give me some ideas on which files i should look at? I really appreciate that. > I saw some promising files in src/sys/netinet but they are not all clear in my mind. > > Thanks heaps! I don't have any idea what you are asking, so I can't answer your question. Before proceeding, it would probably be worth your while to find a copy of Stevens's TCP/IP Illustrated Volume 2 and at least skim it so that you have a better idea of how the connection establishment process works. The book describes an earlier version of the BSD TCP/IP stack, but much still applies. Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 6 21:04:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2F0A16A420 for ; Sat, 6 Aug 2005 21:04:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D81143D46 for ; Sat, 6 Aug 2005 21:04:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id A2D0146B81; Sat, 6 Aug 2005 17:04:07 -0400 (EDT) Date: Sat, 6 Aug 2005 22:06:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Minh Tran In-Reply-To: Message-ID: <20050806220421.A11054@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel code of reseting/ignoring tcp SYN packets 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, 06 Aug 2005 21:04:08 -0000 On Sat, 6 Aug 2005, Minh Tran wrote: > I was looking around for the files of Kernel code where SYN messages are > sent, so we can simply inject some code to send back a reset messages or > ignore the SYN requests. I was looking at the function ioctl() which > takes fd of the tcp socket. As i track the function down, there is also > another call to the dev_ioclt() function where all parameters are passed > down. However, i was not sucessful with finding out the description of > this dev_ioclt() function. I am having a bit of trouble in finding out > the way of injecting code in the kernel to deal with SYN packets. I am > thinking of using ipfw to either reset or drop SYN packets. > > Would anyone have some hints on the clean way of injecting some code to > deal with SYN packets or could you give me some ideas on which files i > should look at? I really appreciate that. I saw some promising files in > src/sys/netinet but they are not all clear in my mind. TCP packet input processing occurs in src/sys/netinet/tcp_input.c:tcp_input(). This is a very large function, so you will want to search for the following line, which precedes responsible for the processing of SYN packets that will form new connections: if (so->so_options & SO_ACCEPTCONN) { FreeBSD makes use of a combined syncache/syncookie mechanism, so you're probably also interested in tcp_syncache.c. Robert N M Watson