Subject: Re: [saag] Linux flaw from RFC5961 implementation

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Sep 2016 09:42:36 -0400

On 08/13/2016 11:35 AM, Joe Touch wrote:

> b) IMO, the Linux code is just (and yet another) bug based on an
> incorrect read of RFC 5961, not worthy of even an errata

There is a fine line between incorrect reading and confusing specification.

I would assume the Linux code went through several reviews at least, as this
is not some basement developed OS.

Therefore, I would disagree with "not worthy of even an errata".

Paul

---

From: Joe Touch <[email-masked]>
Date: Fri, 2 Sep 2016 08:48:10 -0700

I agree and I think Mirja's solution seems reasonable:

>> To me this does not seem to be a case for an errata. For sure some
>> clarification seems to be helpful here but that's not what erratas
>> are for.
>>
>> Therefore, I would suggest to simply set this into "Held for Document
>> Update" state such that it is noticed in case we decide to update the
>> document at some point. Does that make sense? 

> is not some basement developed OS.

Linux is an "accept first, have many eyes check later" system - that's
why it supports so many peripherals, but also why it was once released
with code that failed to atomically update the file system tree (i.e.,
if the system went down while an update was in process, the file system
was destroyed). IMO, your statement is reasonably true for FreeBSD, but
Linux *is* the counterexample. I don't know where Linus whether he his
code in a literal basement, but it was "after a period of self-imposed
isolation and intense concentration" (http://www.linfo.org/linus.html).

A good example - I have two students currently adding options (TCP EDO
and UDP option space). These students - first-timers to kernel editing -
BOTH found legitimate bugs in the Linux code for their transport protocols.

The IETF doesn't have the time or resources to clutter the RFC series
with errata to address the variety and number of ways in which Linux
over-eagerly accepts community code without appropriate review. We need
to decide whether these sorts of errors are driven by real errors in the
doc or whether we're just over-specifying the infinite ways to go
outside the documented spec.

Joe

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 3 Sep 2016 16:54:39 -0400

On Fri, Sep 02, 2016 at 08:48:10AM -0700, Joe Touch wrote:
> Linux *is* the counterexample.

That's quite a hyperbolic description of Linux's development
procedures.  In general patches do get multiple reviews on various
mailing lists before they go in, and there is a very much a strong
test-driven culture.  For example:

	    http://thunk.org/gce-xfstests

The example you gave is one that BSD partisans loved to talk about two
decades ago, but it wasn't true even then.  I'm not aware of *any*
example of where the file system was destroyed if the system crashed
while writes were happening to ext2.  (The assertion was made because
ext2 didn't carefully stage writes in a specific order, but given that
hard drives post the BSD 4.3 era do writeback caching, trying to stage
writes in a specific order is pointless; instead ext2 added a lot more
sophistication to its file system consistency checker to recover from
crashes.  This was good enough that Google for a long time was using
ext2 instead of ext3 because journalling gave back performance they
didn't want, and the file system consistency checker was quite capable
of fixing file systems after crashes.)  Indeed, if we're going to play
the OS trash talking game, I could point out that ext2/ext3/ext4 is
the only file system consistency checker I know of that has a
comprehensive regression test suite.  Certainly BSD FFS's fsck.ufs
does not.  Does that mean that all of BSD is crap?  Of course not!!

In any case, instead of using "ad hominem" attacks, I'd suggest
looking at whether it's reasonable that someone other imeplemtnor
reading the RFC could make the same mistake.

					- Ted

---

From: Joe Touch <[email-masked]>
Date: Sat, 3 Sep 2016 14:23:09 -0700

On 9/3/2016 1:54 PM, Theodore Ts'o wrote:
> while writes were happening to ext2. 
We had multiple machines in our lab experience this failure mode.

> ...
> In any case, instead of using "ad hominem" attacks, 

It's difficult to perform such an attack on an inanimate object, but I
described a specific flaw - one of many that have eluded the Linux
review process.

It's a simple tradeoff - by accepting more code, Linux supports more
devices and becomes more widely accepted.

That same priority also makes it more likely to accept incorrect code -
whether written incorrectly or deployed prematurely.

> I'd suggest

I have repeatedly done so, but the contrary claim is (IMO) "well, if
Linux messed up, *anyone* could". I disagree that logic.

Joe

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 4 Sep 2016 12:41:44 +0000

So let me understand. The linux community got something wrong and Joe has implemented it multiple times and not gotten it wrong, is that right?

If a major implementation got something wrong, why the heck would we *not* put out a clarification?  
--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: [email-masked]
Date: Sun, 4 Sep 2016 11:06:36 -0400

Sent from my iPhone

> On Sep 4, 2016, at 8:41 AM, Salz, Rich <[email-masked]> wrote:
> 

Agreed.  I don't agree with the argument given to not file an errata.

Kathleen 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag