1. 07 Oct, 2009 9 commits
  2. 06 Oct, 2009 1 commit
  3. 05 Oct, 2009 9 commits
  4. 02 Oct, 2009 12 commits
  5. 01 Oct, 2009 9 commits
    • Atis Elsts's avatar
      net: Use sk_mark for routing lookup in more places · 914a9ab3
      Atis Elsts authored
      This patch against v2.6.31 adds support for route lookup using sk_mark in some 
      more places. The benefits from this patch are the following.
      First, SO_MARK option now has effect on UDP sockets too.
      Second, ip_queue_xmit() and inet_sk_rebuild_header() could fail to do routing 
      lookup correctly if TCP sockets with SO_MARK were used.
      Signed-off-by: default avatarAtis Elsts <atis@mikrotik.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      914a9ab3
    • Stephen Hemminger's avatar
      sky2: irqname based on pci address · 66466797
      Stephen Hemminger authored
      This is based on Michal Schmidt fix for skge.
      
      Most network drivers request their IRQ when the interface is activated.
      sky2 does it in ->probe() instead, because it can work with two-port
      cards where the two net_devices use the same IRQ. This works fine most
      of the time, except in some situations when the interface gets renamed.
      Consider this example:
      
      1. modprobe sky2
         The card is detected as eth0 and requests IRQ 17. Directory
         /proc/irq/17/eth0 is created.
      2. There is an udev rule which says this interface should be called
         eth1, so udev renames eth0 -> eth1.
      3. modprobe 8139too
         The Realtek card is detected as eth0. It will be using IRQ 17 too.
      4. ip link set eth0 up
         Now 8139too requests IRQ 17.
      
      The result is:
      WARNING: at fs/proc/generic.c:590 proc_register ...
      proc_dir_entry '17/eth0' already registered
      
      The fix is for sky2 to name the irq based on the pci device, as is done
      by some other devices DRM, infiniband, ...  ie. sky2@pci:0000:00:00
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Reviewed-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66466797
    • Michal Schmidt's avatar
      skge: use unique IRQ name · 415e69e6
      Michal Schmidt authored
      Most network drivers request their IRQ when the interface is activated.
      skge does it in ->probe() instead, because it can work with two-port
      cards where the two net_devices use the same IRQ. This works fine most
      of the time, except in some situations when the interface gets renamed.
      Consider this example:
      
      1. modprobe skge
         The card is detected as eth0 and requests IRQ 17. Directory
         /proc/irq/17/eth0 is created.
      2. There is an udev rule which says this interface should be called
         eth1, so udev renames eth0 -> eth1.
      3. modprobe 8139too
         The Realtek card is detected as eth0. It will be using IRQ 17 too.
      4. ip link set eth0 up
         Now 8139too requests IRQ 17.
      
      The result is:
      WARNING: at fs/proc/generic.c:590 proc_register ...
      proc_dir_entry '17/eth0' already registered
      ...
      And "ls /proc/irq/17" shows two subdirectories, both called eth0.
      
      Fix it by using a unique name for skge's IRQ, based on the PCI address.
      The naming from the example then looks like this:
      $ grep skge /proc/interrupts
       17:        169   IO-APIC-fasteoi   skge@pci:0000:00:0a.0, eth0
      
      irqbalance daemon will have to be taught to recognize "skge@" as an
      Ethernet interrupt. This will be a one-liner addition in classify.c. I
      will send a patch to irqbalance if this change is accepted.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Acked-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      415e69e6
    • Ori Finkelman's avatar
      IPv4 TCP fails to send window scale option when window scale is zero · 89e95a61
      Ori Finkelman authored
      Acknowledge TCP window scale support by inserting the proper option in SYN/ACK
      and SYN headers even if our window scale is zero.
      
      This fixes the following observed behavior:
      
      1. Client sends a SYN with TCP window scaling option and non zero window scale
      value to a Linux box.
      2. Linux box notes large receive window from client.
      3. Linux decides on a zero value of window scale for its part.
      4. Due to compare against requested window scale size option, Linux does not to
       send windows scale TCP option header on SYN/ACK at all.
      
      With the following result:
      
      Client box thinks TCP window scaling is not supported, since SYN/ACK had no
      TCP window scale option, while Linux thinks that TCP window scaling is
      supported (and scale might be non zero), since SYN had  TCP window scale
      option and we have a mismatched idea between the client and server
      regarding window sizes.
      
      Probably it also fixes up the following bug (not observed in practice):
      
      1. Linux box opens TCP connection to some server.
      2. Linux decides on zero value of window scale.
      3. Due to compare against computed window scale size option, Linux does
      not to set windows scale TCP  option header on SYN.
      
      With the expected result that the server OS does not use window scale option
      due to not receiving such an option in the SYN headers, leading to suboptimal
      performance.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad@codefidence.com>
      Signed-off-by: default avatarOri Finkelman <ori@comsleep.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89e95a61
    • Andrew Morton's avatar
      net/ipv4/tcp.c: fix min() type mismatch warning · 4fdb78d3
      Andrew Morton authored
      net/ipv4/tcp.c: In function 'do_tcp_setsockopt':
      net/ipv4/tcp.c:2050: warning: comparison of distinct pointer types lacks a cast
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4fdb78d3
    • Ralf Baechle's avatar
      Kconfig: STRIP: Remove stale bits of STRIP help text · 28ad3957
      Ralf Baechle authored
      Remove references to dead web site mosquitonet.Stanford.EDU.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28ad3957
    • Ralf Baechle's avatar
      NET: mkiss: Fix typo · 7b1401cf
      Ralf Baechle authored
      This typo was introduced by 5793f4be on
      October 14, 2005 ...
      Reported-by: default avatarMatti Aarnio <matti.aarnio@zmailer.org>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b1401cf
    • Eric Dumazet's avatar
      tg3: Remove prev_vlan_tag from struct tx_ring_info · bf18a9f8
      Eric Dumazet authored
      prev_vlan_tag field is not used.
      
      Patch saves 512*8 bytes per tx queue ring on 64bit arches.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarMatthew Carlson <mcarlson@broadcom.com>
      bf18a9f8
    • Uwe Kleine-König's avatar
      move virtnet_remove to .devexit.text · 3d1285be
      Uwe Kleine-König authored
      The function virtnet_remove is used only wrapped by __devexit_p so define
      it using __devexit.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Alex Williamson <alex.williamson@hp.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d1285be