1. 09 1月, 2008 2 次提交
  2. 04 1月, 2008 3 次提交
    • M
      [INET]: Fix netdev renaming and inet address labels · 44344b2a
      Mark McLoughlin 提交于
      When re-naming an interface, the previous secondary address
      labels get lost e.g.
      
        $> brctl addbr foo
        $> ip addr add 192.168.0.1 dev foo
        $> ip addr add 192.168.0.2 dev foo label foo:00
        $> ip addr show dev foo | grep inet
          inet 192.168.0.1/32 scope global foo
          inet 192.168.0.2/32 scope global foo:00
        $> ip link set foo name bar
        $> ip addr show dev bar | grep inet
          inet 192.168.0.1/32 scope global bar
          inet 192.168.0.2/32 scope global bar:2
      
      Turns out to be a simple thinko in inetdev_changename() - clearly we
      want to look at the address label, rather than the device name, for
      a suffix to retain.
      Signed-off-by: NMark McLoughlin <markmc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44344b2a
    • E
      [XFRM]: Do not define km_migrate() if !CONFIG_XFRM_MIGRATE · 2d60abc2
      Eric Dumazet 提交于
      In include/net/xfrm.h we find :
      
      #ifdef CONFIG_XFRM_MIGRATE
      extern int km_migrate(struct xfrm_selector *sel, u8 dir, u8 type,
                            struct xfrm_migrate *m, int num_bundles);
      ...
      #endif
      
      We can also guard the function body itself in net/xfrm/xfrm_state.c
      with same condition.
      
      (Problem spoted by sparse checker)
      make C=2 net/xfrm/xfrm_state.o
      ...
      net/xfrm/xfrm_state.c:1765:5: warning: symbol 'km_migrate' was not declared. Should it be static?
      ...
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d60abc2
    • J
      [X25]: Add missing x25_neigh_put · 76975f8a
      Julia Lawall 提交于
      The function x25_get_neigh increments a reference count.  At the point of
      the second goto out, the result of calling x25_get_neigh is only stored in
      a local variable, and thus no one outside the function will be able to
      decrease the reference count.  Thus, x25_neigh_put should be called before
      the return in this case.
      
      The problem was found using the following semantic match.
      (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      
      @@
      type T,T1,T2;
      identifier E;
      statement S;
      expression x1,x2,x3;
      int ret;
      @@
      
        T E;
        ...
      * if ((E = x25_get_neigh(...)) == NULL)
        S
        ... when != x25_neigh_put(...,(T1)E,...)
            when != if (E != NULL) { ... x25_neigh_put(...,(T1)E,...); ...}
            when != x1 = (T1)E
            when != E = x3;
            when any
        if (...) {
          ... when != x25_neigh_put(...,(T2)E,...)
              when != if (E != NULL) { ... x25_neigh_put(...,(T2)E,...); ...}
              when != x2 = (T2)E
      (
      *   return;
      |
      *   return ret;
      )
        }
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76975f8a
  3. 03 1月, 2008 1 次提交
  4. 30 12月, 2007 2 次提交
    • D
      [BLUETOOTH]: put_device before device_del fix · 38b7da09
      Dave Young 提交于
      Because of workqueue delay, the put_device could be called before
      device_del, so move it to del_conn.
      
      Signed-off-by: Dave Young <hidave.darkstar@gmail.com> 
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38b7da09
    • G
      [TCP]: use non-delayed ACK for congestion control RTT · 2072c228
      Gavin McCullagh 提交于
      When a delayed ACK representing two packets arrives, there are two RTT
      samples available, one for each packet.  The first (in order of seq
      number) will be artificially long due to the delay waiting for the
      second packet, the second will trigger the ACK and so will not itself
      be delayed.
      
      According to rfc1323, the SRTT used for RTO calculation should use the
      first rtt, so receivers echo the timestamp from the first packet in
      the delayed ack.  For congestion control however, it seems measuring
      delayed ack delay is not desirable as it varies independently of
      congestion.
      
      The patch below causes seq_rtt and last_ackt to be updated with any
      available later packet rtts which should have less (and hopefully
      zero) delack delay.  The rtt value then gets passed to
      ca_ops->pkts_acked().
      
      Where TCP_CONG_RTT_STAMP was set, effort was made to supress RTTs from
      within a TSO chunk (!fully_acked), using only the final ACK (which
      includes any TSO delay) to generate RTTs.  This patch removes these
      checks so RTTs are passed for each ACK to ca_ops->pkts_acked().
      
      For non-delay based congestion control (cubic, h-tcp), rtt is
      sometimes used for rtt-scaling.  In shortening the RTT, this may make
      them a little less aggressive.  Delay-based schemes (eg vegas, veno,
      illinois) should get a cleaner, more accurate congestion signal,
      particularly for small cwnds.  The congestion control module can
      potentially also filter out bad RTTs due to the delayed ack alarm by
      looking at the associated cnt which (where delayed acking is in use)
      should probably be 1 if the alarm went off or greater if the ACK was
      triggered by a packet.
      Signed-off-by: NGavin McCullagh <gavin.mccullagh@nuim.ie>
      Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2072c228
  5. 29 12月, 2007 1 次提交
    • S
      [IPV4] Fix ip=dhcp regression · 9cecd07c
      Simon Horman 提交于
      David Brownell pointed out a regression in my recent "Fix ip command
      line processing" patch. It turns out to be a fairly blatant oversight on
      my part whereby ic_enable is never set, and thus autoconfiguration is
      never enabled. Clearly my testing was broken :-(
      
      The solution that I have is to set ic_enable to 1 if we hit
      ip_auto_config_setup(), which basically means that autoconfiguration is
      activated unless told otherwise. I then flip ic_enable to 0 if ip=off,
      ip=none, ip=::::::off or ip=::::::none using ic_proto_name();
      
      The incremental patch is below, let me know if a non-incremental version
      is prepared, as I did as for the original patch to be reverted pending a
      fix.
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cecd07c
  6. 27 12月, 2007 4 次提交
  7. 21 12月, 2007 11 次提交
  8. 20 12月, 2007 8 次提交
  9. 18 12月, 2007 1 次提交
  10. 17 12月, 2007 7 次提交