From owner-freebsd-arch Sun Apr 15 8:27:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id E959137B440 for ; Sun, 15 Apr 2001 08:27:41 -0700 (PDT) (envelope-from oppermann@monzoon.net) Received: (qmail 90263 invoked from network); 15 Apr 2001 15:27:30 -0000 Received: from unknown (HELO monzoon.net) ([195.134.148.7]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 15 Apr 2001 15:27:30 -0000 Message-ID: <3AD9BDD1.E5329F3E@monzoon.net> Date: Sun, 15 Apr 2001 17:27:13 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis Cc: Duncan Barclay , freebsd-arch@FreeBSD.ORG Subject: Re: Use of if_ef for 802.11 interfaces? References: <3AD6CD6E.104C6DD9@monzoon.net> <20010413102444.C664@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brooks Davis wrote: > > On Fri, Apr 13, 2001 at 11:57:02AM +0200, Andre Oppermann wrote: > > > A couple of practical points arise for outgoing packets revolving > > > around the type of 802.11 network in use (infrastructure or adhoc) > > > that would involve if_ef knowing what mode the interface is in and the > > > BSSID. We have some common support for this in the form of the recent > > > (uncommitted) patches to ifconfig PR25577. > > > > Wireless support in ifconfig would be really a good thing IMHO. But > > this brings the need of a well thought out interface between ifconfig > > and the wireless card drivers. > > What, if anything, is wrong with the interface proposed in PR 25577? Nothing, maybe except that there is no IOCTL defined for "microwave oven rubustness" (which is another way to say "don't fallback too fast on transmission errors"). :-) -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 5:54:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C6E0137B42C; Mon, 16 Apr 2001 05:54:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3GCsFU02210; Mon, 16 Apr 2001 14:54:16 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, audit@freebsd.org Subject: [PATCH] Axing VOP_BWRITE From: Poul-Henning Kamp Date: Mon, 16 Apr 2001 14:54:15 +0200 Message-ID: <2208.987425655@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have made a patch which axes VOP_BWRITE: http://phk.freebsd.dk/patch/buf_write.patch 20010416 buf_write.patch This patch removes the VOP_BWRITE() vector. VOP_BWRITE() was a hack which made it possible for NFS client side to use struct buf with non-bio backing. This patch takes a more general approach and adds a bp->b_op vector where more methods can be added. The success of this patch depends on bp->b_op being initialized all relevant places for some value of "relevant" which is not easy to determine. As a followup to this patch, all uses of bwrite(bp) should be changed to BUF_BWRITE(bp) -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 9:21: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 43B0637B43E for ; Mon, 16 Apr 2001 09:21:01 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f3GGKoF08501; Mon, 16 Apr 2001 09:20:50 -0700 Date: Mon, 16 Apr 2001 09:20:50 -0700 From: Brooks Davis To: Andre Oppermann Cc: Brooks Davis , Duncan Barclay , freebsd-arch@FreeBSD.ORG Subject: Re: Use of if_ef for 802.11 interfaces? Message-ID: <20010416092050.A6076@Odin.AC.HMC.Edu> References: <3AD6CD6E.104C6DD9@monzoon.net> <20010413102444.C664@Odin.AC.HMC.Edu> <3AD9BDD1.E5329F3E@monzoon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AD9BDD1.E5329F3E@monzoon.net>; from oppermann@monzoon.net on Sun, Apr 15, 2001 at 05:27:13PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2001 at 05:27:13PM +0200, Andre Oppermann wrote: > Nothing, maybe except that there is no IOCTL defined for "microwave > oven rubustness" (which is another way to say "don't fallback too > fast on transmission errors"). That's easy enough to add. I assume it's just a boolean or integer parameter? The interface supports 2^16-1 options so it's not going to be a real problem to add more. You just add a new #define at the end if sys/net/if_ieee80211.h and and entry in share/man/man4/ieee80211.4 describing what the heck it does. The interface also needs more status gathering functions to get signal strenght and the like for GUI tools. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE62xvhXY6L6fI4GtQRAp+SAKDmhNVejWfq5I6g2xqtQWjk2wjARgCgxfYM bgWZjHowgB4AIrzn9HG74Hg= =7vY0 -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 14:41:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id B31AB37B440 for ; Mon, 16 Apr 2001 14:41:35 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 62218 invoked from network); 16 Apr 2001 21:41:23 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.21.67]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 16 Apr 2001 21:41:23 -0000 Message-ID: <3ADB66F3.66E60281@telehouse.ch> Date: Mon, 16 Apr 2001 23:41:07 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis Cc: Andre Oppermann , Duncan Barclay , freebsd-arch@FreeBSD.ORG Subject: Re: Use of if_ef for 802.11 interfaces? References: <3AD6CD6E.104C6DD9@monzoon.net> <20010413102444.C664@Odin.AC.HMC.Edu> <3AD9BDD1.E5329F3E@monzoon.net> <20010416092050.A6076@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brooks Davis wrote: > > On Sun, Apr 15, 2001 at 05:27:13PM +0200, Andre Oppermann wrote: > > Nothing, maybe except that there is no IOCTL defined for "microwave > > oven rubustness" (which is another way to say "don't fallback too > > fast on transmission errors"). > > That's easy enough to add. I assume it's just a boolean or integer > parameter? The interface supports 2^16-1 options so it's not going to > be a real problem to add more. You just add a new #define at the end if > sys/net/if_ieee80211.h and and entry in share/man/man4/ieee80211.4 > describing what the heck it does. The interface also needs more status > gathering functions to get signal strenght and the like for GUI tools. I'd say your patch is a very good starting point and framewort to which everthing else, is desired, can be added later. PHK assigned himself to your PR with the patch but told me this weekend that he'd hold back until (appearently) this discussion is finished. IMO he can go ahead and commit it. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 16:53:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id C31B937B423; Mon, 16 Apr 2001 16:53:14 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id QAA55416; Mon, 16 Apr 2001 16:53:08 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200104162353.QAA55416@beastie.mckusick.com> To: Robert Watson Subject: Re: Background Fsck Cc: arch@freebsd.org In-Reply-To: Your message of "Thu, 05 Apr 2001 00:50:27 EDT." Date: Mon, 16 Apr 2001 16:53:08 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Thu, 5 Apr 2001 00:50:27 -0400 (EDT) From: Robert Watson To: Kirk McKusick cc: arch@freebsd.org Subject: Re: Background Fsck Kirk, Another usability question. Was wondering about the possibility of multiple background fsck's getting started at a time, et al, possibly due to bad behavior by the user. Can the user get shot in the foot in the following situations: 1) They unmount a file system during a background fsck -- not all that unlikely. (Assuming that fsck keeps a file open for use with the sysctl, or possibly eventually vfsop, a non-forcible unmount should get EBUSY, but not sure what a forcible unmount will do). In the event of a normal unmount request, it will fail with EBUSY. In the event of a forcible unmount, a read or sysctl will fail causing the fsck to terminate with an error. 2) They start a second background fsck running at the same time as the first. This would be indeterminate in the same way as running two foreground fsck's on the same filesystem would be indeterminate. This failure senario has not been considered problematic in the past, so is not guarded against. 3) They perform a remount, possibly changing between read-only and read-write. A background fsck will fail on a read-only filesystem. If the filesystem is downgraded to read-only, a background fsck will fail (and exit) on its next sysctl that attempts to write data. At the moment, it is not possible to toggle soft updates with mount options. If this capability were added, seriously bad things could happen if soft updates were disabled while a background fsck was in progress. In some of these, it may be OK for the user to be shot in the foot, but it might be worth considering strategies to prevent foot-shooting, especially in the case of remount situations. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services Only (2) seems to be a problem, and it has not proven to be an issue in years past. If it is perceived to be a bigger problem now, a fix could be found. A general solution would be to flock the underlying special device as this would work for both foreground and background fsck. At the moment, the /dev filesystem cannot handle advisory file locks, so some serious work would be needed there first. If only background fsck is considered to be an issue, then an flock could be held on the mount point directory. This latter approach seems half baked to me, so I am not inclined to do it. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 16:57:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 3D3EA37B43C; Mon, 16 Apr 2001 16:57:51 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id QAA55446; Mon, 16 Apr 2001 16:57:42 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200104162357.QAA55446@beastie.mckusick.com> To: Alexander Leidinger Subject: Re: Background Fsck Cc: rwatson@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: Your message of "Thu, 05 Apr 2001 11:38:50 +0200." <200104050938.f359ctI09858@Magelan.Leidinger.net> Date: Mon, 16 Apr 2001 16:57:42 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Thu, 5 Apr 2001 11:38:50 +0200 (CEST) From: Alexander Leidinger Subject: Re: Background Fsck To: rwatson@FreeBSD.ORG Cc: mckusick@mckusick.com, arch@FreeBSD.ORG On 5 Apr, Robert Watson wrote: Another usability question. Was wondering about the possibility of multiple background fsck's getting started at a time, et al, possibly due to bad behavior by the user. Can the user get shot in the foot in the following situations: [1-3] 4) They shutdown the machine while the background fsck is in progress. Bye, Alexander. The background fsck is using the soft updates system to make its changes to the filesystem. So, as with all the other concurrent changes going on, they are ordered so as to maintain filesystem consistency. Whether the system is shut down cleanly or abruptly while a background fsck is in progress, the filesystem will be recoverable. When a new background fsck is eventually started on the partially checked filesystem, it will simply pick up where the other one left off. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 18:17:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D165C37B42C; Mon, 16 Apr 2001 18:17:09 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3H1H8W22810; Mon, 16 Apr 2001 18:17:08 -0700 (PDT) Date: Mon, 16 Apr 2001 18:17:08 -0700 From: Alfred Perlstein To: Kirk McKusick Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: Background Fsck Message-ID: <20010416181708.P976@fw.wintelcom.net> References: <200104162353.QAA55416@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104162353.QAA55416@beastie.mckusick.com>; from mckusick@mckusick.com on Mon, Apr 16, 2001 at 04:53:08PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kirk McKusick [010416 16:53] wrote: > > Only (2) seems to be a problem, and it has not proven to be an issue in > years past. If it is perceived to be a bigger problem now, a fix could be > found. A general solution would be to flock the underlying special device > as this would work for both foreground and background fsck. At the moment, > the /dev filesystem cannot handle advisory file locks, so some serious > work would be needed there first. If only background fsck is considered > to be an issue, then an flock could be held on the mount point directory. > This latter approach seems half baked to me, so I am not inclined to do it. Actually Terry Lambert has some really old patches that make flock on just about any vnode backed fd work. Do we want this? I think I can re-forward-port his delta to achieve this. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 18:42: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 32A1637B423; Mon, 16 Apr 2001 18:42:01 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3H1ft887670; Mon, 16 Apr 2001 18:41:55 -0700 (PDT) (envelope-from dillon) Date: Mon, 16 Apr 2001 18:41:55 -0700 (PDT) From: Matt Dillon Message-Id: <200104170141.f3H1ft887670@earth.backplane.com> To: Alfred Perlstein Cc: Kirk McKusick , Robert Watson , arch@FreeBSD.ORG Subject: Re: Background Fsck References: <200104162353.QAA55416@beastie.mckusick.com> <20010416181708.P976@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> the /dev filesystem cannot handle advisory file locks, so some serious :> work would be needed there first. If only background fsck is considered :> to be an issue, then an flock could be held on the mount point directory. :> This latter approach seems half baked to me, so I am not inclined to do it. : :Actually Terry Lambert has some really old patches that make flock on :just about any vnode backed fd work. : :Do we want this? I think I can re-forward-port his delta to achieve this. : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] It makes sense. I think Linux does this and it definitely seems useful. Anyone know about Solaris? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 20:27:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ambrisko.com (adsl-216-103-208-74.dsl.snfc21.pacbell.net [216.103.208.74]) by hub.freebsd.org (Postfix) with ESMTP id D1E1D37B43E for ; Mon, 16 Apr 2001 20:27:31 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.3/8.11.2) id f3H3Q4r64528; Mon, 16 Apr 2001 20:26:04 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200104170326.f3H3Q4r64528@ambrisko.com> Subject: Re: Use of if_ef for 802.11 interfaces? In-Reply-To: <3ADB66F3.66E60281@telehouse.ch> "from Andre Oppermann at Apr 16, 2001 11:41:07 pm" To: Andre Oppermann Date: Mon, 16 Apr 2001 20:26:04 -0700 (PDT) Cc: Brooks Davis , Andre Oppermann , Duncan Barclay , freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andre Oppermann writes: | Brooks Davis wrote: | > | > On Sun, Apr 15, 2001 at 05:27:13PM +0200, Andre Oppermann wrote: | > > Nothing, maybe except that there is no IOCTL defined for "microwave | > > oven rubustness" (which is another way to say "don't fallback too | > > fast on transmission errors"). | > | > That's easy enough to add. I assume it's just a boolean or integer | > parameter? The interface supports 2^16-1 options so it's not going to | > be a real problem to add more. You just add a new #define at the end if | > sys/net/if_ieee80211.h and and entry in share/man/man4/ieee80211.4 | > describing what the heck it does. The interface also needs more status | > gathering functions to get signal strenght and the like for GUI tools. | | I'd say your patch is a very good starting point and framewort to | which everthing else, is desired, can be added later. | | PHK assigned himself to your PR with the patch but told me this | weekend that he'd hold back until (appearently) this discussion is | finished. IMO he can go ahead and commit it. I agree it should be commited. There are some implementation issues in the Cisco/Aironet driver that need fixing (not his fault, existing confusion and strangeness of the card). Getting this commited would reduce a level of complexity of patches that I'm maintaining for the Aironet driver. Also it will be interesting how we support LEAP that requires a user name passwd to be entered. I'm just starting to investigate that. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 16 21:36:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 2619337B43C for ; Mon, 16 Apr 2001 21:36:53 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f3H4adv32146; Mon, 16 Apr 2001 21:36:39 -0700 Date: Mon, 16 Apr 2001 21:36:39 -0700 From: Brooks Davis To: Doug Ambrisko Cc: Andre Oppermann , Andre Oppermann , Duncan Barclay , freebsd-arch@FreeBSD.ORG Subject: Re: Use of if_ef for 802.11 interfaces? Message-ID: <20010416213639.A27836@Odin.AC.HMC.Edu> References: <3ADB66F3.66E60281@telehouse.ch> <200104170326.f3H3Q4r64528@ambrisko.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104170326.f3H3Q4r64528@ambrisko.com>; from ambrisko@ambrisko.com on Mon, Apr 16, 2001 at 08:26:04PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2001 at 08:26:04PM -0700, Doug Ambrisko wrote: > Also it will be interesting how we support LEAP that requires a user name > passwd to be entered. I'm just starting to investigate that. I beleve windows does this via a tray icon. It seems to me that this problem is probably best handled by an entierly different machanism. We could add a stupid IEEE80211_IOC_EAP_INFO ioctl to set it, but I feel that's an invalid solution because it discounts valid options like using one time passwords for network authentication. Also, the user to be entering this data is the one on the console, not necessicairly the administrator of the system so privs get confused. Finally, this problem is very similar to other problems such as cfs key prompting. For these reason, I don't think a ioctl really provides an appropriate interface for this functionality. I think the thing it's closest too today is devd (the currently non-existant replacement for pccard, usbd, etc) except that the devd static implementation is really just the special case for embeded solutions and in other cases you will actually need to prompt the user. That's the hard part. For some UIs prompting the user is pretty obvious. In KDE or Gnome, you create something that sits on a socket or device node and prompts the users when the kernel tells it to. For the console, it's much more complicated. The only solutions I've come up with involve biff or wall like async notification coupled with a program users can run to handle outstanding requests. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE628hXXY6L6fI4GtQRAk/MAKCsMNV2TWn2+oQawF5NwNdh3sD+PgCg2W25 U3Mkhpacw17vu17W2whnATQ= =Xg5V -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 17 11:32:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by hub.freebsd.org (Postfix) with ESMTP id AB7A637B424 for ; Tue, 17 Apr 2001 11:32:46 -0700 (PDT) (envelope-from bmah@cisco.com) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id LAA24745; Tue, 17 Apr 2001 11:30:26 -0700 (PDT) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.3/8.11.1) id f3HIVQD92660; Tue, 17 Apr 2001 11:31:26 -0700 (PDT) (envelope-from bmah) Message-Id: <200104171831.f3HIVQD92660@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4 To: Brooks Davis Cc: Doug Ambrisko , Andre Oppermann , Andre Oppermann , Duncan Barclay , freebsd-arch@FreeBSD.ORG Subject: Re: Use of if_ef for 802.11 interfaces? In-Reply-To: <20010416213639.A27836@Odin.AC.HMC.Edu> References: <3ADB66F3.66E60281@telehouse.ch> <200104170326.f3H3Q4r64528@ambrisko.com> <20010416213639.A27836@Odin.AC.HMC.Edu> Comments: In-reply-to Brooks Davis message dated "Mon, 16 Apr 2001 21:36:39 -0700." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_280080484P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 17 Apr 2001 11:31:26 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --==_Exmh_280080484P Content-Type: text/plain; charset=us-ascii If memory serves me right, Brooks Davis wrote: > On Mon, Apr 16, 2001 at 08:26:04PM -0700, Doug Ambrisko wrote: > > Also it will be interesting how we support LEAP that requires a user name > > passwd to be entered. I'm just starting to investigate that. > > I beleve windows does this via a tray icon. It seems to me that this > problem is probably best handled by an entierly different machanism. I think for Windows, LEAP authentication works by grabbing the username from the Windows network login. I dimly remember some of the user documentation with screenshots showing something to this effect also. Clearly this doesn't work for a multiuser *NIX box, for the reasons you pointed out...I haven't played with the Linux utilities to see what they do. Bruce. --==_Exmh_280080484P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE63Iv+2MoxcVugUsMRAmPJAKChFvdqGjnIvuwYFb9fULJ8Inu/FQCg5ywg ctAZVmwGhOQxDt2D7d7aTFY= =jNqn -----END PGP SIGNATURE----- --==_Exmh_280080484P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 17 11:44:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ambrisko.com (adsl-216-103-208-74.dsl.snfc21.pacbell.net [216.103.208.74]) by hub.freebsd.org (Postfix) with ESMTP id 3F9A237B43E; Tue, 17 Apr 2001 11:44:34 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.3/8.11.2) id f3HIiQD69701; Tue, 17 Apr 2001 11:44:26 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200104171844.f3HIiQD69701@ambrisko.com> Subject: Re: Use of if_ef for 802.11 interfaces? In-Reply-To: <200104171831.f3HIVQD92660@bmah-freebsd-0.cisco.com> "from Bruce A. Mah at Apr 17, 2001 11:31:26 am" To: bmah@FreeBSD.ORG Date: Tue, 17 Apr 2001 11:44:26 -0700 (PDT) Cc: Brooks Davis , Doug Ambrisko , Andre Oppermann , Andre Oppermann , Duncan Barclay , freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce A. Mah writes: | If memory serves me right, Brooks Davis wrote: | > On Mon, Apr 16, 2001 at 08:26:04PM -0700, Doug Ambrisko wrote: | > > Also it will be interesting how we support LEAP that requires a user name | > > passwd to be entered. I'm just starting to investigate that. | > | > I beleve windows does this via a tray icon. It seems to me that this | > problem is probably best handled by an entierly different machanism. | | I think for Windows, LEAP authentication works by grabbing the username | from the Windows network login. I dimly remember some of the user | documentation with screenshots showing something to this effect also. I haven't played with this on Windows ... I try to avoid that. | Clearly this doesn't work for a multiuser *NIX box, for the reasons you | pointed out...I haven't played with the Linux utilities to see what | they do. Under Linux the "acu" utility asks for a Username/Password for LEAP but I haven't tried it yet. BTW I now have a sysctl added to the "an" driver to dump Rid records so I can see what the Linux utilities are doing and then compare them to what we do. So I should be able to sniff what the Cisco utility is doing for LEAP at the Rid level. I also added a filter to dump only selected Rids but I have a bug that hangs my machine when I try to parse out the hex number :-(. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 17 12: 0: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 8F2C837B43F; Tue, 17 Apr 2001 12:00:00 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2LLW6G3D; Tue, 17 Apr 2001 14:59:55 -0400 Reply-To: Randell Jesup To: Kirk McKusick Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: Background Fsck References: <200104162353.QAA55416@beastie.mckusick.com> From: Randell Jesup Date: 17 Apr 2001 15:03:52 -0400 In-Reply-To: Kirk McKusick's message of "Mon, 16 Apr 2001 16:53:08 -0700" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kirk McKusick writes: > 2) They start a second background fsck running at the same time as the > first. > >This would be indeterminate in the same way as running two foreground >fsck's on the same filesystem would be indeterminate. This failure >senario has not been considered problematic in the past, so is not >guarded against. ... >Only (2) seems to be a problem, and it has not proven to be an issue in >years past. If it is perceived to be a bigger problem now, a fix could be >found. A general solution would be to flock the underlying special device >as this would work for both foreground and background fsck. At the moment, >the /dev filesystem cannot handle advisory file locks, so some serious >work would be needed there first. I personally don't like leaving uzi's around with the trigger-lock removed. Admittedly, no one here would pick it up - or at least they wouldn't admit to it later... ;-) I think we should take a shot at adding the lock code that someone else apparently did a while back and close this hole. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 10: 6:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id DCAB637B423 for ; Wed, 18 Apr 2001 10:06:21 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 1539 invoked by uid 1000); 18 Apr 2001 17:04:49 -0000 Date: Wed, 18 Apr 2001 20:04:49 +0300 From: Peter Pentchev To: Mikhail Kruk Cc: Victor Ivanov , freebsd-security@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: /root and users home dir permissions Message-ID: <20010418200449.D582@ringworld.oblivion.bg> Mail-Followup-To: Mikhail Kruk , Victor Ivanov , freebsd-security@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20010418173927.A64529@icon.icon.bg> <20010418200206.C582@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010418200206.C582@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Apr 18, 2001 at 08:02:06PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, so I forgot to CC it to -arch :) So here we go again :) G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. On Wed, Apr 18, 2001 at 08:02:06PM +0300, Peter Pentchev wrote: > CC'd to -arch, although I guess most of the people interested are > already on -security anyway.. > > On Wed, Apr 18, 2001 at 11:27:42AM -0400, Mikhail Kruk wrote: > > > Hi all, > > > > > > I noticed /root is installed with mode=0755 (and updated every time by > > > installworld). It's the root home directory... some admins (like me) are > > > using it for keeping sensitive data away from regular users. Shouldn't it > > > be mode=0700 in /etc/mtree/BSD.root.dist? > > > > I don't think changes like this can be made all of a sudden. Some people > > might be using /root for something which requires it to be readable and we > > don't want to break things... > > > > > Also, when adding new users their home directories should be protected the > > > same way. Am I wrong? > > > > I strongly agree with that. This change seems to be ok in terms of > > breaking existing systems and people have no business in other users' > > directories. > > OK, I think Victor shall cede the /root case - after all, we're all free > to make local mods to the mtree files and all, right? :) > > About adduser.. what do people think about the attached patch? > Or should that ugly regexp also check for numeric modes? Index: src/usr.sbin/adduser/adduser.perl =================================================================== RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.perl,v retrieving revision 1.45 diff -u -r1.45 adduser.perl --- src/usr.sbin/adduser/adduser.perl 2001/04/17 09:42:07 1.45 +++ src/usr.sbin/adduser/adduser.perl 2001/04/18 16:59:19 @@ -39,6 +39,7 @@ $config_read = 1; # read config file $logfile = "/var/log/adduser"; # logfile $home = "/home"; # default HOME + $home_perm = "u+wrX,go-w"; # default permissions on HOME $etc_shells = "/etc/shells"; $etc_passwd = "/etc/master.passwd"; $group = "/etc/group"; @@ -219,6 +220,33 @@ return 0; } +# return the default permissions' string for HOME +sub home_permissions { + local($perm) = @_; + local($p) = $perm; + + return $p if !$verbose && $p eq &home_permissions_valid($p); + + while(1) { + $p = &confirm_list("Enter your default HOME permissions:", 1, $perm, ""); + last if $p eq &home_permissions_valid($p); + } + + $changes++ if $p ne $perm; + return $p; +} + +# check for valid permissions +sub home_permissions_valid { + local($perm) = @_; + + if ($perm =~ /^((([ugo]+[+-][rwxX]+),?)+)/) { + return $1; + } else { + return ""; + } +} + # check for valid passwddb sub passwd_check { system("$pwd_mkdb -C $etc_passwd"); @@ -939,16 +967,17 @@ if (!mkdir("$homedir", 0755)) { warn "$dir: $!\n"; return 0; } - system 'chown', "$name:$group", $homedir; + system("chmod", "$home_perm", "$homedir"); + system("chown", "$name:$group", "$homedir"); return !$?; } # copy files from $dotdir to $homedir # rename 'dot.foo' files to '.foo' print "Copy files from $dotdir to $homedir\n" if $verbose; - system("cp -R $dotdir $homedir"); - system("chmod -R u+wrX,go-w $homedir"); - system("chown -R $name:$group $homedir"); + system("cp", "-R", "$dotdir", "$homedir"); + system("chmod", "-R", "$home_perm", "$homedir"); + system("chown", "-R", "$name:$group", "$homedir"); # security opendir(D, $homedir); @@ -1332,6 +1361,9 @@ # default HOME directory ("/home") home = "$home" +# default permissions on HOME ("u+wrX,go-w") +home_perm = "$home_perm"; + # List of directories where shells located # path = ('/bin', '/usr/bin', '/usr/local/bin') path = ($shpath) @@ -1391,6 +1423,7 @@ &shells_add; # maybe add some new shells $defaultshell = &shell_default; # enter default shell $home = &home_partition($home); # find HOME partition +$home_perm = &home_permissions($home_perm); # set HOME permissions $dotdir = &dotdir_default; # check $dotdir $send_message = &message_default; # send message to new user $defaultpasswd = &password_default; # maybe use password To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 11:21: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 1B5BE37B423 for ; Wed, 18 Apr 2001 11:20:59 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id LAA02572 for ; Wed, 18 Apr 2001 11:20:57 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAjwaiaf; Wed Apr 18 11:20:51 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA17706 for arch@freebsd.org; Wed, 18 Apr 2001 11:26:23 -0700 (MST) From: Terry Lambert Message-Id: <200104181826.LAA17706@usr02.primenet.com> Subject: Reference counters To: arch@freebsd.org Date: Wed, 18 Apr 2001 18:26:23 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As some people undoubtedly know, I've been fighting a bug with credential reference counts, which appears to be related to a close race under extreme load. The architecture of the reference counting is extremely incompatible with tracking this bug down. I would like to propose that the reference counting be substantially changed, and that a general philosophy be adopted in place of the current philosophy. First, some minor discussion. -- Here code from kern/kern_descrip.c: fsetown() crhold(curproc->p_ucred); sigio->sio_ucred = curproc->p_ucred; falloc() fp->f_cred = p->p_ucred; fp->f_ops = &badfileops; fp->f_seqcount = 1; crhold(fp->f_cred); kern/uipc_socket2.c: sonewconn3() so->so_cred = p ? p->p_ucred : head->so_cred; crhold(so->so_cred); kern/uipc_socket.c: socreate() so->so_cred = p->p_ucred; crhold(so->so_cred); kern/kern_fork.c: fork1() MALLOC(p2->p_cred, struct pcred *, sizeof(struct pcred), M_SUBPROC, M_WAITOK); bcopy(p1->p_cred, p2->p_cred, sizeof(*p2->p_cred)); p2->p_cred->p_refcnt = 1; crhold(p1->p_ucred); uihold(p1->p_cred->p_uidinfo); -------------- Except for this last code (which is amazingly distressing to me; it's probably going to turn out to be the ultimate source of the problem I'm seeing), this code lends itself to cleanup; specifically: fsetown() sigio->sio_ucred = crhold(curproc->p_ucred); falloc() fp->f_ops = &badfileops; fp->f_seqcount = 1; fp->f_cred = crhold(p->p_ucred); sonewconn3() so->so_cred = p ? crhold(p->p_ucred) : crhold(head->so_cred); etc.. This would let the crhold() function be replaced with a resource tracking macro version. This would let me identify the instance of the reference allocation which is being doubly freed somewhere in my list of 30,000 descriptors, and -- more important -- with instrumentation, permit me to identify the origin allocation. Specifically, I can relace crhold() with crdup(), and I get the actual double free that's the problem, instead of the last free). I further siggest that _ALL_ reference holds in FreeBSD receive similar treatment. Discussion? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 11:37:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EE16137B43C for ; Wed, 18 Apr 2001 11:37:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA05138; Wed, 18 Apr 2001 11:37:05 -0700 Date: Wed, 18 Apr 2001 11:37:04 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: arch@freebsd.org Subject: Re: Reference counters In-Reply-To: <200104181826.LAA17706@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I tracked a similar bug in SunOS 3.5. It's nice to know things haven't changed. It actually turned out that the bug was a constantly incrementing crhold- not an extra crfree as people had been breaking their teeth on finding. Are there any spots in the code that do plain holds that do *not* imply the assignment of a credp into a structure? If you can assert that any crhold or crdup must return a pointer and any crfree must have an address of a pointer to NULL, you're probably most of the way toward finding the errant action. It also seems to me that one issue that can keep coming up is the freeing of the structure that has the credential- the freeing of that structure has to be still hand auditted to make sure crfree is done. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 15: 7:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id BAF9737B422; Wed, 18 Apr 2001 15:07:26 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id PAA21754; Wed, 18 Apr 2001 15:00:12 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAA9WaqvQ; Wed Apr 18 15:00:01 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA11716; Wed, 18 Apr 2001 15:07:35 -0700 (MST) From: Terry Lambert Message-Id: <200104182207.PAA11716@usr08.primenet.com> Subject: Found BAD BUG: squashed To: arch@freebsd.org Date: Wed, 18 Apr 2001 22:07:25 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have identified the bug. It turns out that the bug causes memory corruption by freeing but continuing to use a credential, and it only occurs in big resource usage cases, and then seemingly at random. It is the fact that there are two credentials per socket, one for the socket, and one for the descriptor itself. The cr_ref is an unsigned short, and ... There is no test for overflow. Thus if I open 65537 files, and close 2, my cred structure is freed. If invariants are on, "0xdeadc0de" is spammed over top of the reference count, and then each time the cread is released, it is decremented: "0xdeadc0dd", "0xdeadc0dc", "0xdeadc0db", ... ...until another "0xc0de" (49374) closes, at which point it frees the already freed credential _again_. The way FreeBSD code is currently structured, this means that the quick-and-ugly fix is simply to change this from u_short to u_long. Further, I moved the cr_ref below the cr_groups declartion -- well out of stomping range of the INVARIANTS code. I have successfully opened 60,000 socket connections (240,000 credential references between the client and server processes combined, and 120,000 each) with this change. -- The real fix is to do as I suggested on -arch earlier today (and then some), and change: crhold(curproc->p_ucred); sigio->sio_ucred = curproc->p_ucred; style things into: sigio->sio_ucred = crhold(curproc->p_ucred); style things. But that is only part of it. Additionally, it needs to be further changed to something like: sigio->sio_ucred = crhold(&curproc->p_ucred); -- passing the address of the credential pointer -- and then (pseudocode), the credential code in crhold() needs to check for an imminent overflow, and when it sees it: struct ucred * crhold(struct ucred **cpp) { struct ucred *ret; if( about_to_overflow) { ret = *cpp; *cpp = crdup(save); } else { ret = *cpp; ret ->cr_ref++; } return ret; } The point of doing this would be to give the FD the overflowing cred, so that new files opened by the process can start counting at 1 again. NOTE: I also suggest chagning free() in kern/kern_malloc.c in free() in the INVARIANTS case, from: --- #ifdef INVARIANTS /* * Check for multiple frees. Use a quick check to see if * it looks free before laboriously searching the freelist. */ if (freep->spare0 == WEIRD_ADDR) { fp = (struct freelist *)kbp->kb_next; while (fp) { if (fp->spare0 != WEIRD_ADDR) panic("free: free item %p modified", fp); else if (addr == (caddr_t)fp) panic("free: multiple freed item %p", addr); fp = (struct freelist *)fp->next; } } --- #ifdef INVARIANTS /* * Check for multiple frees. We can't use a quick check, since * that will give us a false negative for something like a * stomped reference counter or mutex, if it is the first item. */ fp = (struct freelist *)kbp->kb_next; while (fp) { if (fp->spare0 != WEIRD_ADDR) panic("free: free item %p modified", fp); else if (addr == (caddr_t)fp) panic("free: multiple freed item %p", addr); fp = (struct freelist *)fp->next; } --- Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 15:12:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 86D0737B423 for ; Wed, 18 Apr 2001 15:12:26 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IMCPD45159; Wed, 18 Apr 2001 15:12:25 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 15:12:25 -0700 (PDT) From: Matt Dillon Message-Id: <200104182212.f3IMCPD45159@earth.backplane.com> To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed References: <200104182207.PAA11716@usr08.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have identified the bug. : :It turns out that the bug causes memory corruption by freeing :but continuing to use a credential, and it only occurs in big :resource usage cases, and then seemingly at random. : :It is the fact that there are two credentials per socket, one :for the socket, and one for the descriptor itself. : :The cr_ref is an unsigned short, and ... Ahhh.. Excellent find Terry! Why do you want to cycle a new credential when the unsigned short ref count reaches 65535 (what you call the right fix) verses simply changing the ref count to an unsigned long (what you call the quick and dirty fix)? That seems kinda reversed to me. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 16:23:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id CF9E337B423 for ; Wed, 18 Apr 2001 16:23:26 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA08396; Wed, 18 Apr 2001 16:23:22 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAvaaqxq; Wed Apr 18 16:23:19 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA22635; Wed, 18 Apr 2001 16:23:59 -0700 (MST) From: Terry Lambert Message-Id: <200104182323.QAA22635@usr07.primenet.com> Subject: Re: Found BAD BUG: squashed To: dillon@earth.backplane.com (Matt Dillon) Date: Wed, 18 Apr 2001 23:23:54 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <200104182212.f3IMCPD45159@earth.backplane.com> from "Matt Dillon" at Apr 18, 2001 03:12:25 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :I have identified the bug. > : > :It turns out that the bug causes memory corruption by freeing > :but continuing to use a credential, and it only occurs in big > :resource usage cases, and then seemingly at random. > : > :It is the fact that there are two credentials per socket, one > :for the socket, and one for the descriptor itself. > : > :The cr_ref is an unsigned short, and ... > > Ahhh.. Excellent find Terry! > > Why do you want to cycle a new credential when the unsigned short > ref count reaches 65535 (what you call the right fix) verses simply > changing the ref count to an unsigned long (what you call the quick > and dirty fix)? That seems kinda reversed to me. Because my use is not the common use, and it bloats the cred structure to a non-4-byte boundary, which I thought might end up being problematic for some people. If "the right fix" is implemented, it will end up giving out a duplicate cred every 32767 sockets (2 refs per socket: sock, fdp). The use of the & (address of) lets it replace the nearly exhausted cred where it's being cloned from; going the other direction would mean one duplicate cred per, on overflow. There would still be a new cred per dup() of an FD with an "exhausted" credential, but that's not really a problem. The stylistic change would allow this, but I admit it's not necessary, if everyone is willing to live with a bloated cred (I dent a "bloat the cred struct" patch to -current just now). The major thing the stylistic change would have done is allow me to change where crhold() got its credential. I could then #define it, and use __FILE__ and __LINE__, and store that away in the cred data as a "who allocated me?" cookie. Then when I did the duplicate free later, it would tell me the exact line of code where the allocation ("hold") came from. Really, this is a more general case of fixing up the way reference counts are done, to turn the new reference into an rvalue, so it can be replaced without telling the code about it (other than a recompile). In practice, you'd use the fast code, but you would always have the option of substituting the code (everywhere at once) to fix the problem, or, more importantly, future problems. Actually, this particular bug was a case of "When you hear hoof-beats DON'T look for horses, look for Emu!"... all the style change would have done is prove that it _wasn't_ a reference hold/release imbalance. That would have been a lot, but it would still have required me staring at the code (which it did). So the second part would be a generic reference count macro system that could be made to also do bounds checking on the count. The best way to do that is (again), a macro. Really, this wants: #define CRHOLD(x) GENERICHOLD(struct ucred,(x), poolname, MAX_USHORT) #define CRFREE(x) GENERICFREE(struct ucred,(x), poolanme) ...etc.. Then you vary the GENERIC macros based on debugging level. I'm tempted to suggest that the INVARIANTS code wants to seperately reference count objects, after allocating them larger than they are, and passing a pointer into itself that can be backed out (like the old malloc hack to do the same thing), to keep it from spamming reference counts. But that's a lot more work. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 18:20:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 32B0C37B42C for ; Wed, 18 Apr 2001 18:20:23 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA30760; Thu, 19 Apr 2001 11:20:12 +1000 Date: Thu, 19 Apr 2001 11:19:08 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Terry Lambert Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed In-Reply-To: <200104182323.QAA22635@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Terry Lambert wrote: > > :The cr_ref is an unsigned short, and ... This was fixed in -current in: RCS file: /home/ncvs/src/sys/sys/ucred.h,v Working file: ucred.h head: 1.22 ... ---------------------------- revision 1.18 date: 2000/11/27 00:09:16; author: alfred; state: Exp; lines: +11 -3 ucred system overhaul: ... 4) expand the size of the refcount from a u_short to an u_int, by using shorts we might have an overflow. Glanced at by: jake ---------------------------- > > > > Ahhh.. Excellent find Terry! > > > > Why do you want to cycle a new credential when the unsigned short > > ref count reaches 65535 (what you call the right fix) verses simply > > changing the ref count to an unsigned long (what you call the quick > > and dirty fix)? That seems kinda reversed to me. > Because my use is not the common use, and it bloats the cred > structure to a non-4-byte boundary, which I thought might end > up being problematic for some people. Bloatage of struct ucred occurred in 4.4BSD when uid_t's and gid_t's were changed from 16 bits to 32 bits. "u_short cr_ref" is followed by "uid_t cr_uid", so there are normally 2 bytes wasted after "cr_ref". These bytes can used for larger reference counts without changing the size of the struct, but not without breaking binary compatibility. Fortunately, "cr_ref" is invalid in userland. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 18:24:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A981837B42C for ; Wed, 18 Apr 2001 18:24:26 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3J1ONA14496; Wed, 18 Apr 2001 18:24:23 -0700 (PDT) Date: Wed, 18 Apr 2001 18:24:23 -0700 From: Alfred Perlstein To: Bruce Evans Cc: Terry Lambert , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed Message-ID: <20010418182423.A976@fw.wintelcom.net> References: <200104182323.QAA22635@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Thu, Apr 19, 2001 at 11:19:08AM +1000 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bruce Evans [010418 18:21] wrote: > On Wed, 18 Apr 2001, Terry Lambert wrote: > > > > :The cr_ref is an unsigned short, and ... > > This was fixed in -current in: > > RCS file: /home/ncvs/src/sys/sys/ucred.h,v > Working file: ucred.h > head: 1.22 > ... > ---------------------------- > revision 1.18 > date: 2000/11/27 00:09:16; author: alfred; state: Exp; lines: +11 -3 > ucred system overhaul: > ... > 4) expand the size of the refcount from a u_short to an u_int, by using > shorts we might have an overflow. > > Glanced at by: jake > ---------------------------- > > > > > > > Ahhh.. Excellent find Terry! > > > > > > Why do you want to cycle a new credential when the unsigned short > > > ref count reaches 65535 (what you call the right fix) verses simply > > > changing the ref count to an unsigned long (what you call the quick > > > and dirty fix)? That seems kinda reversed to me. > > > Because my use is not the common use, and it bloats the cred > > structure to a non-4-byte boundary, which I thought might end > > up being problematic for some people. > > Bloatage of struct ucred occurred in 4.4BSD when uid_t's and gid_t's > were changed from 16 bits to 32 bits. "u_short cr_ref" is followed > by "uid_t cr_uid", so there are normally 2 bytes wasted after "cr_ref". > These bytes can used for larger reference counts without changing the > size of the struct, but not without breaking binary compatibility. > Fortunately, "cr_ref" is invalid in userland. *slaps forhead* Bruce, you rule. Any chance you can fix this before release? You should be right about refcounts. I know binary compatbility is important, however since it's contained within the kernel I think that supporting > 32k sockets per application might be a nice thing for 4.3. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 18 20:53:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 14F2D37B423 for ; Wed, 18 Apr 2001 20:53:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 6524 invoked by uid 666); 19 Apr 2001 03:56:00 -0000 Received: from i182-041.nv.iinet.net.au (HELO elischer.org) (203.59.182.41) by mail.m.iinet.net.au with SMTP; 19 Apr 2001 03:56:00 -0000 Message-ID: <3ADE60FB.E7B4AD95@elischer.org> Date: Wed, 18 Apr 2001 20:52:27 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Terry Lambert Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed References: <200104182323.QAA22635@usr07.primenet.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > I'm tempted to suggest that the INVARIANTS code wants to seperately > reference count objects, after allocating them larger than they > are, and passing a pointer into itself that can be backed out > (like the old malloc hack to do the same thing), to keep it from > spamming reference counts. But that's a lot more work. I suggest that we define a generic refcount type and implement basic kernel support for incrementing and decrementing it. These can be hand optimised and also be atomic there are some suggestions for this already... allowing the type to be a non-simple type gives the posibility of such debugging support being included. > > Terry Lambert > terry@lambert.org > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 0:47:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6DDB537B43E for ; Thu, 19 Apr 2001 00:47:48 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3J7lG051820; Thu, 19 Apr 2001 00:47:16 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 00:47:16 -0700 (PDT) From: Matt Dillon Message-Id: <200104190747.f3J7lG051820@earth.backplane.com> To: Julian Elischer Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed References: <200104182323.QAA22635@usr07.primenet.com> <3ADE60FB.E7B4AD95@elischer.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I suggest that we define a generic refcount type and implement :basic kernel support for incrementing and decrementing it. : :These can be hand optimised and also be atomic :there are some suggestions for this already... :allowing the type to be a non-simple type :gives the posibility of such debugging support being included. :-- : __--_|\ Julian Elischer I don't think this is a good idea. The best way to get a reference on an object is to have an objet-specific referencing routine. e.g. vget(), vrele(), vm_object_reference(), and so forth. Some of these routines may well already have to obtain some sort of mutex to do their stuff, and doing unnecessary bus-locked instructions on top of that would be, well, unnecessary. I think it is best to leave the matter up to the individual referencing/dereferencing procedures. Nobody outside those specific routines should ever be manipulating a structure's ref count anyway. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 0:52:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0A08D37B424 for ; Thu, 19 Apr 2001 00:52:56 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3J7qoC51933; Thu, 19 Apr 2001 00:52:50 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 00:52:50 -0700 (PDT) From: Matt Dillon Message-Id: <200104190752.f3J7qoC51933@earth.backplane.com> To: Alfred Perlstein Cc: Bruce Evans , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed References: <200104182323.QAA22635@usr07.primenet.com> <20010418182423.A976@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> These bytes can used for larger reference counts without changing the :> size of the struct, but not without breaking binary compatibility. :> Fortunately, "cr_ref" is invalid in userland. : :*slaps forhead* : :Bruce, you rule. Any chance you can fix this before release? You :should be right about refcounts. I know binary compatbility is :important, however since it's contained within the kernel I think :that supporting > 32k sockets per application might be a nice thing :for 4.3. : :-- :-Alfred Perlstein - [alfred@freebsd.org] Oh, please don't. I'm sure Terry can wait until after 4.3 release to get this fix in! There is no sense chancing it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 0:54:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D117037B43C for ; Thu, 19 Apr 2001 00:54:36 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3J7sX424633; Thu, 19 Apr 2001 00:54:33 -0700 (PDT) Date: Thu, 19 Apr 2001 00:54:33 -0700 From: Alfred Perlstein To: Matt Dillon Cc: Bruce Evans , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed Message-ID: <20010419005432.D976@fw.wintelcom.net> References: <200104182323.QAA22635@usr07.primenet.com> <20010418182423.A976@fw.wintelcom.net> <200104190752.f3J7qoC51933@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104190752.f3J7qoC51933@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Apr 19, 2001 at 12:52:50AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [010419 00:52] wrote: > > :> These bytes can used for larger reference counts without changing the > :> size of the struct, but not without breaking binary compatibility. > :> Fortunately, "cr_ref" is invalid in userland. > : > :*slaps forhead* > : > :Bruce, you rule. Any chance you can fix this before release? You > :should be right about refcounts. I know binary compatbility is > :important, however since it's contained within the kernel I think > :that supporting > 32k sockets per application might be a nice thing > :for 4.3. > : > :-- > :-Alfred Perlstein - [alfred@freebsd.org] > > Oh, please don't. I'm sure Terry can wait until after 4.3 release to > get this fix in! There is no sense chancing it. I'm sorta in over-zealous bugfix mode lately, you're right though we ought to wait. -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 0:55:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0237B37B423 for ; Thu, 19 Apr 2001 00:55:38 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3J7taQ51976; Thu, 19 Apr 2001 00:55:36 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 00:55:36 -0700 (PDT) From: Matt Dillon Message-Id: <200104190755.f3J7taQ51976@earth.backplane.com> To: Bruce Evans Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok. Since -current went from u_short to u_int, we should simply MFC that change to stable after 4.3 is out the door. Now, I know you have your heart set on your fancy overflow check Terry but I really think going to a 32 bit counter is the best solution, especially as Bruce pointed out it will not bloat the structure. We've been moving all our other ref counts to 32 bits over the years... -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 1: 1: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 10C8737B423 for ; Thu, 19 Apr 2001 01:00:48 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 14581 invoked by uid 1000); 19 Apr 2001 07:59:02 -0000 Date: Thu, 19 Apr 2001 10:59:02 +0300 From: Peter Pentchev To: Matt Dillon Cc: Alfred Perlstein , Bruce Evans , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed Message-ID: <20010419105902.B3605@ringworld.oblivion.bg> Mail-Followup-To: Matt Dillon , Alfred Perlstein , Bruce Evans , Terry Lambert , arch@FreeBSD.ORG References: <200104182323.QAA22635@usr07.primenet.com> <20010418182423.A976@fw.wintelcom.net> <200104190752.f3J7qoC51933@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104190752.f3J7qoC51933@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Apr 19, 2001 at 12:52:50AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 12:52:50AM -0700, Matt Dillon wrote: > > :> These bytes can used for larger reference counts without changing the > :> size of the struct, but not without breaking binary compatibility. > :> Fortunately, "cr_ref" is invalid in userland. > : > :*slaps forhead* > : > :Bruce, you rule. Any chance you can fix this before release? You > :should be right about refcounts. I know binary compatbility is > :important, however since it's contained within the kernel I think > :that supporting > 32k sockets per application might be a nice thing > :for 4.3. > : > :-- > :-Alfred Perlstein - [alfred@freebsd.org] > > Oh, please don't. I'm sure Terry can wait until after 4.3 release to > get this fix in! There is no sense chancing it. Would there be any bad implications of upping cr_ref to 32-bit before 4.3? Besides binary compatibility? (I know, I know.. recompiling third-party kernel modules and all..) G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 5:40:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 188D937B424 for ; Thu, 19 Apr 2001 05:40:20 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA00891; Thu, 19 Apr 2001 22:40:07 +1000 Date: Thu, 19 Apr 2001 22:39:06 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alfred Perlstein Cc: Matt Dillon , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed In-Reply-To: <20010419005432.D976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Apr 2001, Alfred Perlstein wrote: > * Matt Dillon [010419 00:52] wrote: > > [Alfred wrote] > > :Bruce, you rule. Any chance you can fix this before release? You > > :should be right about refcounts. I know binary compatbility is > > :important, however since it's contained within the kernel I think > > :that supporting > 32k sockets per application might be a nice thing > > :for 4.3. > > : > > :-- > > :-Alfred Perlstein - [alfred@freebsd.org] > > > > Oh, please don't. I'm sure Terry can wait until after 4.3 release to > > get this fix in! There is no sense chancing it. > > I'm sorta in over-zealous bugfix mode lately, you're right though > we ought to wait. I agree. 1 day (+ slippage) is not enough time to test anything. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 5:46: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6D34437B42C for ; Thu, 19 Apr 2001 05:45:58 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA01233; Thu, 19 Apr 2001 22:45:13 +1000 Date: Thu, 19 Apr 2001 22:44:12 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Pentchev Cc: Matt Dillon , Alfred Perlstein , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed In-Reply-To: <20010419105902.B3605@ringworld.oblivion.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Apr 2001, Peter Pentchev wrote: > Would there be any bad implications of upping cr_ref to 32-bit before 4.3? > Besides binary compatibility? (I know, I know.. recompiling third-party > kernel modules and all..) It's hard to tell with only 1 day to test :-). Non-bloatage of the struct makes bugs less obvious. If not all the modules are compiled, then some modules may provide (nonzero) garbage in the padding after cr_ref. This will be interpreted as a large refcount by new kernels and ucreds will never be freed. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 5:48: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id AB74037B423 for ; Thu, 19 Apr 2001 05:47:55 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 1438 invoked by uid 1000); 19 Apr 2001 12:46:12 -0000 Date: Thu, 19 Apr 2001 15:46:11 +0300 From: Peter Pentchev To: Bruce Evans Cc: Matt Dillon , Alfred Perlstein , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed Message-ID: <20010419154611.D1067@ringworld.oblivion.bg> Mail-Followup-To: Bruce Evans , Matt Dillon , Alfred Perlstein , Terry Lambert , arch@FreeBSD.ORG References: <20010419105902.B3605@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Thu, Apr 19, 2001 at 10:44:12PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 10:44:12PM +1000, Bruce Evans wrote: > On Thu, 19 Apr 2001, Peter Pentchev wrote: > > > Would there be any bad implications of upping cr_ref to 32-bit before 4.3? > > Besides binary compatibility? (I know, I know.. recompiling third-party > > kernel modules and all..) > > It's hard to tell with only 1 day to test :-). Non-bloatage of the struct > makes bugs less obvious. If not all the modules are compiled, then some > modules may provide (nonzero) garbage in the padding after cr_ref. This > will be interpreted as a large refcount by new kernels and ucreds will > never be freed. Ack. I never thought of stale modules. Point taken - there might also be LOTS of other things I - or others - have not thought of :) G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 9:47:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 7B76E37B423 for ; Thu, 19 Apr 2001 09:47:38 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id JAA27197; Thu, 19 Apr 2001 09:40:22 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAQ5aye1; Thu Apr 19 09:40:17 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id JAA02940; Thu, 19 Apr 2001 09:47:52 -0700 (MST) From: Terry Lambert Message-Id: <200104191647.JAA02940@usr08.primenet.com> Subject: Re: Found BAD BUG: squashed To: dillon@earth.backplane.com (Matt Dillon) Date: Thu, 19 Apr 2001 16:47:52 +0000 (GMT) Cc: bde@zeta.org.au (Bruce Evans), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <200104190755.f3J7taQ51976@earth.backplane.com> from "Matt Dillon" at Apr 19, 2001 12:55:36 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok. Since -current went from u_short to u_int, we should simply MFC > that change to stable after 4.3 is out the door. Now, I know you have > your heart set on your fancy overflow check Terry but I really think > going to a 32 bit counter is the best solution, especially as Bruce > pointed out it will not bloat the structure. We've been moving all our > other ref counts to 32 bits over the years... Note that Bruce's fix doesn't addres the invariant stomping the reference count, which makes checking for multiple frees impossible. The only way to fix that is to move the cr_ref out of the first two bytes. I would still like a general reference counting mechanism, so I could turn on overflow checking at runtime. As I said before, this is independent of whether the cred is duplicated near overflow, or the count pushes the overflow off to 4 billion (without preventing it). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 10:10:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id E205E37B424 for ; Thu, 19 Apr 2001 10:10:49 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3JHAka55437; Thu, 19 Apr 2001 10:10:46 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 10:10:46 -0700 (PDT) From: Matt Dillon Message-Id: <200104191710.f3JHAka55437@earth.backplane.com> To: Terry Lambert Cc: bde@zeta.org.au (Bruce Evans), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed References: <200104191647.JAA02940@usr08.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Note that Bruce's fix doesn't addres the invariant stomping the :reference count, which makes checking for multiple frees :impossible. The only way to fix that is to move the cr_ref out :of the first two bytes. : : :I would still like a general reference counting mechanism, so :I could turn on overflow checking at runtime. : :As I said before, this is independent of whether the cred is :duplicated near overflow, or the count pushes the overflow off :to 4 billion (without preventing it). : : Terry Lambert I think we can safely move the ref counter to the end of the structure (and make it a u_int) after the 4.3 release, and if you want to have a KASSERT to test for 4-billion-overflow, that's fine with me too. I think being able to check for a double-free is a good idea. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 18:28:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 1598F37B43E for ; Thu, 19 Apr 2001 18:28:13 -0700 (PDT) (envelope-from bsddiy@163.net) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id JAA13151; Fri, 20 Apr 2001 09:25:27 +0800 Date: Fri, 20 Apr 2001 09:33:24 +0800 From: David Xu X-Mailer: The Bat! (v1.48f) Personal Reply-To: bsddiy@163.net Organization: Viasoft X-Priority: 3 (Normal) Message-ID: <1901302512.20010420093324@163.net> To: Matt Dillon Cc: Terry Lambert , bde@zeta.org.au ((Bruce Evans)), arch@FreeBSD.ORG Subject: Re[2]: Found BAD BUG: squashed In-reply-To: <200104191710.f3JHAka55437@earth.backplane.com> References: <200104191647.JAA02940@usr08.primenet.com> <200104191710.f3JHAka55437@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Matt, Friday, April 20, 2001, 1:10:46 AM, you wrote: MD> I think we can safely move the ref counter to the end of the MD> structure (and make it a u_int) after the 4.3 release, and if MD> you want to have a KASSERT to test for 4-billion-overflow, that's MD> fine with me too. I think being able to check for a double-free MD> is a good idea. MD> -Matt why cann't it go into 4.3-release? if you think this will break many third party utils, how do you think 4.4-release won't break them ? -- Best regards, David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 18:34: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C7AE837B423 for ; Thu, 19 Apr 2001 18:33:58 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3K1XtN65914; Thu, 19 Apr 2001 18:33:55 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 18:33:55 -0700 (PDT) From: Matt Dillon Message-Id: <200104200133.f3K1XtN65914@earth.backplane.com> To: David Xu Cc: Terry Lambert , bde@zeta.org.au ((Bruce Evans)), arch@FreeBSD.ORG Subject: Re: Re[2]: Found BAD BUG: squashed References: <200104191647.JAA02940@usr08.primenet.com> <200104191710.f3JHAka55437@earth.backplane.com> <1901302512.20010420093324@163.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :why cann't it go into 4.3-release? if you think this will break many third :party utils, how do you think 4.4-release won't break them ? : :-- :Best regards, :David Xu Too great a chance that it will mess something up and turn the CDs into so much shiny garbage. If we put it in just after the release we have several months to deal with any potential problems before the next set of CD's is cut. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 19: 7:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id E6D4E37B42C for ; Thu, 19 Apr 2001 19:07:25 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id TAA66037; Thu, 19 Apr 2001 19:05:35 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200104200205.TAA66037@gndrsh.dnsmgr.net> Subject: Re: Re[2]: Found BAD BUG: squashed In-Reply-To: <200104200133.f3K1XtN65914@earth.backplane.com> from Matt Dillon at "Apr 19, 2001 06:33:55 pm" To: dillon@earth.backplane.com (Matt Dillon) Date: Thu, 19 Apr 2001 19:05:35 -0700 (PDT) Cc: bsddiy@163.net (David Xu), tlambert@primenet.com (Terry Lambert), bde@zeta.org.au ((Bruce Evans)), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > :why cann't it go into 4.3-release? if you think this will break many third > :party utils, how do you think 4.4-release won't break them ? > : > :-- > :Best regards, > :David Xu > > Too great a chance that it will mess something up and turn the CDs into > so much shiny garbage. If we put it in just after the release we have > several months to deal with any potential problems before the > next set of CD's is cut. And instantly invalidate the viability of commercial software vendors 4.3-RELEASE versions of code running on systems tracking -stable to keep up with serious bug fixes. It's a double edge sword, this change should either go in now, or right before 4.4 goes to BETA. Any other time is going to have disruptive effects... The only real time that breaking binary capatibilty in the -stable tree makes since is right _BEFORE_ release, not right after! -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 19 20:19:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 05B5137B43C for ; Thu, 19 Apr 2001 20:19:20 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3K3JEp66472; Thu, 19 Apr 2001 20:19:14 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 20:19:14 -0700 (PDT) From: Matt Dillon Message-Id: <200104200319.f3K3JEp66472@earth.backplane.com> To: "Rodney W. Grimes" Cc: bsddiy@163.net (David Xu), tlambert@primenet.com (Terry Lambert), bde@zeta.org.au ((Bruce Evans)), arch@FreeBSD.ORG Subject: Re: Re[2]: Found BAD BUG: squashed References: <200104200205.TAA66037@gndrsh.dnsmgr.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :And instantly invalidate the viability of commercial software vendors :4.3-RELEASE versions of code running on systems tracking -stable to :keep up with serious bug fixes. : :It's a double edge sword, this change should either go in now, or :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net I think this is an overreaction. ucred is almost universally used as an opaque structure. It seems highly unlikely to me that it will break anything outside the cvs tree. In fact, not a single program in /usr/src/sys/dev references elements inside a ucred (and barely reference the ucred itself). But, even though we don't think it will break anything is no excuse to risk the 4.3-release on the change. If something bad breaks after the 4.3 release we can always back it out. If we break 4.3 itself we're stuck. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 20 16: 8:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9BE8537B424; Fri, 20 Apr 2001 16:08:38 -0700 (PDT) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.2/8.11.1) with ESMTP id f3KN8WC63486; Fri, 20 Apr 2001 19:08:32 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200104202308.f3KN8WC63486@green.bikeshed.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Matt Dillon Cc: "Rodney W. Grimes" , bsddiy@163.net (David Xu), tlambert@primenet.com (Terry Lambert), bde@zeta.org.au ((Bruce Evans)), arch@FreeBSD.ORG Subject: Re: Re[2]: Found BAD BUG: squashed In-Reply-To: Message from Matt Dillon of "Thu, 19 Apr 2001 20:19:14 PDT." <200104200319.f3K3JEp66472@earth.backplane.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 19:08:32 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > : > :And instantly invalidate the viability of commercial software vendors > :4.3-RELEASE versions of code running on systems tracking -stable to > :keep up with serious bug fixes. > : > :It's a double edge sword, this change should either go in now, or > :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net > > I think this is an overreaction. ucred is almost universally used > as an opaque structure. It seems highly unlikely to me that it > will break anything outside the cvs tree. In fact, not a single > program in /usr/src/sys/dev references elements inside a ucred (and > barely reference the ucred itself). > > But, even though we don't think it will break anything is no excuse to > risk the 4.3-release on the change. If something bad breaks after the > 4.3 release we can always back it out. If we break 4.3 itself we're > stuck. I plan on MFCing the less-evil struct xucred along with the various updates to struct ucred after 4.3-RELEASE. Things outside the kernel really shouldn't be using ucred after all. I feel bad for having introduced net.*.getcred without specifying a new structure for it to use when I did; that means that some applications may return improper results (notably, identd servers), but none should actually have unpredictable results because of the sysctl interface being used. At this point, I'll also MFC the change to struct export_args, but that won't fix old kernels that improperly will try to allocate whatever junk size may be in that struct passed in and crash instead of failing the allocation.... -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 21 9:43:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 9613D37B422 for ; Sat, 21 Apr 2001 09:43:23 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3LGhFf62187; Sat, 21 Apr 2001 12:43:15 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 21 Apr 2001 12:43:15 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Peter Pentchev Cc: Bruce Evans , Matt Dillon , Alfred Perlstein , Terry Lambert , arch@FreeBSD.ORG Subject: Re: Found BAD BUG: squashed In-Reply-To: <20010419154611.D1067@ringworld.oblivion.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Apr 2001, Peter Pentchev wrote: > On Thu, Apr 19, 2001 at 10:44:12PM +1000, Bruce Evans wrote: > > On Thu, 19 Apr 2001, Peter Pentchev wrote: > > > > > Would there be any bad implications of upping cr_ref to 32-bit before 4.3? > > > Besides binary compatibility? (I know, I know.. recompiling third-party > > > kernel modules and all..) > > > > It's hard to tell with only 1 day to test :-). Non-bloatage of the struct > > makes bugs less obvious. If not all the modules are compiled, then some > > modules may provide (nonzero) garbage in the padding after cr_ref. This > > will be interpreted as a large refcount by new kernels and ucreds will > > never be freed. > > Ack. I never thought of stale modules. Point taken - there might also > be LOTS of other things I - or others - have not thought of :) > > G'luck, > Peter Note: stale modules may be OK as long as (a) the structure isn't rearranged and (b) they are using the base kernel's cr*() calls to manipulate credentials. However, this is something that would have to be extensively tested. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 21 16:58:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 425D337B424 for ; Sat, 21 Apr 2001 16:58:09 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3LNwef67256 for ; Sat, 21 Apr 2001 19:58:40 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 21 Apr 2001 19:58:40 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: SA/LWP on NetBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Was perusing NetBSD source from a bit ago and was interested when I found this: http://mail-index.netbsd.org/source-changes/2001/03/06/0002.html Was wondering if anyone had had a chance to look at this work and potential applicability to FreeBSD, as well as how this compares with the KSE architecture we've been considering. For some reason, I'm having trouble browsing the files added under that commit in our copy of the NetBSD cvs repository using cvsweb. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 21 19:36: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5E9DD37B424; Sat, 21 Apr 2001 19:35:55 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA15352; Sat, 21 Apr 2001 22:35:19 -0400 (EDT) Date: Sat, 21 Apr 2001 22:35:18 -0400 (EDT) From: Daniel Eischen To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: SA/LWP on NetBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 Apr 2001, Robert Watson wrote: > Was perusing NetBSD source from a bit ago and was interested when I found > this: > > http://mail-index.netbsd.org/source-changes/2001/03/06/0002.html > > Was wondering if anyone had had a chance to look at this work and > potential applicability to FreeBSD, as well as how this compares with the > KSE architecture we've been considering. For some reason, I'm having > trouble browsing the files added under that commit in our copy of the > NetBSD cvs repository using cvsweb. I'd be interested in adding support for KSEs/SAs in our threads library. I'm already working on a new libpthread to give us NxN threading (much like linuxthreads), with the goal of having something ready for 5.0-release. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 21 22: 6:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id F14D537B423 for ; Sat, 21 Apr 2001 22:06:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 21176 invoked by uid 666); 22 Apr 2001 05:09:06 -0000 Received: from i192-228.nv.iinet.net.au (HELO elischer.org) (203.59.192.228) by mail.m.iinet.net.au with SMTP; 22 Apr 2001 05:09:06 -0000 Message-ID: <3AE26691.B10EF982@elischer.org> Date: Sat, 21 Apr 2001 22:05:21 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: SA/LWP on NetBSD? References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > Was perusing NetBSD source from a bit ago and was interested when I found > this: > > http://mail-index.netbsd.org/source-changes/2001/03/06/0002.html holy sh*t! I haven't been able to see the diffs yet It'll be interesting to see ho closely they stuck to the original Schedular activations paper..! > > Was wondering if anyone had had a chance to look at this work and > potential applicability to FreeBSD, as well as how this compares with the > KSE architecture we've been considering. For some reason, I'm having > trouble browsing the files added under that commit in our copy of the > NetBSD cvs repository using cvsweb. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message