Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Apr 2001 19:08:32 -0400
From:      "Brian F. Feldman" <green@FreeBSD.ORG>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, 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 
Message-ID:  <200104202308.f3KN8WC63486@green.bikeshed.org>
In-Reply-To: Message from Matt Dillon <dillon@earth.backplane.com>  of "Thu, 19 Apr 2001 20:19:14 PDT." <200104200319.f3K3JEp66472@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon <dillon@earth.backplane.com> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104202308.f3KN8WC63486>