Re: silent semantic changes with reiser4

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 08/31/04

  • Next message: Adrian Bunk: "2.6.9-rc1: missing netfilter help texts" 
    Date:	Tue, 31 Aug 2004 10:15:25 -0700 (PDT)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>

    On Tue, 31 Aug 2004, Alan Cox wrote:
    >
    > Several do TCP in user space. The only thing you need in kernel for
    > TCP/IP is enough decode to decide who gets the packet.

    Only thing? I don't think so.

    You also want to make sure that regular users cannot send "impossible"
    packets. Think about the old "ping of death" kind of thing, where a normal
    mis-behaving (and I'm not saying intentionally so: it might be a small bug
    that just overwrites some data) program should _not_ be able to cause
    problems on the network.

    Admins absolutely _hate_ that. They will ban an OS if it sends out packets
    that cause troublem. You should remember that - we used to do strange
    things on the net (long long time ago), and we brought down servers by
    mistake, and nobody ever considered it a server bug: it was a Linux bug
    that it wouldn't do the right thing.

    Things like not sending FIN-packets when a program suddenly goes away is
    NOT acceptable behaviour! Neither is it acceptable behaviour to allow user
    programs to make up their own packets.

    > Even some non microkernel embedded OS's do this in order to keep kernel
    > size down.

    ..and I'm not disagreeing that it doesn't happen. I explicitly mentioned
    PalmOS, I bet it happens in other cases too. But I'd strongly argue that
    it's a bug, not a feature.

    It's a bug that people tend to accept in a "single-client" environment.

    NOTE! This is totally ignoring the fact that you can't be called "UNIX"
    any more. You _need_ to have sequence numbers etc be shared between
    multiple programs that all write to the stream. Again, that _does_ mean
    that you have another protection domain (aka "kernel" or "TCP deamon")
    that keeps track of the sequence number.

                    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Adrian Bunk: "2.6.9-rc1: missing netfilter help texts"

    Relevant Pages

    • RE: Linux 2.4.27 SECURITY BUG - TCP Local (probable Remote) Denial of Service
      ... > is absolutely nothing the kernel can do about it. ... > It's a resource leak, ... This is how TCP works. ... and read the bug before you comment. ...
      (Linux-Kernel)
    • Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
      ... I've been tracking down this bug for some time, ... the TCP stack starts shrinking the TCP window ... receiving real-time data (many small packets, ... The connection is established and the receiver's TCP window quickly ramps ...
      (Linux-Kernel)
    • Re: cwnd and sstresh monitor
      ... (kernel patch, kernel module, etc?), and how would this be done best? ... but there is a TCPDEBUG kernel option that gathers TCP state information for debugging and tracing purposes. ... I also modified the iptimefunction to provide microsecond resolution instead of miliseconds, because most of the packets have the same timestamp attached. ...
      (freebsd-hackers)
    • Re: [PATCH] net_device refcnt bug when NFQUEUEing bridged packets
      ... I came across the following bug a few weeks ago (which still applies to ... If however one or more packets of a br_looprun end up in a NFQUEUE, ... refused to shutdown a virtual device with non-zero refcount... ... running a kernel with this patch since weeks and has not had any ...
      (Linux-Kernel)
    • Re: TCP library
      ... |> my program instead of the normal TCP code? ... |> belong to the kernel as far as I know. ... | can also get the reply packets from the interface. ...
      (comp.os.linux.development.system)