1. 07 Oct, 2009 14 commits
  2. 06 Oct, 2009 1 commit
  3. 05 Oct, 2009 9 commits
  4. 02 Oct, 2009 12 commits
  5. 01 Oct, 2009 4 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