netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Allen Simpson <william.allen.simpson@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Developers <linux-kernel@vger.kernel.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Michael Chan <mchan@broadcom.com>,
	Simon Horman <horms@verge.net.au>
Subject: Re: [PATCH v4 2/7] net: remove old tcp_optlen function
Date: Sat, 13 Mar 2010 06:12:18 -0500	[thread overview]
Message-ID: <4B9B7312.80301@gmail.com> (raw)
In-Reply-To: <1268471488.2947.26.camel@edumazet-laptop>

On 3/13/10 4:11 AM, Eric Dumazet wrote:
> David already pointed out fact that this code path is not used in
> forwardind / routing path. Your assumptions are clearly wrong.
>
> Can you sit down and understand this difference ?
>
> Only *locally* generated trafic by linux kernel can enter this path.
>
Since you agree with David, perhaps you could kindly point out exactly
how your statement is true?  Proof by assertion is generally not good
argumentation.  I'll start a new thread for you to discuss.

More importantly, how is this relevant to this patch?

This patch removes a seldom used function that generates bad code, and
MUST NOT be used elsewhere in the code base -- an attractive nuisance,
speaking in legal terms.

This patch is also more elegant, and generates faster code.

Are you saying this patch is incorrect in any way?

Please point to the bad line of code (not David's comments or diatribe).
Certainly, I'll be happy to correct it!


> And if a bug in linux core network stack can feed any driver a buggy
> skb, bad things can happen, even if a driver is perfect.
>
Certainly.  But a driver cannot depend on the entirety of a large
project being perfect.  It *should* be perfect in and of itself!


> Please point out _this_ bug _if_ it really exists, so that we can
> correct this bug instead of hiding it in one thousand of drivers.
>
Again, I'll start a new thread for your edification.


> Your attacks make no sense, you know nothing about linux kernel
> internals and assume it was written like other projects you were
> involved to.
>
I've made no "attacks".  The above is a personal /ad hominem/ attack,
evidently the raison d'etre for Linux email lists.  :-(

Yes, I've been involved in many other projects, and am arguably the
most widely experienced TCP/IP implementer in the world.  I've been
programming in C since 1977, and my first TCP/IP implementation was
started in 1979 (in assembly).  Probably before you were born.

Why are you so threatened by that?

Why are you insulting and trying to drive me away?

Why, oh why, is there such a lack of community spirit here?!?!

  reply	other threads:[~2010-03-13 11:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11 11:35 [PATCH 0/7] tcp: bugs and cleanup for 2.6.34-rc1 William Allen Simpson
2010-03-11 11:41 ` [PATCH v3 1/7] net: tcp_header_len_th and tcp_option_len_th William Allen Simpson
2010-03-11 11:53 ` [PATCH v4 2/7] net: remove old tcp_optlen function William Allen Simpson
2010-03-11 11:54   ` William Allen Simpson
2010-03-12  0:26   ` Simon Horman
2010-03-12 13:21     ` William Allen Simpson
2010-03-12 13:25   ` William Allen Simpson
2010-03-12 17:46     ` Dan Carpenter
2010-03-12 23:05       ` William Allen Simpson
2010-03-13  9:11         ` Eric Dumazet
2010-03-13 11:12           ` William Allen Simpson [this message]
2010-03-13 11:24             ` Eric Dumazet
2010-03-11 12:08 ` [PATCH v6 3/7] tcp: harmonize tcp_vx_rcv header length assumptions William Allen Simpson
2010-03-11 12:24 ` [PATCH v6 4/7] tcp: input header length, prediction, and timestamp bugs William Allen Simpson
2010-03-11 12:31 ` [PATCH v3 5/7] TCPCT part 2e: accept SYNACK data William Allen Simpson
2010-03-11 12:48 ` [PATCH v6 6/7] TCPCT part 2f: cleanup tcp_parse_options William Allen Simpson
2010-03-11 13:06 ` [PATCH v8 7/7] TCPCT part 2g: parse cookie pair and 64-bit timestamp William Allen Simpson
2010-03-11 15:01 ` [PATCH 0/7] tcp: bugs and cleanup for 2.6.34-rc1 Eric Dumazet
2010-03-11 17:38   ` William Allen Simpson
2010-03-11 18:14     ` Joe Perches
2010-03-12 13:27       ` William Allen Simpson
2010-03-13  5:29     ` Américo Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B9B7312.80301@gmail.com \
    --to=william.allen.simpson@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=error27@gmail.com \
    --cc=horms@verge.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).