1. 25 1月, 2008 3 次提交
  2. 23 1月, 2008 4 次提交
  3. 21 1月, 2008 14 次提交
  4. 14 1月, 2008 1 次提交
  5. 12 1月, 2008 1 次提交
    • P
      [NETFILTER]: bridge: fix double POST_ROUTING invocation · 2948d2eb
      Patrick McHardy 提交于
      The bridge code incorrectly causes two POST_ROUTING hook invocations
      for DNATed packets that end up on the same bridge device. This
      happens because packets with a changed destination address are passed
      to dst_output() to make them go through the neighbour output function
      again to build a new destination MAC address, before they will continue
      through the IP hooks simulated by bridge netfilter.
      
      The resulting hook order is:
       PREROUTING	(bridge netfilter)
       POSTROUTING	(dst_output -> ip_output)
       FORWARD	(bridge netfilter)
       POSTROUTING	(bridge netfilter)
      
      The deferred hooks used to abort the first POST_ROUTING invocation,
      but since the only thing bridge netfilter actually really wants is
      a new MAC address, we can avoid going through the IP stack completely
      by simply calling the neighbour output function directly.
      
      Tested, reported and lots of data provided by: Damien Thebault <damien.thebault@gmail.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2948d2eb
  6. 11 1月, 2008 6 次提交
  7. 10 1月, 2008 3 次提交
  8. 09 1月, 2008 8 次提交
    • H
      [ATM]: Check IP header validity in mpc_send_packet · 1c9b7aa1
      Herbert Xu 提交于
      Al went through the ip_fast_csum callers and found this piece of code
      that did not validate the IP header.  While root crashing the machine
      by sending bogus packets through raw or AF_PACKET sockets isn't that
      serious, it is still nice to react gracefully.
      
      This patch ensures that the skb has enough data for an IP header and
      that the header length field is valid.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c9b7aa1
    • B
    • E
      [XFRM]: xfrm_algo_clone() allocates too much memory · 0f99be0d
      Eric Dumazet 提交于
      alg_key_len is the length in bits of the key, not in bytes.
      
      Best way to fix this is to move alg_len() function from net/xfrm/xfrm_user.c 
      to include/net/xfrm.h, and to use it in xfrm_algo_clone()
      
      alg_len() is renamed to xfrm_alg_len() because of its global exposition.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f99be0d
    • B
      [LRO] Fix lro_mgr->features checks · 877364e6
      Brice Goglin 提交于
      lro_mgr->features contains a bitmask of LRO_F_* values which are
      defined as power of two, not as bit indexes.
      They must be checked with x&LRO_F_FOO, not with test_bit(LRO_F_FOO,&x).
      Signed-off-by: NBrice Goglin <Brice.Goglin@inria.fr>
      Acked-by: NAndrew Gallatin <gallatin@myri.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      877364e6
    • P
      [NET]: Clone the sk_buff 'iif' field in __skb_clone() · 02f1c89d
      Paul Moore 提交于
      Both NetLabel and SELinux (other LSMs may grow to use it as well) rely
      on the 'iif' field to determine the receiving network interface of
      inbound packets.  Unfortunately, at present this field is not
      preserved across a skb clone operation which can lead to garbage
      values if the cloned skb is sent back through the network stack.  This
      patch corrects this problem by properly copying the 'iif' field in
      __skb_clone() and removing the 'iif' field assignment from
      skb_act_clone() since it is no longer needed.
      
      Also, while we are here, put the assignments in the same order as the
      offsets to reduce cacheline bounces.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02f1c89d
    • E
      [IPV4] ROUTE: ip_rt_dump() is unecessary slow · d8c92830
      Eric Dumazet 提交于
      I noticed "ip route list cache x.y.z.t" can be *very* slow.
      
      While strace-ing -T it I also noticed that first part of route cache
      is fetched quite fast :
      
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
      GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3772 <0.000047>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\234\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3736 <0.000042>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3740 <0.000055>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\234\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3712 <0.000043>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3732 <0.000053>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
      GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3708 <0.000052>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
      GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3680 <0.000041>
      
      while the part at the end of the table is more expensive:
      
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3656 <0.003857>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3772 <0.003891>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3712 <0.003765>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3700 <0.003879>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3676 <0.003797>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3724 <0.003856>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\234\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3736 <0.003848>
      
      The following patch corrects this performance/latency problem,
      removing quadratic behavior.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8c92830
    • D
      [NET]: Stop polling when napi_disable() is pending. · fed17f30
      David S. Miller 提交于
      This finally adds the code in net_rx_action() to break out of the
      ->poll()'ing loop when a napi_disable() is found to be pending.
      
      Now, even if a device is being flooded with packets it can be cleanly
      brought down.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fed17f30
    • A
      mac80211: return an error when SIWRATE doesn't match any rate · 5cdfed54
      Andrew Lutomirski 提交于
      Currently mac80211 fails silently when trying to set a nonexistent
      rate.  Return an error instead.
      Signed-Off-By: NAndy Lutomirski <luto@myrealbox.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5cdfed54