1. 08 5月, 2008 2 次提交
    • J
      net/ipv4: correct RFC 1122 section reference in comment · c67fa027
      J.H.M. Dassen (Ray) 提交于
      RFC 1122 does not have a section 3.1.2.2. The requirement to silently
      discard datagrams with a bad checksum is in section 3.2.1.2 instead.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=10611Signed-off-by: NJ.H.M. Dassen (Ray) <jdassen@debian.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c67fa027
    • I
      tcp FRTO: SACK variant is errorneously used with NewReno · 62ab2227
      Ilpo Järvinen 提交于
      Note: there's actually another bug in FRTO's SACK variant, which
      is the causing failure in NewReno case because of the error
      that's fixed here. I'll fix the SACK case separately (it's
      a separate bug really, though related, but in order to fix that
      I need to audit tp->snd_nxt usage a bit).
      
      There were two places where SACK variant of FRTO is getting
      incorrectly used even if SACK wasn't negotiated by the TCP flow.
      This leads to incorrect setting of frto_highmark with NewReno
      if a previous recovery was interrupted by another RTO.
      
      An eventual fallback to conventional recovery then incorrectly
      considers one or couple of segments as forward transmissions
      though they weren't, which then are not LOST marked during
      fallback making them "non-retransmittable" until the next RTO.
      In a bad case, those segments are really lost and are the only
      one left in the window. Thus TCP needs another RTO to continue.
      The next FRTO, however, could again repeat the same events
      making the progress of the TCP flow extremely slow.
      
      In order for these events to occur at all, FRTO must occur
      again in FRTOs step 3 while the key segments must be lost as
      well, which is not too likely in practice. It seems to most
      frequently with some small devices such as network printers
      that *seem* to accept TCP segments only in-order. In cases
      were key segments weren't lost, things get automatically
      resolved because those wrongly marked segments don't need to be
      retransmitted in order to continue.
      
      I found a reproducer after digging up relevant reports (few
      reports in total, none at netdev or lkml I know of), some
      cases seemed to indicate middlebox issues which seems now
      to be a false assumption some people had made. Bugzilla
      #10063 _might_ be related. Damon L. Chesser <damon@damtek.com>
      had a reproducable case and was kind enough to tcpdump it
      for me. With the tcpdump log it was quite trivial to figure
      out.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62ab2227
  2. 05 5月, 2008 2 次提交
  3. 03 5月, 2008 1 次提交
  4. 02 5月, 2008 2 次提交
  5. 01 5月, 2008 1 次提交
  6. 30 4月, 2008 3 次提交
    • L
      tcp: Overflow bug in Vegas · 15913114
      Lachlan Andrew 提交于
      From: Lachlan Andrew <lachlan.andrew@gmail.com>
      
      There is an overflow bug in net/ipv4/tcp_vegas.c for large BDPs
      (e.g. 400Mbit/s, 400ms).  The multiplication (old_wnd *
      vegas->baseRTT) << V_PARAM_SHIFT overflows a u32.
      
      [ Fix tcp_veno.c too, it has similar calculations. -DaveM ]
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15913114
    • K
      [IPv4] UFO: prevent generation of chained skb destined to UFO device · be9164e7
      Kostya B 提交于
      Problem: ip_append_data() could wrongly generate a chained skb for
      devices which support UFO.  When sk_write_queue is not empty
      (e.g. MSG_MORE), __instead__ of appending data into the next nr_frag
      of the queued skb, a new chained skb is created.
      
      I would normally assume UFO device should get data in nr_frags and not
      in frag_list.  Later the udp4_hwcsum_outgoing() resets csum to NONE
      and skb_gso_segment() has oops.
      
      Proposal:
      1. Even length is less than mtu, employ ip_ufo_append_data()
      and append data to the __existed__ skb in the sk_write_queue.
      
      2. ip_ufo_append_data() is fixed due to a wrong manipulation of
      peek-ing and later enqueue-ing of the same skb.  Now, enqueuing is
      always performed, because on error the further
      ip_flush_pending_frames() would release the queued skb.
      Signed-off-by: NKostya B <bkostya@hotmail.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be9164e7
    • S
      ipv4: annotate a few functions __init in ipconfig.c · 45e741b8
      Sam Ravnborg 提交于
      A few functions are only used from __init context.
      So annotate these with __init for consistency and silence
      the following warnings:
      
      WARNING: net/ipv4/built-in.o(.text+0x2a876): Section mismatch
               in reference from the function ic_bootp_init() to
               the variable .init.data:bootp_packet_type
      WARNING: net/ipv4/built-in.o(.text+0x2a907): Section mismatch
               in reference from the function ic_bootp_cleanup() to
               the variable .init.data:bootp_packet_type
      
      Note: The warnings only appear with CONFIG_DEBUG_SECTION_MISMATCH=y
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45e741b8
  7. 29 4月, 2008 8 次提交
    • H
      Remove duplicated unlikely() in IS_ERR() · 801678c5
      Hirofumi Nakagawa 提交于
      Some drivers have duplicated unlikely() macros.  IS_ERR() already has
      unlikely() in itself.
      
      This patch cleans up such pointless code.
      Signed-off-by: NHirofumi Nakagawa <hnakagawa@miraclelinux.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NJeff Garzik <jeff@garzik.org>
      Cc: Paul Clements <paul.clements@steeleye.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      801678c5
    • P
      netfilter: nf_conntrack: padding breaks conntrack hash on ARM · 443a70d5
      Philip Craig 提交于
      commit 0794935e "[NETFILTER]: nf_conntrack: optimize hash_conntrack()"
      results in ARM platforms hashing uninitialised padding.  This padding
      doesn't exist on other architectures.
      
      Fix this by replacing NF_CT_TUPLE_U_BLANK() with memset() to ensure
      everything is initialised.  There were only 4 bytes that
      NF_CT_TUPLE_U_BLANK() wasn't clearing anyway (or 12 bytes on ARM).
      Signed-off-by: NPhilip Craig <philipc@snapgear.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      443a70d5
    • T
      ipv4: Update MTU to all related cache entries in ip_rt_frag_needed() · 0010e465
      Timo Teras 提交于
      Add struct net_device parameter to ip_rt_frag_needed() and update MTU to
      cache entries where ifindex is specified. This is similar to what is
      already done in ip_rt_redirect().
      Signed-off-by: NTimo Teras <timo.teras@iki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0010e465
    • D
      net: Add compat support for getsockopt (MCAST_MSFILTER) · 42908c69
      David L Stevens 提交于
      This patch adds support for getsockopt for MCAST_MSFILTER for
      both IPv4 and IPv6. It depends on the previous setsockopt patch,
      and uses the same method.
      Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42908c69
    • J
      ipvs: fix oops in backup for fwmark conn templates · 2ad17def
      Julian Anastasov 提交于
      	Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=10556
      where conn templates with protocol=IPPROTO_IP can oops backup box.
      
              Result from ip_vs_proto_get() should be checked because
      protocol value can be invalid or unsupported in backup. But
      for valid message we should not fail for templates which use
      IPPROTO_IP. Also, add checks to validate message limits and
      connection state. Show state NONE for templates using IPPROTO_IP.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ad17def
    • A
      netfilter: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets · 9a732ed6
      Arnaud Ebalard 提交于
      While reinjecting *bigger* modified versions of IPv6 packets using
      libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too)
      but I get the following on recents kernels (2.6.25, trace below is
      against today's net-2.6 git tree):
      
      skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0
      ------------[ cut here ]------------
      invalid opcode: 0000 [#1] PREEMPT 
      Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000)
      Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80 
             f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60 
             c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c 
      Call Trace:
       [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
       [<c04cdbfc>] ? skb_put+0x3c/0x40
       [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
       [<c04fd115>] ? nfnetlink_rcv_msg+0xf5/0x160
       [<c04fd03e>] ? nfnetlink_rcv_msg+0x1e/0x160
       [<c04fd020>] ? nfnetlink_rcv_msg+0x0/0x160
       [<c04f8ed7>] ? netlink_rcv_skb+0x77/0xa0
       [<c04fcefc>] ? nfnetlink_rcv+0x1c/0x30
       [<c04f8c73>] ? netlink_unicast+0x243/0x2b0
       [<c04cfaba>] ? memcpy_fromiovec+0x4a/0x70
       [<c04f9406>] ? netlink_sendmsg+0x1c6/0x270
       [<c04c8244>] ? sock_sendmsg+0xc4/0xf0
       [<c011970d>] ? set_next_entity+0x1d/0x50
       [<c0133a80>] ? autoremove_wake_function+0x0/0x40
       [<c0118f9e>] ? __wake_up_common+0x3e/0x70
       [<c0342fbf>] ? n_tty_receive_buf+0x34f/0x1280
       [<c011d308>] ? __wake_up+0x68/0x70
       [<c02cea47>] ? copy_from_user+0x37/0x70
       [<c04cfd7c>] ? verify_iovec+0x2c/0x90
       [<c04c837a>] ? sys_sendmsg+0x10a/0x230
       [<c011967a>] ? __dequeue_entity+0x2a/0xa0
       [<c011970d>] ? set_next_entity+0x1d/0x50
       [<c0345397>] ? pty_write+0x47/0x60
       [<c033d59b>] ? tty_default_put_char+0x1b/0x20
       [<c011d2e9>] ? __wake_up+0x49/0x70
       [<c033df99>] ? tty_ldisc_deref+0x39/0x90
       [<c033ff20>] ? tty_write+0x1a0/0x1b0
       [<c04c93af>] ? sys_socketcall+0x7f/0x260
       [<c0102ff9>] ? sysenter_past_esp+0x6a/0x91
       [<c05f0000>] ? snd_intel8x0m_probe+0x270/0x6e0
       =======================
      Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0 
      EIP: [<c04ccdfc>] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8
      
      
      Looking at the code, I ended up in nfq_mangle() function (called by
      nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to
      the increased size of data passed to the function. AFAICT, it should ask
      for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the
      resulting sk_buff has not enough space to support the skb_put(skb, diff)
      call a few lines later, this results in the call to skb_over_panic().
      
      The patch below asks for allocation of a copy with enough space for
      mangled packet and the same amount of headroom as old sk_buff. While
      looking at how the regression appeared (e2b58a67), I noticed the same
      pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects
      those locations too.
      
      Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things
      are ok (2.6.25 and today's net-2.6 git tree).
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a732ed6
    • J
      tcp: Limit cwnd growth when deferring for GSO · 246eb2af
      John Heffner 提交于
      This fixes inappropriately large cwnd growth on sender-limited flows
      when GSO is enabled, limiting cwnd growth to 64k.
      Signed-off-by: NJohn Heffner <johnwheffner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      246eb2af
    • J
      tcp: Allow send-limited cwnd to grow up to max_burst when gso disabled · ce447eb9
      John Heffner 提交于
      This changes the logic in tcp_is_cwnd_limited() so that cwnd may grow
      up to tcp_max_burst() even when sk_can_gso() is false, or when
      sysctl_tcp_tso_win_divisor != 0.
      Signed-off-by: NJohn Heffner <johnwheffner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce447eb9
  8. 28 4月, 2008 2 次提交
  9. 25 4月, 2008 1 次提交
    • T
      tcp: tcp_probe buffer overflow and incorrect return value · 8d390efd
      Tom Quetchenbach 提交于
      tcp_probe has a bounds-checking bug that causes many programs (less,
      python) to crash reading /proc/net/tcp_probe. When it outputs a log
      line to the reader, it only checks if that line alone will fit in the
      reader's buffer, rather than that line and all the previous lines it
      has already written.
      
      tcpprobe_read also returns the wrong value if copy_to_user fails--it
      just passes on the return value of copy_to_user (number of bytes not
      copied), which makes a failure look like a success.
      
      This patch fixes the buffer overflow and sets the return value to
      -EFAULT if copy_to_user fails.
      
      Patch is against latest net-2.6; tested briefly and seems to fix the
      crashes in less and python.
      Signed-off-by: NTom Quetchenbach <virtualphtn@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d390efd
  10. 24 4月, 2008 1 次提交
  11. 22 4月, 2008 1 次提交
  12. 21 4月, 2008 3 次提交
  13. 20 4月, 2008 1 次提交
  14. 19 4月, 2008 1 次提交
  15. 18 4月, 2008 1 次提交
  16. 16 4月, 2008 10 次提交