1. 01 Dec, 2012 6 commits
  2. 30 Nov, 2012 2 commits
  3. 27 Nov, 2012 4 commits
  4. 26 Nov, 2012 2 commits
    • David Woodhouse's avatar
      atm: br2684: Fix excessive queue bloat · ae088d66
      David Woodhouse authored
      There's really no excuse for an additional wmem_default of buffering
      between the netdev queue and the ATM device. Two packets (one in-flight,
      and one ready to send) ought to be fine. It's not as if it should take
      long to get another from the netdev queue when we need it.
      
      If necessary we can make the queue space configurable later, but I don't
      think it's likely to be necessary.
      
      cf. commit 9d02daf7 (pppoatm: Fix
      excessive queue bloat) which did something very similar for PPPoATM.
      
      Note that there is a tremendously unlikely race condition which may
      result in qspace temporarily going negative. If a CPU running the
      br2684_pop() function goes off into the weeds for a long period of time
      after incrementing qspace to 1, but before calling netdev_wake_queue()...
      and another CPU ends up calling br2684_start_xmit() and *stopping* the
      queue again before the first CPU comes back, the netdev queue could
      end up being woken when qspace has already reached zero.
      
      An alternative approach to coping with this race would be to check in
      br2684_start_xmit() for qspace==0 and return NETDEV_TX_BUSY, but just
      using '> 0' and '< 1' for comparison instead of '== 0' and '!= 0' is
      simpler. It just warranted a mention of *why* we do it that way...
      
      Move the call to atmvcc->send() to happen *after* the accounting and
      potentially stopping the netdev queue, in br2684_xmit_vcc(). This matters
      if the ->send() call suffers an immediate failure, because it'll call
      br2684_pop() with the offending skb before returning. We want that to
      happen *after* we've done the initial accounting for the packet in
      question. Also make it return an appropriate success/failure indication
      while we're at it.
      
      Tested by running 'ping -l 1000 bottomless.aaisp.net.uk' from within my
      network, with only a single PPPoE-over-BR2684 link running. And after
      setting txqueuelen on the nas0 interface to something low (5, in fact).
      Before the patch, we'd see about 15 packets being queued and a resulting
      latency of ~56ms being reached. After the patch, we see only about 8,
      which is fairly much what we expect. And a max latency of ~36ms. On this
      OpenWRT box, wmem_default is 163840.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Reviewed-by: default avatarKrzysztof Mazur <krzysiek@podlesie.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae088d66
    • Ben Hutchings's avatar
      dsa: Hide core config options; make drivers select what they need · b3422a31
      Ben Hutchings authored
      Commit 82167cb8 ('net: dsa/slave: Fix
      compilation warnings') fixed one possible invalid configuration
      (NET_DSA enabled with no trailer formats) but added others: drivers
      can select NET_DSA without its dependencies being met.
      
      It's not very useful to make either the DSA core or the tagging
      formats manually selectable without a driver to use them, so:
      
      1. Define a hidden HAVE_NET_DSA option and move the dependencies of
         NET_DSA to that.  While we're at it, drop the deprecated
         EXPERIMENTAL dependency.
      2. Make NET_DSA and the drivers dependent on HAVE_NET_DSA.
      3. Hide the tagging format options again.
      4. Make drivers select both NET_DSA and the appropriate tagging format
         option.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3422a31
  5. 25 Nov, 2012 4 commits
    • Joe Perches's avatar
      ipv4/ipmr and ipv6/ip6mr: Convert int mroute_do_<foo> to bool · 53d6841d
      Joe Perches authored
      Save a few bytes per table by convert mroute_do_assert and
      mroute_do_pim from int to bool.
      
      Remove !! as the compiler does that when assigning int to bool.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53d6841d
    • Eric Dumazet's avatar
      ipv4: ipmr: various fixes and cleanups · 5e1859fb
      Eric Dumazet authored
      1) ip_mroute_setsockopt() & ip_mroute_getsockopt() should not
         access/set raw_sk(sk)->ipmr_table before making sure the socket
         is a raw socket, and protocol is IGMP
      
      2) MRT_INIT should return -EINVAL if optlen != sizeof(int), not
         -ENOPROTOOPT
      
      3) MRT_ASSERT & MRT_PIM should validate optlen
      
      4) " (v) ? 1 : 0 " can be written as " !!v "
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e1859fb
    • viresh kumar's avatar
      net: dsa/slave: Fix compilation warnings · 82167cb8
      viresh kumar authored
      Currently when none of CONFIG_NET_DSA_TAG_DSA, CONFIG_NET_DSA_TAG_EDSA and
      CONFIG_NET_DSA_TAG_TRAILER is defined, we get following compilation warnings:
      
      net/dsa/slave.c:51:12: warning: 'dsa_slave_init' defined but not used [-Wunused-function]
      net/dsa/slave.c:60:12: warning: 'dsa_slave_open' defined but not used [-Wunused-function]
      net/dsa/slave.c:98:12: warning: 'dsa_slave_close' defined but not used [-Wunused-function]
      net/dsa/slave.c:116:13: warning: 'dsa_slave_change_rx_flags' defined but not used [-Wunused-function]
      net/dsa/slave.c:127:13: warning: 'dsa_slave_set_rx_mode' defined but not used [-Wunused-function]
      net/dsa/slave.c:136:12: warning: 'dsa_slave_set_mac_address' defined but not used [-Wunused-function]
      net/dsa/slave.c:164:12: warning: 'dsa_slave_ioctl' defined but not used [-Wunused-function]
      
      Earlier approach to fix this was discussed here:
      
      lkml.org/lkml/2012/10/29/549
      
      This is another approach to fix it. This is done by some changes in config
      options, which make more sense than the earlier approach. As, atleast one
      tagging option must always be selected for using net/dsa/ infrastructure, this
      patch selects NET_DSA from tagging configs instead of having it as an selectable
      config.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82167cb8
    • Marc Kleine-Budde's avatar
      net: sched: enable CAN Identifier to be build into kernel · a303fbf3
      Marc Kleine-Budde authored
      This patch makes it possible to build the CAN Identifier into the kernel, even
      if the CAN support is build as a module.
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a303fbf3
  6. 22 Nov, 2012 7 commits
    • Julian Anastasov's avatar
      ipv4: do not cache looped multicasts · 63617421
      Julian Anastasov authored
      	Starting from 3.6 we cache output routes for
      multicasts only when using route to 224/4. For local receivers
      we can set RTCF_LOCAL flag depending on the membership but
      in such case we use maddr and saddr which are not caching
      keys as before. Additionally, we can not use same place to
      cache routes that differ in RTCF_LOCAL flag value.
      
      	Fix it by caching only RTCF_MULTICAST entries
      without RTCF_LOCAL (send-only, no loopback). As a side effect,
      we avoid unneeded lookup for fnhe when not caching because
      multicasts are not redirected and they do not learn PMTU.
      
      	Thanks to Maxime Bizon for showing the caching
      problems in __mkroute_output for 3.6 kernels: different
      RTCF_LOCAL flag in cache can lead to wrong ip_mc_output or
      ip_output call and the visible problem is that traffic can
      not reach local receivers via loopback.
      Reported-by: default avatarMaxime Bizon <mbizon@freebox.fr>
      Tested-by: default avatarMaxime Bizon <mbizon@freebox.fr>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63617421
    • Andrey Vagin's avatar
      ipv6: adapt connect for repair move · 2b916477
      Andrey Vagin authored
      This is work the same as for ipv4.
      
      All other hacks about tcp repair are in common code for ipv4 and ipv6,
      so this patch is enough for repairing ipv6 connections.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarAndrey Vagin <avagin@openvz.org>
      Acked-by: default avatarPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b916477
    • Paul Gortmaker's avatar
      tipc: delete TIPC_ADVANCED Kconfig variable · 94fc9c47
      Paul Gortmaker authored
      There used to be a time when TIPC had lots of Kconfig knobs the
      end user could alter, but they have all been made automatic or
      obsolete, with the exception of CONFIG_TIPC_PORTS.  This
      previously existing set of options was all hidden under the
      TIPC_ADVANCED setting, which does not exist in any code, but
      only in Kconfig scope.
      
      Having this now, just to hide the one remaining "advanced"
      option no longer makes sense.  Remove it.  Also get rid of the
      ifdeffery in the TIPC code that allowed for TIPC_PORTS to be
      possibly undefined.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      94fc9c47
    • Ying Xue's avatar
      tipc: eliminate an unnecessary cast of node variable · 4cb7d55a
      Ying Xue authored
      As the variable:node is currently defined to u32 type, it is
      unnecessary to cast its type to u32 again when using it.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      4cb7d55a
    • Jon Maloy's avatar
      tipc: introduce message to synchronize broadcast link · c64f7a6a
      Jon Maloy authored
      Upon establishing a first link between two nodes, there is
      currently a risk that the two endpoints will disagree on exactly
      which sequence number reception and acknowleding of broadcast
      packets should start.
      
      The following scenarios may happen:
      
      1: Node A sends an ACTIVATE message to B, telling it to start acking
         packets from sequence number N.
      2: Node A sends out broadcast N, but does not expect an acknowledge
         from B, since B is not yet in its broadcast receiver's list.
      3: Node A receives ACK for N from all nodes except B, and releases
         packet N.
      4: Node B receives the ACTIVATE, activates its link endpoint, and
         stores the value N as sequence number of first expected packet.
      5: Node B sends a NAME_DISTR message to A.
      6: Node A receives the NAME_DISTR message, and activates its endpoint.
         At this moment B is added to A's broadcast receiver's set.
         Node A also sets sequence number 0 as the first broadcast packet
         to be received from B.
      7: Node A sends broadcast N+1.
      8: B receives N+1, determines there is a gap in the sequence, since
         it is expecting N, and sends a NACK for N back to A.
      9: Node A has already released N, so no retransmission is possible.
         The broadcast link in direction A->B is stale.
      
      In addition to, or instead of, 7-9 above, the following may happen:
      
      10: Node B sends broadcast M > 0 to A.
      11: Node A receives M, falsely decides there must be a gap, since
          it is expecting packet 0, and asks for retransmission of packets
          [0,M-1].
      12: Node B has already released these packets, so the broadcast
          link is stale in direction B->A.
      
      We solve this problem by introducing a new unicast message type,
      BCAST_PROTOCOL/STATE, to convey the sequence number of the next
      sent broadcast packet to the other endpoint, at exactly the moment
      that endpoint is added to the own node's broadcast receivers list,
      and before any other unicast messages are permitted to be sent.
      
      Furthermore, we don't allow any node to start receiving and
      processing broadcast packets until this new synchronization
      message has been received.
      
      To maintain backwards compatibility, we still open up for
      broadcast reception if we receive a NAME_DISTR message without
      any preceding broadcast sync message. In this case, we must
      assume that the other end has an older code version, and will
      never send out the new synchronization message. Hence, for mixed
      old and new nodes, the issue arising in 7-12 of the above may
      happen with the same probability as before.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      c64f7a6a
    • Ying Xue's avatar
      tipc: rename supported flag to recv_permitted · 389dd9bc
      Ying Xue authored
      Rename the "supported" flag in bclink structure to "recv_permitted"
      to better reflect what it is used for. When this flag is set for a
      given node, we are permitted to receive and acknowledge broadcast
      messages from that node.  Convert it to a bool at the same time,
      since it is not used to store any numerical values.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      389dd9bc
    • Ying Xue's avatar
      tipc: remove supportable flag from bclink structure · 818f4da5
      Ying Xue authored
      The "supportable" flag in bclink structure is a compatibility flag
      indicating whether a peer node is capable of receiving TIPC broadcast
      messages. However, all TIPC versions since tipc-1.5, and after the
      inclusion in the upstream Linux kernel in 2006, support this capability.
      It is highly unlikely that anybody is still using such an old
      version of TIPC, let alone that they want to mix it with TIPC-2.0
      nodes. Therefore, we now remove the "supportable" flag.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      818f4da5
  7. 21 Nov, 2012 14 commits
  8. 20 Nov, 2012 1 commit
    • Neil Horman's avatar
      sctp: send abort chunk when max_retrans exceeded · de4594a5
      Neil Horman authored
      In the event that an association exceeds its max_retrans attempts, we should
      send an ABORT chunk indicating that we are closing the assocation as a result.
      Because of the nature of the error, its unlikely to be received, but its a nice
      clean way to close the association if it does make it through, and it will give
      anyone watching via tcpdump a clue as to what happened.
      
      Change notes:
      v2)
      	* Removed erroneous changes from sctp_make_violation_parmlen
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: linux-sctp@vger.kernel.org
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de4594a5