1. 04 2月, 2013 3 次提交
  2. 01 2月, 2013 4 次提交
  3. 31 1月, 2013 1 次提交
  4. 30 1月, 2013 5 次提交
    • N
      tcp: Increment LISTENOVERFLOW and LISTENDROPS in tcp_v4_conn_request() · 2aeef18d
      Nivedita Singhvi 提交于
      We drop a connection request if the accept backlog is full and there are
      sufficient packets in the syn queue to warrant starting drops. Increment the
      appropriate counters so this isn't silent, for accurate stats and help in
      debugging.
      
      This patch assumes LINUX_MIB_LISTENDROPS is a superset of/includes the
      counter LINUX_MIB_LISTENOVERFLOWS.
      Signed-off-by: NNivedita Singhvi <niv@us.ibm.com>
      Acked-by: NVijay Subramanian <subramanian.vijay@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2aeef18d
    • Y
      ipv6 addrconf: Fix interface identifiers of 802.15.4 devices. · 5e98a36e
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      The "Universal/Local" (U/L) bit must be complmented according to RFC4944
      and RFC2464.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e98a36e
    • C
      pktgen: correctly handle failures when adding a device · 604dfd6e
      Cong Wang 提交于
      The return value of pktgen_add_device() is not checked, so
      even if we fail to add some device, for example, non-exist one,
      we still see "OK:...". This patch fixes it.
      
      After this patch, I got:
      
      	# echo "add_device non-exist" > /proc/net/pktgen/kpktgend_0
      	-bash: echo: write error: No such device
      	# cat /proc/net/pktgen/kpktgend_0
      	Running:
      	Stopped:
      	Result: ERROR: can not add device non-exist
      	# echo "add_device eth0" > /proc/net/pktgen/kpktgend_0
      	# cat /proc/net/pktgen/kpktgend_0
      	Running:
      	Stopped: eth0
      	Result: OK: add_device=eth0
      
      (Candidate for -stable)
      
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      604dfd6e
    • J
      netem: fix delay calculation in rate extension · a13d3104
      Johannes Naab 提交于
      The delay calculation with the rate extension introduces in v3.3 does
      not properly work, if other packets are still queued for transmission.
      For the delay calculation to work, both delay types (latency and delay
      introduces by rate limitation) have to be handled differently. The
      latency delay for a packet can overlap with the delay of other packets.
      The delay introduced by the rate however is separate, and can only
      start, once all other rate-introduced delays finished.
      
      Latency delay is from same distribution for each packet, rate delay
      depends on the packet size.
      
      .: latency delay
      -: rate delay
      x: additional delay we have to wait since another packet is currently
         transmitted
      
        .....----                    Packet 1
          .....xx------              Packet 2
                     .....------     Packet 3
          ^^^^^
          latency stacks
               ^^
               rate delay doesn't stack
                     ^^
                     latency stacks
      
        -----> time
      
      When a packet is enqueued, we first consider the latency delay. If other
      packets are already queued, we can reduce the latency delay until the
      last packet in the queue is send, however the latency delay cannot be
      <0, since this would mean that the rate is overcommitted.  The new
      reference point is the time at which the last packet will be send. To
      find the time, when the packet should be send, the rate introduces delay
      has to be added on top of that.
      Signed-off-by: NJohannes Naab <jn@stusta.de>
      Acked-by: NHagen Paul Pfeifer <hagen@jauu.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a13d3104
    • T
      l2tp: prevent l2tp_tunnel_delete racing with userspace close · 80d84ef3
      Tom Parkin 提交于
      If a tunnel socket is created by userspace, l2tp hooks the socket destructor
      in order to clean up resources if userspace closes the socket or crashes.  It
      also caches a pointer to the struct sock for use in the data path and in the
      netlink interface.
      
      While it is safe to use the cached sock pointer in the data path, where the
      skb references keep the socket alive, it is not safe to use it elsewhere as
      such access introduces a race with userspace closing the socket.  In
      particular, l2tp_tunnel_delete is prone to oopsing if a multithreaded
      userspace application closes a socket at the same time as sending a netlink
      delete command for the tunnel.
      
      This patch fixes this oops by forcing l2tp_tunnel_delete to explicitly look up
      a tunnel socket held by userspace using sockfd_lookup().
      Signed-off-by: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80d84ef3
  5. 28 1月, 2013 4 次提交
  6. 27 1月, 2013 3 次提交
  7. 24 1月, 2013 1 次提交
  8. 23 1月, 2013 2 次提交
    • S
      ipv4: Fix route refcount on pmtu discovery · b44108db
      Steffen Klassert 提交于
      git commit 9cb3a50c (ipv4: Invalidate the socket cached route on
      pmtu events if possible) introduced a refcount problem. We don't
      get a refcount on the route if we get it from__sk_dst_get(), but
      we need one if we want to reuse this route because __sk_dst_set()
      releases the refcount of the old route. This patch adds proper
      refcount handling for that case. We introduce a 'new' flag to
      indicate that we are going to use a new route and we release the
      old route only if we replace it by a new one.
      Reported-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b44108db
    • D
      net: net_cls: fd passed in SCM_RIGHTS datagram not set correctly · d8429506
      Daniel Wagner 提交于
      Commit 6a328d8c changed the update
      logic for the socket but it does not update the SCM_RIGHTS update
      as well. This patch is based on the net_prio fix commit
      
      48a87cc2
      
          net: netprio: fd passed in SCM_RIGHTS datagram not set correctly
      
          A socket fd passed in a SCM_RIGHTS datagram was not getting
          updated with the new tasks cgrp prioidx. This leaves IO on
          the socket tagged with the old tasks priority.
      
          To fix this add a check in the scm recvmsg path to update the
          sock cgrp prioidx with the new tasks value.
      
      Let's apply the same fix for net_cls.
      Signed-off-by: NDaniel Wagner <daniel.wagner@bmw-carit.de>
      Reported-by: NLi Zefan <lizefan@huawei.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: netdev@vger.kernel.org
      Cc: cgroups@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8429506
  9. 22 1月, 2013 2 次提交
  10. 21 1月, 2013 5 次提交
  11. 19 1月, 2013 1 次提交
  12. 18 1月, 2013 2 次提交
  13. 17 1月, 2013 5 次提交
  14. 16 1月, 2013 2 次提交