Date: Mon, 22 May 2000 02:26:50 +1000 (EST) From: Darren Reed <darrenr@reed.wattle.id.au> To: jlemon@flugsvamp.com (Jonathan Lemon) Cc: darrenr@reed.wattle.id.au, freebsd-stable@freebsd.org, ps@freebsd.org, Cy.Schubert@uumail.gov.bc.ca Subject: 4.0_STABLE Broken (was Re: FTP proxy without translation no longer working? (fwd)) Message-ID: <200005211626.CAA12901@avalon.reed.wattle.id.au> In-Reply-To: <20000521102808.C5468@prism.flugsvamp.com> from Jonathan Lemon at "May 21, 0 10:28:08 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In some email I received from Jonathan Lemon, sie wrote:
> On Sun, May 21, 2000 at 02:28:30PM +1000, Darren Reed wrote:
> > Jonathan,
> > Can you please back these changes out for 4.0_STABLE ?
> > They appear to interfere with the operation IP Filter. I'm happy
> > for these to on the head and for there to be work required to get
> > things working again. If I don't hear/see from you within the
> > next week, I'll assume that you otherwise are not that concerned
> > and offer to backout the changes myself.
>
> Well, instead of backing the changes out, how about we fix the problem
> instead? I'm not familiar with IPFilter, but I know that there were
> some initial problems with ipfw, perhaps the problems here are similar.
Okay. So you want to play "pass the buck". Backing out that change
(which does not fix *any* bugs!) will "fix the problem". As it is,
you've introduced a _new feature_ to the _STABLE branch and broken
something. In my book, that's two crosses you've marked up: changes
to _STABLE must not break it and new features must be extensively
tested in -current before committing to a release branch.
To summarise, some very good reasons why that change should be backed
out of 4.0_STABLE:
1. It breaks 4.0_STABLE
2. It breaks 4.0_STABLE
3. It breaks 4.0_STABLE
Do you need any more ? I am given to understand that FreeBSD
doesn't have a very strict (read absent) release engineering
policy which allows for this sort of thing to happen. The change
(as I understand it) is not necessary for stability. It would
appear that it needs some testing under -current and until it
works flawlessly there should not be brought into the -stable
branch. At least that is how the current "release engineering"
process works, right ? Put it in -current and if there are no
problems, put it on -stable and if there are problems there,
remove from -stable until things are fixed in -current ? Or is
that a failure on my part to believe that things should be fixed
in -current before they are patched up in -stable ?
It *SHOULD NOT* matter that there "may be" a problem with how
IP Filter is handling the checksums (and given the comments from
your changes for things like IP divert I'm sure there are).
Commits to -stable should *NOT* break -stable in any way. Or am
I wrong in making that statement and that commits to -stable are
(now) allowed to break it ? Jordan ?
> What happens now is that the TCP/UDP layer will place the pseudo
> checksum in the TCP/UDP header, and set a flag in the mbuf. After
> the IP layer determines which interface the packet is going out on,
> it will compute the checksum if: 1. the interface indicates it does
> not support delayed checksums, and 2. the delayed csum flag is set
> in the mbuf.
Sounds like a similar sort of `hack' used in Solaris for devices which
do the TCP checksum in hardware (at present limited to Gigabit and ATM
cards, AFAIK).
> If the packet is intercepted/redirected at some point between the
> upper (TCP) and lower (IP) layers, then it will not have a valid
> checksum. In this case, there needs to be a small bit of code to
> force the checksum to be computed if necessary. E.g.:
>
> if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
> in_delayed_cksum(m);
> m->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
> }
>
> I don't know where IPFilter hooks into the stack, so I don't know
> where the appropriate point to put this would be.
Well, maybe you should have thought of that *before* you merged the
change from -current into 4.0_STABLE ?
Jordan, if you're reading this, you should give some *serious*
thought to setting up a proper release engineering team - they
should be dealing with this, not me and Jonathan directly pissing
on each other. Allowing the "unwashed" (i.e. committers) to commit
to released and stable branches is an invitation for disaster, IMHO.
Darren
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005211626.CAA12901>