From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 06:31:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E4B116A4CE for ; Mon, 13 Dec 2004 06:31:08 +0000 (GMT) Received: from www.stv.ee (www.stv.ee [212.7.5.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id C729C43D49 for ; Mon, 13 Dec 2004 06:31:07 +0000 (GMT) (envelope-from remi69@weedmail.com) Received: from samsa (213-35-154-94-stl.trt.estpak.ee [213.35.154.94]) by www.stv.ee (8.12.9p2/8.12.9) with ESMTP id iBD6V0Qe062101 for ; Mon, 13 Dec 2004 08:31:03 +0200 (EET) (envelope-from remi69@weedmail.com) Message-Id: <200412130631.iBD6V0Qe062101@www.stv.ee> To: freebsd-arch@FreeBSD.org From: remi69@weedmail.com Date: Mon, 13 Dec 2004 08:31:02 +0200 MIME-Version: 1.0 X-Antivirus: avast! (VPS 0450-1, 09.12.2004), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: half a thousand in bonus chips added to your first deposit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 06:31:08 -0000 Get up to $500 in bonus chips added to your first deposit. After installing the software, simply register with the casino and we will match 50% of up to $1000 of your first deposit with bonus chips added to your player account. Click the link below: http://www.imperialcasino.com/S13XXF/ http://www.imperialcasino.com/downloads/S13XXF/Imperial%20Casino.exe Fair Play is both a philosophy and a science in our Casino. First, we have philosophical commitment to providing absolutely fair play in every game because it's the right thing to do. We treat our players like we want to be treated: honestly and fairly. Second, we use industry standard Las Vegas odds and game-play rules to ensure that our players get the most entertainment value for their money. Fair play means lots of winners and more repeat business for our Casino. We also take a scientific approach to making sure our games are fair: Fair by design. The software that powers our casino games uses a sophisticated Random Numb! er Generator (RNG) to make sure each hand of cards or roll of the dice is unpredictable and completely random. Thus, our games are designed to be fair from the ground up. Test for fairness. We methodically analyze historical game data and test our games on a continual basis to assure ourselves that the games are absolutely fair and random. Audit for assurance. We make our game software and test data available to external auditors and gaming authorities to provide an outside, independent check of our own research and analysis. http://www.imperialcasino.com/downloads/S13XXF/ or try downloading the soft right away - risk free http://www.imperialcasino.com/downloads/S13XXF/Imperial%20Casino.exe Yours sincerely, Derek Applegate CIO, senior editor, sales person From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 11:14:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 258D816A4CE for ; Mon, 13 Dec 2004 11:14:48 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id B390743D53 for ; Mon, 13 Dec 2004 11:14:46 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 30492 invoked from network); 13 Dec 2004 11:14:42 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 13 Dec 2004 11:14:42 -0000 Received: (qmail 60846 invoked by uid 1000); 13 Dec 2004 11:14:44 -0000 Date: Mon, 13 Dec 2004 13:14:44 +0200 From: Peter Pentchev To: Mark Murray Message-ID: <20041213111444.GC4172@straylight.m.ringlet.net> Mail-Followup-To: Mark Murray , Colin Percival , freebsd-arch@FreeBSD.ORG References: <41B9D586.5070403@wadham.ox.ac.uk> <200412101755.iBAHt55A090986@grovel.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7qSK/uQB79J36Y4o" Content-Disposition: inline In-Reply-To: <200412101755.iBAHt55A090986@grovel.grondar.org> User-Agent: Mutt/1.5.6i cc: Colin Percival cc: freebsd-arch@FreeBSD.ORG Subject: Re: Adding standalone RSA code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 11:14:48 -0000 --7qSK/uQB79J36Y4o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 10, 2004 at 05:55:05PM +0000, Mark Murray wrote: > Colin Percival writes: > > > Is size really a concern? > >=20 > > No. The size is a side-effect of having a minimal, highly secure, > > library, and was not a design consideration. >=20 > "New" very often means "Insecure". I'd rather see something with lots=20 > of eyes over it, and OpenSSL has the advantage of having quite a few=20 > competent crypto guys grovel through it. >=20 > I'm still inclined to say "Please stick with OpenSSL; it is the devil=20 > we know." And then, of course, there's the problem that OpenSSL doesn't work RIGHT NOW in some situations; see my two e-mails to -hackers and others (including you ;) at http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2004-September/00808= 9.html http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2004-September/00809= 0.html Yep, "the devil we know", indeed :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 =2Esiht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI --7qSK/uQB79J36Y4o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBvXmk7Ri2jRYZRVMRAidWAJ9Cca8cJPNDznxJuz1MSkn87TDUqQCeJdrs ReJENdPye1YOpgyvv4lg13A= =z234 -----END PGP SIGNATURE----- --7qSK/uQB79J36Y4o-- From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 11:32:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 339F916A4CE; Mon, 13 Dec 2004 11:32:03 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E7043D39; Mon, 13 Dec 2004 11:32:02 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CdoQr-0000EZ-00; Mon, 13 Dec 2004 12:32:01 +0100 Received: from [217.83.4.147] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CdoQr-00018g-00; Mon, 13 Dec 2004 12:32:01 +0100 From: Max Laier To: freebsd-current@freebsd.org Date: Mon, 13 Dec 2004 12:32:47 +0100 User-Agent: KMail/1.7.1 References: <94AE3F5A-4CD6-11D9-8BD6-000A95C4D7BC@FreeBSD.org> <200412130913.20215.max@love2party.net> In-Reply-To: <200412130913.20215.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1147140.QXZ1z243kW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412131232.55051.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Suleiman Souhlal cc: freebsd-arch@freebsd.org Subject: Re: sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 11:32:03 -0000 --nextPart1147140.QXZ1z243kW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 13 December 2004 09:13, I wrote: > On Monday 13 December 2004 08:14, Suleiman Souhlal wrote: > > Hello, > > > > The patch at http://people.freebsd.org/~ssouhlal/sysctl-locking.diff > > removes Giant from the sysctl subsystem. > > I tested it on i386 and powerpc, where it appears to work perfectly. > > However, I have not been able to test it on an SMP box, as I don't have > > access to any. > > So I would appreciate it if someone would test it, and report any > > problems. > > I will commit it in about week, unless, of course, there are > > objections/problems. > > Wait a minute ... you can't just assert that all sysctl handler are MPSAF= E. > It's a good idea to introduce "real" locking for the sysctl-tree handling > in order to be able to lose Giant at a later point, but I *strongly* > suggest that you keep on grabing Giant before calling oid_handler() in > sysctl_root(). It doesn't seem like you do so, right now. > > You have identified two places where Giant is explicitly asserted, but I = am > afraid that there are much more handlers that don't assert Giant but need > it. Moreover, the "simple" handler might also write to memory that is > implicitly protected by Giant and should not be modified without it. > > As a transition step I suggest that we extend the API in the way the > callout API works. So that you can ask for a Giant-free handler call by > setting an MPSAFE flag. This got me wondering a bit how well we protect sysctls at the moment or if= we=20 have code that just assumes atomicy for sysctls. As an example of a very we= ll=20 protected sysctl there is kern.securelevel, which has it's own handler that= =20 uses it's own mutex to protect the change and a defined API to read the val= ue=20 (useing the same mutex to protect the access). Other values are not so well= =20 protected. It is safe for some sysctls - with just on/off semantic (net.inet.forwardin= g=20 e.g.) - to read them unprotected. As the user can decide to flip the switch= =20 in a loop, the code should cope with a (short) unstable value anyway. Sysctls that describe maximum buffer sizes, portranges or maximal number of= =20 threads per process are more dangerous and might need attention. With bad=20 timing we might have very undesired effects. The "complex" sysctls that implement their own handlers are not a concern, = as=20 they are usually implemented within the .c file that has the appropriate=20 mutex and can use proper locking if required. If we come to the conclusion that it is required to protect these values=20 better, I suggest the following: 1) Extend sysctl_add_oid() to accept an additional mutex argument. 2) Extend the simple sysctl handler to use this mutex to protect the actual= =20 write(?read?). We must not hold the mutex during the useland copy in/out= so=20 we must move to temporary storage. 3) To maintain the current API and behavior we use &Giant as the default=20 fallback argument. This might need some extension for complex handler (i= =2Ee.=20 no mutex given -> acquire Giant before calling the complex handler). What do people think of this? Does it make any sense? Should we be concerne= d=20 at all? Does the extension make sense? Comments? [CCing -arch] =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 --nextPart1147140.QXZ1z243kW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBvX3nXyyEoT62BG0RAlAIAJ9roEIb8kMmiDcHxhHtlDfZCHp4zQCcDhtC kfQ6MAunbImQMOfBuqI+1eQ= =RnXa -----END PGP SIGNATURE----- --nextPart1147140.QXZ1z243kW-- From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 22:09:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CCE416A4D0 for ; Mon, 13 Dec 2004 22:09:28 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 052A643D64 for ; Mon, 13 Dec 2004 22:09:28 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 64653 invoked from network); 13 Dec 2004 22:10:03 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 13 Dec 2004 22:10:03 -0000 From: Joe Kelsey To: arch@freebsd.org, hackers@freebsd.org Content-Type: text/plain Date: Mon, 13 Dec 2004 14:10:03 -0800 Message-Id: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: stable@freebsd.org cc: current@freebsd.org Subject: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 22:09:28 -0000 I have a desire to fix posix semaphores in at least 5.3. The current implementation doesn't actually follow the "spirit" of the standard, even though it technically qualifies in a somewhat degraded sense. I refer to the fact that the current implementation treats posix semaphores as completely contained inside the kernel and essentially divorced from the filesystem. The true "spirit" of the standard places the semaphores directly in the file system, similar to named pipes. However the current implementation treats the supplied "name" as a 14-character identifier, required to begin with a slash and contain no other slashes. Pretty weak. Well, in order to fix this, we need to add file system code and come up with a new type. I currently have some time to spend on something like this and am willing to put in whatever effort it takes. Does anyone want to add their own ideas or requirements? I currently run 5.3, but I suppose I could think about running current at some point in the future. /Joe From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 22:21:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C8316A4CE; Mon, 13 Dec 2004 22:21:35 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5856D43D54; Mon, 13 Dec 2004 22:21:35 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 432447A403; Mon, 13 Dec 2004 14:21:35 -0800 (PST) Message-ID: <41BE15EE.5060704@elischer.org> Date: Mon, 13 Dec 2004 14:21:34 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Joe Kelsey References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> In-Reply-To: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 22:21:35 -0000 Joe Kelsey wrote: >I have a desire to fix posix semaphores in at least 5.3. The current >implementation doesn't actually follow the "spirit" of the standard, >even though it technically qualifies in a somewhat degraded sense. I >refer to the fact that the current implementation treats posix >semaphores as completely contained inside the kernel and essentially >divorced from the filesystem. The true "spirit" of the standard places >the semaphores directly in the file system, similar to named pipes. >However the current implementation treats the supplied "name" as a >14-character identifier, required to begin with a slash and contain no >other slashes. Pretty weak. > >Well, in order to fix this, we need to add file system code and come up >with a new type. I currently have some time to spend on something like >this and am willing to put in whatever effort it takes. Does anyone >want to add their own ideas or requirements? > >I currently run 5.3, but I suppose I could think about running current >at some point in the future. > I don't think that the spirit is to do what you suggest. I have always interpretted it to be a separate namespace. does the posix "mknod" definition mention how to make a semaphore? An interesting problem but I'm not sure if it's needed.. P.S. CC's trimmed to arch (correct place) and current (not so correct but ok) next round should probably stay on just "arch". > >/Joe > > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 22:39:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69C8216A4CE for ; Mon, 13 Dec 2004 22:39:16 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 0BF7043D5F for ; Mon, 13 Dec 2004 22:39:16 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 64836 invoked from network); 13 Dec 2004 22:39:51 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 13 Dec 2004 22:39:51 -0000 From: Joe Kelsey To: Julian Elischer In-Reply-To: <41BE15EE.5060704@elischer.org> References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> <41BE15EE.5060704@elischer.org> Content-Type: text/plain Date: Mon, 13 Dec 2004 14:39:51 -0800 Message-Id: <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 22:39:16 -0000 On Mon, 2004-12-13 at 14:21 -0800, Julian Elischer wrote: > > Joe Kelsey wrote: > > >I have a desire to fix posix semaphores in at least 5.3. The current > >implementation doesn't actually follow the "spirit" of the standard, > >even though it technically qualifies in a somewhat degraded sense. I > >refer to the fact that the current implementation treats posix > >semaphores as completely contained inside the kernel and essentially > >divorced from the filesystem. The true "spirit" of the standard places > >the semaphores directly in the file system, similar to named pipes. > >However the current implementation treats the supplied "name" as a > >14-character identifier, required to begin with a slash and contain no > >other slashes. Pretty weak. > > > >Well, in order to fix this, we need to add file system code and come up > >with a new type. I currently have some time to spend on something like > >this and am willing to put in whatever effort it takes. Does anyone > >want to add their own ideas or requirements? > > > >I currently run 5.3, but I suppose I could think about running current > >at some point in the future. > > > > I don't think that the spirit is to do what you suggest. > I have always interpretted it to be a separate namespace. > does the posix "mknod" definition mention how to make a semaphore? POSIX does not define or allow use of mknod to create a named semaphore. Only sem_open() can create a named semaphore. The "spirit", as implemented in other OS', clearly indicates the use of file system names, not the restricted 14-character name used by FreeBSD. For instance, Solaris uses file system names. /Joe From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 22:55:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D1DD16A4CE for ; Mon, 13 Dec 2004 22:55:12 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3425D43D5C for ; Mon, 13 Dec 2004 22:55:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id F2A0B7A403; Mon, 13 Dec 2004 14:55:11 -0800 (PST) Message-ID: <41BE1DCF.4070209@elischer.org> Date: Mon, 13 Dec 2004 14:55:11 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Joe Kelsey References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> <41BE15EE.5060704@elischer.org> <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> In-Reply-To: <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 22:55:12 -0000 Joe Kelsey wrote: >On Mon, 2004-12-13 at 14:21 -0800, Julian Elischer wrote: > > >>Joe Kelsey wrote: >> >> >> >>>I have a desire to fix posix semaphores in at least 5.3. The current >>>implementation doesn't actually follow the "spirit" of the standard, >>>even though it technically qualifies in a somewhat degraded sense. I >>>refer to the fact that the current implementation treats posix >>>semaphores as completely contained inside the kernel and essentially >>>divorced from the filesystem. The true "spirit" of the standard places >>>the semaphores directly in the file system, similar to named pipes. >>>However the current implementation treats the supplied "name" as a >>>14-character identifier, required to begin with a slash and contain no >>>other slashes. Pretty weak. >>> >>>Well, in order to fix this, we need to add file system code and come up >>>with a new type. I currently have some time to spend on something like >>>this and am willing to put in whatever effort it takes. Does anyone >>>want to add their own ideas or requirements? >>> >>>I currently run 5.3, but I suppose I could think about running current >>>at some point in the future. >>> >>> >>> >>I don't think that the spirit is to do what you suggest. >>I have always interpretted it to be a separate namespace. >>does the posix "mknod" definition mention how to make a semaphore? >> >> > >POSIX does not define or allow use of mknod to create a named semaphore. >Only sem_open() can create a named semaphore. The "spirit", as >implemented in other OS', clearly indicates the use of file system >names, not the restricted 14-character name used by FreeBSD. For >instance, Solaris uses file system names. > What does it gain you? (other than more letters to the name). > >/Joe > > > From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 22:56:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C867616A4CE for ; Mon, 13 Dec 2004 22:56:33 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB6D543D54 for ; Mon, 13 Dec 2004 22:56:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 9AE347A44A; Mon, 13 Dec 2004 14:56:33 -0800 (PST) Message-ID: <41BE1E21.6090201@elischer.org> Date: Mon, 13 Dec 2004 14:56:33 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Joe Kelsey References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> <41BE15EE.5060704@elischer.org> <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> In-Reply-To: <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 22:56:33 -0000 Joe Kelsey wrote: >On Mon, 2004-12-13 at 14:21 -0800, Julian Elischer wrote: > > >>Joe Kelsey wrote: >> >> >> >>>I have a desire to fix posix semaphores in at least 5.3. The current >>>implementation doesn't actually follow the "spirit" of the standard, >>>even though it technically qualifies in a somewhat degraded sense. I >>>refer to the fact that the current implementation treats posix >>>semaphores as completely contained inside the kernel and essentially >>>divorced from the filesystem. The true "spirit" of the standard places >>>the semaphores directly in the file system, similar to named pipes. >>>However the current implementation treats the supplied "name" as a >>>14-character identifier, required to begin with a slash and contain no >>>other slashes. Pretty weak. >>> >>>Well, in order to fix this, we need to add file system code and come up >>>with a new type. I currently have some time to spend on something like >>>this and am willing to put in whatever effort it takes. Does anyone >>>want to add their own ideas or requirements? >>> >>>I currently run 5.3, but I suppose I could think about running current >>>at some point in the future. >>> >>> >>> >>I don't think that the spirit is to do what you suggest. >>I have always interpretted it to be a separate namespace. >>does the posix "mknod" definition mention how to make a semaphore? >> >> > >POSIX does not define or allow use of mknod to create a named semaphore. >Only sem_open() can create a named semaphore. The "spirit", as >implemented in other OS', clearly indicates the use of file system >names, not the restricted 14-character name used by FreeBSD. For >instance, Solaris uses file system names. > What does Linux use? AIX? > >/Joe > > > From owner-freebsd-arch@FreeBSD.ORG Mon Dec 13 23:35:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0395716A4CE for ; Mon, 13 Dec 2004 23:35:20 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AF0D43D5C for ; Mon, 13 Dec 2004 23:35:19 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id iBDNYKtk052391; Mon, 13 Dec 2004 18:34:20 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id iBDNYJtB052390; Mon, 13 Dec 2004 18:34:20 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 13 Dec 2004 18:34:19 -0500 From: David Schultz To: Joe Kelsey Message-ID: <20041213233419.GA52130@VARK.MIT.EDU> Mail-Followup-To: Joe Kelsey , Julian Elischer , arch@FreeBSD.ORG References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> <41BE15EE.5060704@elischer.org> <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> cc: arch@FreeBSD.ORG cc: Julian Elischer Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 23:35:20 -0000 On Mon, Dec 13, 2004, Joe Kelsey wrote: > On Mon, 2004-12-13 at 14:21 -0800, Julian Elischer wrote: > > > > Joe Kelsey wrote: > > > > >I have a desire to fix posix semaphores in at least 5.3. The current > > >implementation doesn't actually follow the "spirit" of the standard, > > >even though it technically qualifies in a somewhat degraded sense. I > > >refer to the fact that the current implementation treats posix > > >semaphores as completely contained inside the kernel and essentially > > >divorced from the filesystem. The true "spirit" of the standard places > > >the semaphores directly in the file system, similar to named pipes. > > >However the current implementation treats the supplied "name" as a > > >14-character identifier, required to begin with a slash and contain no > > >other slashes. Pretty weak. > > > > > >Well, in order to fix this, we need to add file system code and come up > > >with a new type. I currently have some time to spend on something like > > >this and am willing to put in whatever effort it takes. Does anyone > > >want to add their own ideas or requirements? > > > > > >I currently run 5.3, but I suppose I could think about running current > > >at some point in the future. > > > > > > > I don't think that the spirit is to do what you suggest. > > I have always interpretted it to be a separate namespace. > > does the posix "mknod" definition mention how to make a semaphore? > > POSIX does not define or allow use of mknod to create a named semaphore. > Only sem_open() can create a named semaphore. The "spirit", as > implemented in other OS', clearly indicates the use of file system > names, not the restricted 14-character name used by FreeBSD. For > instance, Solaris uses file system names. Err, I'm pretty sure Solaris uses a separate namespace for semaphores, and I think Linux does the same. That's not to say that I'm opposed to this idea. However, the implementation you propose, while aesthetically pleasing, is likely to be much slower and take a good deal of effort. Moreover, it doesn't seem that it would provide any significant additional functionality. From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 03:19:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 626A316A4CE for ; Tue, 14 Dec 2004 03:19:45 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 07FF143D58 for ; Tue, 14 Dec 2004 03:19:45 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 66203 invoked from network); 14 Dec 2004 03:20:20 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 14 Dec 2004 03:20:20 -0000 From: Joe Kelsey To: David Schultz In-Reply-To: <20041213233419.GA52130@VARK.MIT.EDU> References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> <41BE15EE.5060704@elischer.org> <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> <20041213233419.GA52130@VARK.MIT.EDU> Content-Type: text/plain Date: Mon, 13 Dec 2004 19:20:20 -0800 Message-Id: <1102994420.30309.219.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG cc: Julian Elischer Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 03:19:45 -0000 On Mon, 2004-12-13 at 18:34 -0500, David Schultz wrote: > On Mon, Dec 13, 2004, Joe Kelsey wrote: > > On Mon, 2004-12-13 at 14:21 -0800, Julian Elischer wrote: > > > > > > Joe Kelsey wrote: > > > > > > >I have a desire to fix posix semaphores in at least 5.3. The current > > > >implementation doesn't actually follow the "spirit" of the standard, > > > >even though it technically qualifies in a somewhat degraded sense. I > > > >refer to the fact that the current implementation treats posix > > > >semaphores as completely contained inside the kernel and essentially > > > >divorced from the filesystem. The true "spirit" of the standard places > > > >the semaphores directly in the file system, similar to named pipes. > > > >However the current implementation treats the supplied "name" as a > > > >14-character identifier, required to begin with a slash and contain no > > > >other slashes. Pretty weak. > > > > > > > >Well, in order to fix this, we need to add file system code and come up > > > >with a new type. I currently have some time to spend on something like > > > >this and am willing to put in whatever effort it takes. Does anyone > > > >want to add their own ideas or requirements? > > > > > > > >I currently run 5.3, but I suppose I could think about running current > > > >at some point in the future. > > > > > > > > > > I don't think that the spirit is to do what you suggest. > > > I have always interpretted it to be a separate namespace. > > > does the posix "mknod" definition mention how to make a semaphore? > > > > POSIX does not define or allow use of mknod to create a named semaphore. > > Only sem_open() can create a named semaphore. The "spirit", as > > implemented in other OS', clearly indicates the use of file system > > names, not the restricted 14-character name used by FreeBSD. For > > instance, Solaris uses file system names. > > Err, I'm pretty sure Solaris uses a separate namespace for > semaphores, and I think Linux does the same. That's not to say > that I'm opposed to this idea. However, the implementation you > propose, while aesthetically pleasing, is likely to be much slower > and take a good deal of effort. Moreover, it doesn't seem that it > would provide any significant additional functionality. The Solaris documentation specifically says that sem_open uses file system namespace. The whole point of POSIX semaphores is that there are TWO different ways to create semaphores. sem_init() creates unnamed semaphores. sem_open creates named semaphores. Therefore, you choose at creation time whether you want speed or interoperability. The speed penalty only applies to creation/open. Once you have the semaphore, the rest is the same. The whole point of having a file system name is to allow for unplanned sharing in a complex way. Using stupid 14-character names does not allow for the use of sub-directories and sym-links and so on to really take advantage of the complex name space. Of course, if no one really wants to see this, then I guess I can just hide over in my little corner since *I* want to see this happen. /Joe From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 03:35:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6C9216A4CE; Tue, 14 Dec 2004 03:35:37 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FAB843D1D; Tue, 14 Dec 2004 03:35:37 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iBE3ZWHr027103; Mon, 13 Dec 2004 22:35:32 -0500 (EST) Date: Mon, 13 Dec 2004 22:35:32 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joe Kelsey In-Reply-To: <1102994420.30309.219.camel@zircon.zircon.seattle.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: arch@freebsd.org cc: David Schultz cc: Julian Elischer Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 03:35:37 -0000 On Mon, 13 Dec 2004, Joe Kelsey wrote: > On Mon, 2004-12-13 at 18:34 -0500, David Schultz wrote: > > > > Err, I'm pretty sure Solaris uses a separate namespace for > > semaphores, and I think Linux does the same. That's not to say > > that I'm opposed to this idea. However, the implementation you > > propose, while aesthetically pleasing, is likely to be much slower > > and take a good deal of effort. Moreover, it doesn't seem that it > > would provide any significant additional functionality. > > The Solaris documentation specifically says that sem_open uses file > system namespace. It doesn't in the man page for sem_open(). From a Solaris 9 box: $ man sem_open [ ... ] The name argument points to a string naming a semaphore object. It is unspecified whether the name appears in the file system and is visible to functions that take pathnames as arguments. The name argument conforms to the construction rules for a pathname. The first character of name must be a slash (/) character and the remaining characters of name cannot include any slash characters. For maximum portabil- ity, name should include no more than 14 characters, but this limit is not enforced. [ ... ] -- DE From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 07:43:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A3FA16A4CE for ; Tue, 14 Dec 2004 07:43:38 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF23043D54 for ; Tue, 14 Dec 2004 07:43:37 +0000 (GMT) (envelope-from csujun@gmail.com) Received: by mproxy.gmail.com with SMTP id w41so329016cwb for ; Mon, 13 Dec 2004 23:43:37 -0800 (PST) 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:mime-version:content-type:content-transfer-encoding; b=YpcGebePpgi0ybF2z8aJaE6LrIcUFfTlrFOc/4NTUEa7hhg+4WcNr5wtOJ/AgA2WYwu0T5ZlDTDC99Xq0P0Smb10n+cnQW64ZDw1jCjF5EkyR91C0YPxULMdag3Yp3DWyL+oeZ7HH0NPnzpZ8ON7gbCPf95sF1fuwg54tXkzg3Q= Received: by 10.11.94.12 with SMTP id r12mr199851cwb; Mon, 13 Dec 2004 23:43:37 -0800 (PST) Received: by 10.11.118.15 with HTTP; Mon, 13 Dec 2004 23:43:37 -0800 (PST) Message-ID: Date: Tue, 14 Dec 2004 15:43:37 +0800 From: Jun Su To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: alc@freebsd.org cc: tegge@freebsd.org cc: delphij@FreeBSD.org Subject: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jun Su List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 07:43:38 -0000 Backgroud ======== Many modern server machines have over 4G, even 16G memory. Full Memory Dump is nightmare for them. In the Linux world, there is a project named LKD that support several dump methods. In Windows, it also supports MiniDump, KernelOnlyDump and FullDump. In our use base, many users can only report the call-stack to the newsgroup. For these users, a MiniDump can severve them very well. Most important message can be generagte at the dumptime and save into dump file. For the limitation of our current kgdb, we can not trace the stack into user memory space. In this scenerio, a KernelOnly dump contains the informaiton that we can used. And in most panic scenerio, VM system is not the root cause and its data structure are very well. It is not so risky to rely on the data of VM subsystem. And we can even create a method to check if the VM subsystem is in a good state before we did KernelOnlyDump. Kernel-Only Dump ============== We now can use /dev/kmem as the core file. If we can generate a dump file with the same information with it, then we can enable kernel-only dump with very limit code changes. 1. Change KVM library to support a new type of file that only contains kernel memory. 2. Change kernel side to write only kernel memory when dumping. 3. Change dumpon utility to do the right checking on the partiction size. MiniDump ======= In a minidump, Register info, plus the crash stack is enough. New Dump MI interface ================= There is only dumpsys method as the MI interface for the dump system. And if we look at the implementation of AMD, x86, Alpha, we will find they are very similiar. We need revise this interface when importing these new feature in. I post this in order to get some feedback and thinking about this idea. Thanks, Jun From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 07:48:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72A6316A4E0; Tue, 14 Dec 2004 07:48:47 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74D1843D6E; Tue, 14 Dec 2004 07:48:46 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iBE7miJe054797; Tue, 14 Dec 2004 08:48:44 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jun Su From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 14 Dec 2004 15:43:37 +0800." Date: Tue, 14 Dec 2004 08:48:44 +0100 Message-ID: <54796.1103010524@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: alc@freebsd.org cc: arch@freebsd.org cc: tegge@freebsd.org cc: delphij@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 07:48:47 -0000 In message , Jun Su writes: >MiniDump >======= >In a minidump, Register info, plus the crash stack is enough. Make it an EVENTHANDLER() and dump it in ascii format. That way any kernel subsystem can hook in a function and dump potentially relevant information. -- 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-arch@FreeBSD.ORG Wed Dec 15 01:44:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E34AB16A4CF for ; Wed, 15 Dec 2004 01:44:08 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CABD43D53 for ; Wed, 15 Dec 2004 01:44:08 +0000 (GMT) (envelope-from csujun@gmail.com) Received: by mproxy.gmail.com with SMTP id q44so355984cwc for ; Tue, 14 Dec 2004 17:44:08 -0800 (PST) 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:references; b=YxEh+ltoggJvqM0Q/foMWMxaGAvuUBtHzVxFGuF6B1FytRty7/Vy/O4MibAXtu7mmOW00pkq8jOVRfmuqURO6SloqZMWiZC1Jl9ipc/MSbXjLWDVcVSmbel6stpTVrvHG4Jrbe4nGLqudIXxTSlnc563MdvU9rGAerZBqOxybBA= Received: by 10.11.94.29 with SMTP id r29mr23216cwb; Tue, 14 Dec 2004 17:44:08 -0800 (PST) Received: by 10.11.118.15 with HTTP; Tue, 14 Dec 2004 17:44:08 -0800 (PST) Message-ID: Date: Wed, 15 Dec 2004 09:44:08 +0800 From: Jun Su To: Poul-Henning Kamp In-Reply-To: <54796.1103010524@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <54796.1103010524@critter.freebsd.dk> cc: arch@freebsd.org cc: delphij@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jun Su List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 01:44:09 -0000 On Tue, 14 Dec 2004 08:48:44 +0100, Poul-Henning Kamp wrote: > In message , Jun Su writes: > > >MiniDump > >======= > >In a minidump, Register info, plus the crash stack is enough. > > Make it an EVENTHANDLER() and dump it in ascii format. ^^^^^^^^^^^^ Don't think the ascii format is a good choose. We can only dump the information like the ones we can get in the KDB. My propose is storing the pages that the stack point is in. Then we can get more useful stack in the userland with the kernel file and kernel symbol. > > That way any kernel subsystem can hook in a function and dump > potentially relevant information. > > -- > 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. > -- -- Jun Su From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 07:51:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99AA816A4CF; Wed, 15 Dec 2004 07:51:24 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B81E343D46; Wed, 15 Dec 2004 07:51:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iBF7pLWF040355; Wed, 15 Dec 2004 08:51:22 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jun Su From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 15 Dec 2004 09:44:08 +0800." Date: Wed, 15 Dec 2004 08:51:21 +0100 Message-ID: <40354.1103097081@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: delphij@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 07:51:24 -0000 In message , Jun Su writes: >On Tue, 14 Dec 2004 08:48:44 +0100, Poul-Henning Kamp > wrote: >> In message , Jun Su writes: >> >> >MiniDump >> >======= >> >In a minidump, Register info, plus the crash stack is enough. >> >> Make it an EVENTHANDLER() and dump it in ascii format. > ^^^^^^^^^^^^ >Don't think the ascii format is a good choose. We can only dump the >information like the ones we can get in the KDB. My propose is storing >the pages that the stack point is in. Then we can get more useful >stack in the userland with the kernel file and kernel symbol. An ascii format summary is a _great_ format because people can email us it without knowing anything else. We could in fact make it a /etc/rc.conf tunable: "send_panic_reports=YES" and we would receive it in email whenever a crash occured. -- 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-arch@FreeBSD.ORG Wed Dec 15 08:26:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CC2916A4CE; Wed, 15 Dec 2004 08:26:30 +0000 (GMT) Received: from beastie.mckusick.com (dsl081-247-227.sfo1.dsl.speakeasy.net [64.81.247.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22F3643D31; Wed, 15 Dec 2004 08:26:30 +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 iBF8QQ5S029357; Wed, 15 Dec 2004 00:26:26 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200412150826.iBF8QQ5S029357@beastie.mckusick.com> To: Jun Su In-Reply-To: Your message of "Wed, 15 Dec 2004 09:44:08 +0800." Date: Wed, 15 Dec 2004 00:26:26 -0800 From: Kirk McKusick cc: arch@freebsd.org cc: Poul-Henning Kamp cc: delphij@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:26:30 -0000 I like the idea of smaller dumps. Certainly KernelOnly is most useful from my perspective. Mini is also useful. Having an ascii option for it seems reasonable if it can be done with minimal kernel code. Otherwise, it seems like it would be fairly simple to get it after the fact from a binary dump with kgdb. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 08:36:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26AB616A4CE for ; Wed, 15 Dec 2004 08:36:54 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01C5543D45 for ; Wed, 15 Dec 2004 08:36:54 +0000 (GMT) (envelope-from csujun@gmail.com) Received: by mproxy.gmail.com with SMTP id q44so360658cwc for ; Wed, 15 Dec 2004 00:36:53 -0800 (PST) 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:references; b=bcisQXdlIn/3F/323yfyoISfHnrFTcNtusdy5borFaDBaaHmfXjL1uMejmt3phCT+fI0hXJTDhUORyRVUqSn6adv9D4U2gWV1uoC5EC6lZAKd2SgbMRGORjddpQhp5b8v1LpFHroMqcmoTE8wiJdlRq0LPQIPR2HBCOrXTBeifM= Received: by 10.11.99.79 with SMTP id w79mr767471cwb; Wed, 15 Dec 2004 00:36:53 -0800 (PST) Received: by 10.11.118.15 with HTTP; Wed, 15 Dec 2004 00:36:53 -0800 (PST) Message-ID: Date: Wed, 15 Dec 2004 16:36:53 +0800 From: Jun Su To: Poul-Henning Kamp In-Reply-To: <40354.1103097081@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <40354.1103097081@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jun Su List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:36:54 -0000 On Wed, 15 Dec 2004 08:51:21 +0100, Poul-Henning Kamp wrote: > In message , Jun Su writes: > >On Tue, 14 Dec 2004 08:48:44 +0100, Poul-Henning Kamp > > wrote: > >> In message , Jun Su writes: > >> > >> >MiniDump > >> >======= > >> >In a minidump, Register info, plus the crash stack is enough. > >> > >> Make it an EVENTHANDLER() and dump it in ascii format. > > ^^^^^^^^^^^^ > >Don't think the ascii format is a good choose. We can only dump the > >information like the ones we can get in the KDB. My propose is storing > >the pages that the stack point is in. Then we can get more useful > >stack in the userland with the kernel file and kernel symbol. > > An ascii format summary is a _great_ format because people can email > us it without knowing anything else. We could in fact make it > a /etc/rc.conf tunable: "send_panic_reports=YES" and we would > receive it in email whenever a crash occured. We can also create an automation system to collect these information. When the number of crash in same function reaches a thorehold, it will send a report to a ML. :-) Sounds your idea is interesing. Anyway, I still think ascii format dump can not replace the minidump. Minidump can provide more information. > > -- > 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. > -- -- Jun Su From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 08:40:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21DC516A4CE for ; Wed, 15 Dec 2004 08:40:42 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC3943D49 for ; Wed, 15 Dec 2004 08:40:41 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iBF8eesv041381; Wed, 15 Dec 2004 09:40:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jun Su From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 15 Dec 2004 16:36:53 +0800." Date: Wed, 15 Dec 2004 09:40:40 +0100 Message-ID: <41380.1103100040@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:40:42 -0000 In message , Jun Su writes: >> An ascii format summary is a _great_ format because people can email >> us it without knowing anything else. We could in fact make it >> a /etc/rc.conf tunable: "send_panic_reports=YES" and we would >> receive it in email whenever a crash occured. >We can also create an automation system to collect these information. >When the number of crash in same function reaches a thorehold, it will >send a report to a ML. :-) Sounds your idea is interesing. >Anyway, I still think ascii format dump can not replace the minidump. >Minidump can provide more information. Ohh, I didn't intend it to replace minidumps. -- 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-arch@FreeBSD.ORG Wed Dec 15 08:45:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EA7016A4CF for ; Wed, 15 Dec 2004 08:45:11 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82F2343D53 for ; Wed, 15 Dec 2004 08:45:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 7B8CC1FFACA; Wed, 15 Dec 2004 09:45:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 36AA71FF9AB; Wed, 15 Dec 2004 09:45:06 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id AC72215389; Wed, 15 Dec 2004 08:41:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id A259B15336; Wed, 15 Dec 2004 08:41:50 +0000 (UTC) Date: Wed, 15 Dec 2004 08:41:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Poul-Henning Kamp In-Reply-To: <40354.1103097081@critter.freebsd.dk> Message-ID: References: <40354.1103097081@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: arch@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:45:11 -0000 On Wed, 15 Dec 2004, Poul-Henning Kamp wrote: > In message , Jun Su writes: > >On Tue, 14 Dec 2004 08:48:44 +0100, Poul-Henning Kamp > > wrote: > >> In message , Jun Su writes: > >> > >> >MiniDump > >> >======= > >> >In a minidump, Register info, plus the crash stack is enough. > >> > >> Make it an EVENTHANDLER() and dump it in ascii format. > > ^^^^^^^^^^^^ > >Don't think the ascii format is a good choose. We can only dump the > >information like the ones we can get in the KDB. My propose is storing > >the pages that the stack point is in. Then we can get more useful > >stack in the userland with the kernel file and kernel symbol. > > An ascii format summary is a _great_ format because people can email > us it without knowing anything else. We could in fact make it > a /etc/rc.conf tunable: "send_panic_reports=YES" and we would > receive it in email whenever a crash occured. < SCNR > let's have a dialog UI to set this knob; sth that might look like this: +-----------------------------------------------------------------------+ | | | [ ] Do you really want to (automatically) send crash reports? | | [ ] Are you sure you really want to send them? | | [ ] Please confirm that the crash reports may be mailed out. | | [ ] Please confirm that a mail client is installed and working. | | [ ] Please confirm that the sender address I will chose is replyable. | | [ ] Do you want not to view no details before sending? | | [ ] Never ask me these silly questions again - just do it. | | [ ] Add note that FreeBSD rocks anyway. | | | | [ Yes ] [ No ] [ Maybe ] [ Please explain what this all means ] | | | +-----------------------------------------------------------------------+ < / SCNR > *uups* sorry; what I really meant is: if the knob is turned on then write the data to pre-filled send-pr understandable text file upon extraction and tell the user sth. like the following: --- cut --- To send a report of the last crashdump to FreeBSD developers please use: send-pr -f /var/crash/4305834 You will be able to review everything before mailing out. --- cut --- this can then either go to an extra mailing list or and extra gnats cateory. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 13:45:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E64AD16A4CE for ; Wed, 15 Dec 2004 13:45:59 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 10D7443D48 for ; Wed, 15 Dec 2004 13:45:59 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 85881 invoked by uid 0); 15 Dec 2004 13:44:37 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.165.87) by node15.coopprint.com with SMTP; 15 Dec 2004 13:44:37 -0000 Message-ID: <41C04029.7010909@gamersimpact.com> Date: Wed, 15 Dec 2004 07:46:17 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <40354.1103097081@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 13:46:00 -0000 Bjoern A. Zeeb wrote: > *uups* sorry; what I really meant is: > >if the knob is turned on then write the data to pre-filled send-pr >understandable text file upon extraction and tell the user sth. like >the following: > >--- cut --- >To send a report of the last crashdump to FreeBSD developers please use: > send-pr -f /var/crash/4305834 >You will be able to review everything before mailing out. >--- cut --- > >this can then either go to an extra mailing list or and extra gnats >cateory. > > I like the idea of automated send capabilities. However, what is this going to mean for the already cluttered GNATS database? It seems to me GNATS tends to grow faster than it shrinks. With possibly 100-200 additional PRs a day, how long before it becomes a nightmare? -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 17:30:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B363616A4CE for ; Wed, 15 Dec 2004 17:30:51 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A4543D41 for ; Wed, 15 Dec 2004 17:30:51 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id DF646148ED; Wed, 15 Dec 2004 11:30:50 -0600 (CST) Date: Wed, 15 Dec 2004 11:30:50 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Ryan Sommers In-Reply-To: <41C04029.7010909@gamersimpact.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Bjoern A. Zeeb" cc: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 17:30:51 -0000 On Wed, 15 Dec 2004, Ryan Sommers wrote: > I like the idea of automated send capabilities. However, what is this > going to mean for the already cluttered GNATS database? I believe the word we are looking for is "catastrophic." We should think long and hard before automating the sending of what might be very large files into GNATS. GNATS is a flat-text=file datatbase with a fragile format and primitive search capabilities (kind of goes with that territory). I don't even want to think about what this would do to its performance (remember that several people mirror it via cvsup.) Having some kind of ability to save off the info is no doubt a good idea, but auto-submitting it isn't. (Imagine for a moment the number of downrev versions of FreeBSD that are still installed ...) mcl From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 18:47:07 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D01716A50D for ; Wed, 15 Dec 2004 18:47:07 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAB5F43D60 for ; Wed, 15 Dec 2004 18:47:06 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id iBFIl5ih057561; Wed, 15 Dec 2004 12:47:05 -0600 (CST) (envelope-from dan) Date: Wed, 15 Dec 2004 12:47:05 -0600 From: Dan Nelson To: Mark Linimon Message-ID: <20041215184705.GA23842@dan.emsphone.com> References: <41C04029.7010909@gamersimpact.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: Ryan Sommers cc: Poul-Henning Kamp cc: "Bjoern A. Zeeb" Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 18:47:07 -0000 In the last episode (Dec 15), Mark Linimon said: > On Wed, 15 Dec 2004, Ryan Sommers wrote: > > I like the idea of automated send capabilities. However, what is > > this going to mean for the already cluttered GNATS database? > > I believe the word we are looking for is "catastrophic." > > We should think long and hard before automating the sending of what > might be very large files into GNATS. GNATS is a flat-text=file > datatbase with a fragile format and primitive search capabilities > (kind of goes with that territory). I don't even want to think about > what this would do to its performance (remember that several people > mirror it via cvsup.) > > Having some kind of ability to save off the info is no doubt a good > idea, but auto-submitting it isn't. (Imagine for a moment the number > of downrev versions of FreeBSD that are still installed ...) An ideal would be something like Mozilla's talkback, where something aggregates the submitted stack traces and gives you a summary. Even sending the traces to a mailinglist with a searchable archive would be useful, though. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Wed Dec 15 21:58:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A74D216A4CE; Wed, 15 Dec 2004 21:58:14 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AE8743D3F; Wed, 15 Dec 2004 21:58:14 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 37378AC93D; Wed, 15 Dec 2004 22:58:12 +0100 (CET) Date: Wed, 15 Dec 2004 22:58:12 +0100 From: Pawel Jakub Dawidek To: Jun Su Message-ID: <20041215215812.GM1130@darkness.comp.waw.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kZxC0s2ORSstvtHP" Content-Disposition: inline In-Reply-To: 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: alc@freebsd.org cc: arch@freebsd.org cc: tegge@freebsd.org cc: delphij@FreeBSD.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 21:58:14 -0000 --kZxC0s2ORSstvtHP Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 14, 2004 at 03:43:37PM +0800, Jun Su wrote: +> Kernel-Only Dump +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> We now can use /dev/kmem as the core file. If we can generate a dump fil= e with +> the same information with it, then we can enable kernel-only dump with +> very limit code changes. +>=20 +> 1. Change KVM library to support a new type of file that only contains +> kernel memory. +> 2. Change kernel side to write only kernel memory when dumping. +> 3. Change dumpon utility to do the right checking on the partiction size. I like the idea of Kernel-Only dump also because of security reasons - user may not want to send whole dump full of passwords, etc. It will be also cool if we can introduce malloc(9) flag (M_NODUMP), so we can safely allocate things like gbde keys, etc. and be sure it will not be part of a dump. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --kZxC0s2ORSstvtHP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBwLN0ForvXbEpPzQRAqQtAKCN4pDY3AN2wlQbHvALalpQKdnqXACeI7od EFBSodsUaEA6hz5jZMFPfII= =U8Gx -----END PGP SIGNATURE----- --kZxC0s2ORSstvtHP-- From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 04:50:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BB2D16A4F5; Fri, 17 Dec 2004 04:50:26 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84C0443D3F; Fri, 17 Dec 2004 04:50:25 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.98] (pool-138-88-246-116.res.east.verizon.net [138.88.246.116]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id iBH4oEW12433 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Thu, 16 Dec 2004 23:50:23 -0500 In-Reply-To: <200412131232.55051.max@love2party.net> References: <94AE3F5A-4CD6-11D9-8BD6-000A95C4D7BC@FreeBSD.org> <200412130913.20215.max@love2party.net> <200412131232.55051.max@love2party.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21F934EB-4FE7-11D9-B1F7-000A95C4D7BC@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Thu, 16 Dec 2004 23:50:11 -0500 To: Max Laier X-Mailer: Apple Mail (2.619) cc: freebsd-current@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 04:50:26 -0000 Hello, On Dec 13, 2004, at 6:32 AM, Max Laier wrote: > 1) Extend sysctl_add_oid() to accept an additional mutex argument. > 2) Extend the simple sysctl handler to use this mutex to protect the > actual > write(?read?). We must not hold the mutex during the useland copy > in/out so > we must move to temporary storage. > 3) To maintain the current API and behavior we use &Giant as the > default > fallback argument. This might need some extension for complex > handler (i.e. > no mutex given -> acquire Giant before calling the complex handler). > > What do people think of this? Does it make any sense? Should we be > concerned > at all? Does the extension make sense? Comments? I have implemented this. The diff is at http://people.freebsd.org/~ssouhlal/sysctl-sx-locking-20041214.diff It also needs the patch at http://people.freebsd.org/~ssouhlal/sx_xlocked.diff which introduces a sx_xlocked() function. Unfortunately, we still need to look at every single SYSCTL_PROC, and make either grab Giant, lock correctly, or make sure it doesn't need any locking. :( -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 06:28:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A95816A4CF for ; Fri, 17 Dec 2004 06:28:47 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1670543D31 for ; Fri, 17 Dec 2004 06:28:47 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1269268rnf for ; Thu, 16 Dec 2004 22:28:46 -0800 (PST) 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; b=GDp1IowxgGwfxjvN+RDdA61bsGyzZ+zIHd6gRzUHlq+Xzqukc0U2+iUBdi+U+dr7wl/EQdsP81w6a6XIiFXvoW9flIykndH+QwLkv9O08OKAxEuj+j2kwX8UzMH9HgR5VJMP2KTxilrYcTIoLQdSA67bCf2+RSjZ+NURhAHB2n8= Received: by 10.38.163.80 with SMTP id l80mr103407rne; Thu, 16 Dec 2004 22:28:46 -0800 (PST) Received: by 10.38.209.11 with HTTP; Thu, 16 Dec 2004 22:28:46 -0800 (PST) Message-ID: <84dead7204121622283c51d41a@mail.gmail.com> Date: Fri, 17 Dec 2004 11:58:46 +0530 From: Joseph Koshy To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Eventhandlers for CPU state changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 06:28:47 -0000 We currently allow CPUs to be enabled and disabled via the sysctl "machdep.hlt_cpus". CPU enabling and disabling can happen at any time in our current design. It would be useful to have an eventhandler hook so that kernel modules can get notified when a CPU is enabled or disabled. For example, schedulers, memory allocators and drivers that use MSRs inside the CPU could use this information. Here is a straightforward attempt at implementing such an eventhandler: http://perforce.freebsd.org/changeView.cgi?CH=67118 The question however, is about the right kind of semantics for such an eventhandler (The eventhandler above is at best "advisory" in nature). When we notify a module that "CPU X is going to go away", we may still want to allow that module to run on that CPU to cleanup some state (e.g., disable some MSRs). However we may also wish to prevent other kernel threads from getting scheduled onto the to-be-disabled CPU inadvertently. One way of getting around this problem is for schedulers to register two eventhandlers. The first with priority EVENTHANDLER_PRI_FIRST marks CPU X as about to be disabled. Threads will not then get scheduled onto CPU X unless bound to it. The second with priority EVENTHANDLER_PRI_LAST will actually disable CPU X. Suggestions? Comments? From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 08:19:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78D5316A4CE; Fri, 17 Dec 2004 08:19:20 +0000 (GMT) Received: from mail.sam-solutions.net (mail.sam-solutions.net [217.21.35.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F6343D2D; Fri, 17 Dec 2004 08:19:19 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from c71.sam-solutions.net ([217.21.35.67]) by mail.sam-solutions.net with esmtp (Exim 4.34) id 1CfDKY-0000i3-Ke; Fri, 17 Dec 2004 10:19:18 +0200 Received: from mail pickup service by c71.sam-solutions.net with Microsoft SMTPSVC; Fri, 17 Dec 2004 10:19:17 +0200 Received: from mail.sam-solutions.net ([217.21.35.41]) by c71.sam-solutions.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Dec 2004 06:51:30 +0200 Received: from speedy.tutby.com ([195.209.41.194] helo=tut.by) by mail.sam-solutions.net with esmtp (Exim 4.34) id 1CfA5Q-0003rX-P0 for m.boyarov@sam-solutions.net; Fri, 17 Dec 2004 06:51:28 +0200 Received: from by tut.by (CommuniGate Pro RULES 4.1.8) with RULES id 48088987; Fri, 17 Dec 2004 06:51:28 +0200 X-Autogenerated: Mirror X-Mirrored-by: Received: from [195.209.34.110] (HELO tut.by) by tut.by (CommuniGate Pro SMTP 4.1.8) with ESMTP id 48088983 for max_b@tut.by; Fri, 17 Dec 2004 06:51:28 +0200 Received: from mx8.mail.ru ([194.67.23.28] verified) by tut.by (CommuniGate Pro SMTP 4.1.8) with ESMTP id 169004106 for max_b@tut.by; Fri, 17 Dec 2004 07:49:08 +0200 Received: from mail by mx8.mail.ru with local id 1CfA5Q-000IC0-00 for max_b@tut.by; Fri, 17 Dec 2004 07:51:28 +0300 X-ResentFrom: Received: from [216.136.204.119] (port=25 helo=mx2.freebsd.org) by mx8.mail.ru with esmtp id 1CfA5P-000IBn-00 for m.boyarov@bk.ru; Fri, 17 Dec 2004 07:51:27 +0300 Received-SPF: pass (mx8.mail.ru: domain of freebsd.org designates 216.136.204.119 as permitted sender) client-ip=216.136.204.119; envelope-from=owner-freebsd-current@freebsd.org; helo=mx2.freebsd.org; Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 1F83957FE1; Fri, 17 Dec 2004 04:50:43 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9637E16A4DE; Fri, 17 Dec 2004 04:50:33 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BB2D16A4F5; Fri, 17 Dec 2004 04:50:26 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84C0443D3F; Fri, 17 Dec 2004 04:50:25 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.98] (pool-138-88-246-116.res.east.verizon.net [138.88.246.116]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id iBH4oEW12433 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Thu, 16 Dec 2004 23:50:23 -0500 In-Reply-To: <200412131232.55051.max@love2party.net> References: <94AE3F5A-4CD6-11D9-8BD6-000A95C4D7BC@FreeBSD.org> <200412130913.20215.max@love2party.net> <200412131232.55051.max@love2party.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21F934EB-4FE7-11D9-B1F7-000A95C4D7BC@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Thu, 16 Dec 2004 23:50:11 -0500 To: Max Laier X-Mailer: Apple Mail (2.619) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org X-Spam: Not detected X-Spam-Scanned-By: Spamassassin X-Virus-Scanned-By: AVP Antivirus X-OriginalArrivalTime: 17 Dec 2004 04:51:30.0417 (UTC) FILETIME=[130A1610:01C4E3F4] cc: freebsd-current@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: sysctl locking X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 08:19:20 -0000 Hello, On Dec 13, 2004, at 6:32 AM, Max Laier wrote: > 1) Extend sysctl_add_oid() to accept an additional mutex argument. > 2) Extend the simple sysctl handler to use this mutex to protect the > actual > write(?read?). We must not hold the mutex during the useland copy > in/out so > we must move to temporary storage. > 3) To maintain the current API and behavior we use &Giant as the > default > fallback argument. This might need some extension for complex > handler (i.e. > no mutex given -> acquire Giant before calling the complex handler). > > What do people think of this? Does it make any sense? Should we be > concerned > at all? Does the extension make sense? Comments? I have implemented this. The diff is at http://people.freebsd.org/~ssouhlal/sysctl-sx-locking-20041214.diff It also needs the patch at http://people.freebsd.org/~ssouhlal/sx_xlocked.diff which introduces a sx_xlocked() function. Unfortunately, we still need to look at every single SYSCTL_PROC, and make either grab Giant, lock correctly, or make sure it doesn't need any locking. :( -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 12:32:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F43116A4CE for ; Fri, 17 Dec 2004 12:32:04 +0000 (GMT) Received: from hotmail.com (bay14-f24.bay14.hotmail.com [64.4.49.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC0E43D48 for ; Fri, 17 Dec 2004 12:32:04 +0000 (GMT) (envelope-from houyzhuxl@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 17 Dec 2004 04:32:03 -0800 Message-ID: Received: from 61.187.16.2 by by14fd.bay14.hotmail.msn.com with HTTP; Fri, 17 Dec 2004 12:31:45 GMT X-Originating-IP: [61.187.16.2] X-Originating-Email: [houyzhuxl@hotmail.com] X-Sender: houyzhuxl@hotmail.com From: =?gb2312?B?uu4g08I=?= To: freebsd-arch@freebsd.org Date: Fri, 17 Dec 2004 20:31:45 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 17 Dec 2004 12:32:03.0549 (UTC) FILETIME=[69AB68D0:01C4E434] X-Mailman-Approved-At: Fri, 17 Dec 2004 13:00:06 +0000 Subject: Need Your Suggestion! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 12:32:04 -0000 Now,I want to transplant a Journaling filesystem to freebsd. There are some good Journaling filesystem,such as EXT3,JFS,XFS,ReiserFS,etc. Which one should I choose? Or,If the freebsd developers are doing the work,what are they choose? Why? Thanks! _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 13:39:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C71DC16A4CE for ; Fri, 17 Dec 2004 13:39:44 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 2FA3443D48 for ; Fri, 17 Dec 2004 13:39:44 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 85225 invoked by uid 0); 17 Dec 2004 13:38:18 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 17 Dec 2004 13:38:18 -0000 Message-ID: <41C2E1A1.7020400@gamersimpact.com> Date: Fri, 17 Dec 2004 07:39:45 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?GB2312?B?uu4g08I=?= References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit cc: freebsd-arch@freebsd.org Subject: Re: Need Your Suggestion! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 13:39:44 -0000 侯 勇 wrote: > Now,I want to transplant a Journaling filesystem to freebsd. > There are some good Journaling filesystem,such as > EXT3,JFS,XFS,ReiserFS,etc. > Which one should I choose? > Or,If the freebsd developers are doing the work,what are they choose? > Why? > > Thanks! I believe there is someone already working on importing RFS. You might do a search of the archives and see if there's anything you might be able to help with. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 15:48:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 647E016A4CE for ; Fri, 17 Dec 2004 15:48:40 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0EF043D1F for ; Fri, 17 Dec 2004 15:48:39 +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 D9D56C290; Fri, 17 Dec 2004 16:48:38 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id E175540BB; Fri, 17 Dec 2004 16:48:33 +0100 (CET) Date: Fri, 17 Dec 2004 16:48:32 +0100 From: Jeremie Le Hen To: ?? ?? Message-ID: <20041217154832.GS740@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: Need Your Suggestion! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 15:48:40 -0000 > Now,I want to transplant a Journaling filesystem to freebsd. > There are some good Journaling filesystem,such as > EXT3,JFS,XFS,ReiserFS,etc. > Which one should I choose? > Or,If the freebsd developers are doing the work,what are they choose? Why? Try Jean-S閎astien P閐ron . He has a read-only version of ReiserFS which runs on -CURRENT. Regards, -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 16:21:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5DBB16A4CE; Fri, 17 Dec 2004 16:21:47 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCA143D3F; Fri, 17 Dec 2004 16:21:45 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.1/8.13.1) with ESMTP id iBHGLiYU026743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2004 11:21:44 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iBHGLdVQ060467; Fri, 17 Dec 2004 11:21:39 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16835.1939.301128.802993@grasshopper.cs.duke.edu> Date: Fri, 17 Dec 2004 11:21:39 -0500 (EST) To: Jun Su In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: alc@freebsd.org cc: arch@freebsd.org cc: tegge@freebsd.org cc: delphij@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 16:21:47 -0000 Jun Su writes: > Kernel-Only Dump > ============== > We now can use /dev/kmem as the core file. If we can generate a dump file with > the same information with it, then we can enable kernel-only dump with > very limit code changes. > > 1. Change KVM library to support a new type of file that only contains > kernel memory. > 2. Change kernel side to write only kernel memory when dumping. > 3. Change dumpon utility to do the right checking on the partiction size. I think the kernel-only dump is an excellent idea. But I'm confused as to how you would do it. To me, it seems like the most obvious way to do this would be walking the kernel's vm maps. But that does not work on 64-bit platforms which have a direct 1-1 physical/virtual address mapping. So how do you quickly distinguish kernel memory from user memory in the dump routine? I'm probably missing something simple.. Thanks, Drew From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 16:30:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE3CC16A4CE for ; Fri, 17 Dec 2004 16:30:51 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id A89B443D41 for ; Fri, 17 Dec 2004 16:30:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2582 invoked from network); 17 Dec 2004 16:30:51 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 17 Dec 2004 16:30:51 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iBHGUhj1018917; Fri, 17 Dec 2004 11:30:43 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org, Joseph Koshy Date: Fri, 17 Dec 2004 11:17:16 -0500 User-Agent: KMail/1.6.2 References: <84dead7204121622283c51d41a@mail.gmail.com> In-Reply-To: <84dead7204121622283c51d41a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412171117.16971.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Eventhandlers for CPU state changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 16:30:52 -0000 On Friday 17 December 2004 01:28 am, Joseph Koshy wrote: > We currently allow CPUs to be enabled and disabled via the > sysctl "machdep.hlt_cpus". CPU enabling and disabling can > happen at any time in our current design. > > It would be useful to have an eventhandler hook so that kernel > modules can get notified when a CPU is enabled or disabled. > For example, schedulers, memory allocators and drivers that > use MSRs inside the CPU could use this information. > > Here is a straightforward attempt at implementing such an > eventhandler: > http://perforce.freebsd.org/changeView.cgi?CH=67118 > > The question however, is about the right kind of semantics for > such an eventhandler (The eventhandler above is at best > "advisory" in nature). > > When we notify a module that "CPU X is going to go away", we > may still want to allow that module to run on that CPU to cleanup > some state (e.g., disable some MSRs). However we may also wish > to prevent other kernel threads from getting scheduled onto the > to-be-disabled CPU inadvertently. > > One way of getting around this problem is for schedulers to register > two eventhandlers. The first with priority EVENTHANDLER_PRI_FIRST > marks CPU X as about to be disabled. Threads will not then get scheduled > onto CPU X unless bound to it. The second with priority > EVENTHANDLER_PRI_LAST will actually disable CPU X. > > Suggestions? Comments? I think this is a good first step to getting ULE to work with the hlt_cpus stuff. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 20:59:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D872D16A4CE; Fri, 17 Dec 2004 20:59:25 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 632ED43D1D; Fri, 17 Dec 2004 20:59:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CfPC8-0007zP-00; Fri, 17 Dec 2004 21:59:24 +0100 Received: from [217.227.152.17] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CfPC7-0004cA-00; Fri, 17 Dec 2004 21:59:24 +0100 From: Max Laier To: freebsd-arch@freebsd.org Date: Fri, 17 Dec 2004 21:59:15 +0100 User-Agent: KMail/1.7.1 References: <94AE3F5A-4CD6-11D9-8BD6-000A95C4D7BC@FreeBSD.org> <200412131232.55051.max@love2party.net> <21F934EB-4FE7-11D9-B1F7-000A95C4D7BC@FreeBSD.org> In-Reply-To: <21F934EB-4FE7-11D9-B1F7-000A95C4D7BC@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12125019.tk7FQXOsAd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412172159.22871.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-current@freebsd.org cc: Suleiman Souhlal Subject: Re: sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 20:59:26 -0000 --nextPart12125019.tk7FQXOsAd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 17 December 2004 05:50, Suleiman Souhlal wrote: > Hello, > > On Dec 13, 2004, at 6:32 AM, Max Laier wrote: > > 1) Extend sysctl_add_oid() to accept an additional mutex argument. > > 2) Extend the simple sysctl handler to use this mutex to protect the > > actual > > write(?read?). We must not hold the mutex during the useland copy > > in/out so > > we must move to temporary storage. > > 3) To maintain the current API and behavior we use &Giant as the > > default > > fallback argument. This might need some extension for complex > > handler (i.e. > > no mutex given -> acquire Giant before calling the complex handler). > > > > What do people think of this? Does it make any sense? Should we be > > concerned > > at all? Does the extension make sense? Comments? > > I have implemented this. The diff is at > http://people.freebsd.org/~ssouhlal/sysctl-sx-locking-20041214.diff It still looks like you call oid_handler() without grabbing the lock. You=20 should do this at least for the "oid_mtx =3D=3D &Giant"-case and - in my op= inion=20 =2D it should be done for the default case as well, so that oid_handler() c= an=20 assert the mutex. > It also needs the patch at > http://people.freebsd.org/~ssouhlal/sx_xlocked.diff which introduces a > sx_xlocked() function. Just spotted an error: @@ -884,10 +1015,14 @@ outlen =3D strlen((char *)arg1)+1; tmparg =3D malloc(outlen, M_SYSCTLTMP, M_WAITOK); =20 + if (oidp->oid_mtx) + mtx_lock(oidp->oid_mtx); if (strlcpy(tmparg, (char *)arg1, outlen) >=3D outlen) { free(tmparg, M_SYSCTLTMP); goto retry; <--- this will break the lock order, no? } + if (oidp->oid_mtx) + mtx_unlock(oidp->oid_mtx); =20 error =3D SYSCTL_OUT(req, tmparg, outlen); free(tmparg, M_SYSCTLTMP); > Unfortunately, we still need to look at every single SYSCTL_PROC, and > make either grab Giant, lock correctly, or make sure it doesn't need > any locking. :( =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 --nextPart12125019.tk7FQXOsAd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBw0iqXyyEoT62BG0RArpeAJ9jrVuSwJYl6GqiYfEVaoVty34u/ACeOadk 0rIxAblyICRqPlD8cxn/6IQ= =S50c -----END PGP SIGNATURE----- --nextPart12125019.tk7FQXOsAd-- From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 21:00:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 128D116A4CE for ; Fri, 17 Dec 2004 21:00:08 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9516B43D5A for ; Fri, 17 Dec 2004 21:00:07 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 9335 invoked from network); 17 Dec 2004 21:00:07 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Dec 2004 21:00:06 -0000 Received: from hydrogen.funkthat.com (qxabuf@localhost.funkthat.com [127.0.0.1])iBHL06GH051416; Fri, 17 Dec 2004 13:00:06 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id iBHL05OD051414; Fri, 17 Dec 2004 13:00:05 -0800 (PST) Date: Fri, 17 Dec 2004 13:00:05 -0800 From: John-Mark Gurney To: Max Laier Message-ID: <20041217210004.GZ19624@funkthat.com> Mail-Followup-To: Max Laier , freebsd-current@freebsd.org, Suleiman Souhlal , freebsd-arch@freebsd.org References: <94AE3F5A-4CD6-11D9-8BD6-000A95C4D7BC@FreeBSD.org> <200412130913.20215.max@love2party.net> <200412131232.55051.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412131232.55051.max@love2party.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE 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-current@freebsd.org cc: Suleiman Souhlal cc: freebsd-arch@freebsd.org Subject: Re: sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 21:00:08 -0000 Max Laier wrote this message on Mon, Dec 13, 2004 at 12:32 +0100: > If we come to the conclusion that it is required to protect these values > better, I suggest the following: > > 1) Extend sysctl_add_oid() to accept an additional mutex argument. > 2) Extend the simple sysctl handler to use this mutex to protect the actual > write(?read?). We must not hold the mutex during the useland copy in/out so > we must move to temporary storage. > 3) To maintain the current API and behavior we use &Giant as the default > fallback argument. This might need some extension for complex handler (i.e. > no mutex given -> acquire Giant before calling the complex handler). > > What do people think of this? Does it make any sense? Should we be concerned > at all? Does the extension make sense? Comments? If all one is doing is a single read or a single write, then a mutex is not needed... Since you are not syncronizing with something else or doing a write based on a read (i.e atomic increment, etc), the read/write could happen at any order.. Only if the entire value can not be written atomicly (like 64 bit ints of 486's, Pentiums have an 8 byte xchng op) would a mutex be helpful... In the kqueue case, there is a function knlist_empty that originally would obtain the lock, read the value and then unlock.. This was pointless since any state returned by the function would be stale and any decision made on it would be bogus... It was changed to require that the calling function hold the lock so that the state was consistent with the subsequent decission... If a sysctl needs that level of protection, it seems like they need to be writing their own custom handler to handle the required interactions.. -- 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-arch@FreeBSD.ORG Sat Dec 18 09:39:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1193316A4D0 for ; Sat, 18 Dec 2004 09:39:38 +0000 (GMT) Received: from dedicated.gogr.net (207-36-15-160.ptr.primarydns.com [207.36.15.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E38843D55 for ; Sat, 18 Dec 2004 09:39:37 +0000 (GMT) (envelope-from info@infomarine.gr) Received: from localhost (localhost.localdomain [127.0.0.1]) by dedicated.gogr.net (8.11.6/8.11.6) with SMTP id iBI9XLH02291 for ; Sat, 18 Dec 2004 09:33:21 GMT Date: Sat, 18 Dec 2004 09:33:21 GMT Message-Id: <200412180933.iBI9XLH02291@dedicated.gogr.net> To: freebsd-arch@freebsd.org From: info@infomarine.gr X-Mailer: Perl Powered Socket Mailer Subject: Merry Cristmas from Infomarine On-Line X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: info@infomarine.gr List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 09:39:38 -0000 The management and staff from our office Infomarine On-Line at www.infomarine.gr would like to take this opportunity to wish you all a Merry Christmas and a Prosperous 2004. To pick up your cards, simply point your browser at the page listed below. www.infomarine.gr/cards/dec12-8884132590.html We are delighted to send your Greetings card to your friends via the link below. www.infomarine.gr/indextopcards.htm ============================================ Infomarine On-line www.infomarine.gr www.domainmarine.com www.infomarine.net www.gogr.gr www.marineterms.com 29, Plastira St. N.Erithrea 146-71 Athens - Greece Tel: +30-210- 620-4792 Fax: +30-210- 620-4793 From owner-freebsd-arch@FreeBSD.ORG Sat Dec 18 17:51:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E353616A4CE for ; Sat, 18 Dec 2004 17:51:59 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D33143D49 for ; Sat, 18 Dec 2004 17:51:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iBIHpvic067698 for ; Sat, 18 Dec 2004 18:51:57 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Sat, 18 Dec 2004 18:51:57 +0100 Message-ID: <67697.1103392317@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Forcefully unmounting devfs... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 17:52:00 -0000 Brainteaser for the x-mas days: What is the correct handling of busy device vnodes belonging to a devfs mountpoint which is being forcefully unmounted ? If you think this has a simple answer, please don't bother replying. -- 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.