1. 09 Oct, 2014 3 commits
  2. 08 Oct, 2014 2 commits
  3. 07 Oct, 2014 6 commits
    • Fabian Frederick's avatar
      wimax: convert printk to pr_foo() · 28b7deae
      Fabian Frederick authored
      Use current logging functions and add module name prefix.
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28b7deae
    • Fabian Frederick's avatar
      af_unix: remove 0 assignment on static · 505e907d
      Fabian Frederick authored
      static values are automatically initialized to 0
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      505e907d
    • David S. Miller's avatar
      ipv6: Do not warn for informational ICMP messages, regardless of type. · ea85a0a2
      David S. Miller authored
      There is no reason to emit a log message for these.
      
      Based upon a suggestion from Hannes Frederic Sowa.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      ea85a0a2
    • Herbert Xu's avatar
      bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING · 93fdd47e
      Herbert Xu authored
      As we may defragment the packet in IPv4 PRE_ROUTING and refragment
      it after POST_ROUTING we should save the value of frag_max_size.
      
      This is still very wrong as the bridge is supposed to leave the
      packets intact, meaning that the right thing to do is to use the
      original frag_list for fragmentation.
      
      Unfortunately we don't currently guarantee that the frag_list is
      left untouched throughout netfilter so until this changes this is
      the best we can do.
      
      There is also a spot in FORWARD where it appears that we can
      forward a packet without going through fragmentation, mark it
      so that we can fix it later.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93fdd47e
    • Jon Maloy's avatar
      tipc: fix bug in multicast congestion handling · 908344cd
      Jon Maloy authored
      One aim of commit 50100a5e ("tipc:
      use pseudo message to wake up sockets after link congestion") was
      to handle link congestion abatement in a uniform way for both unicast
      and multicast transmit. However, the latter doesn't work correctly,
      and has been broken since the referenced commit was applied.
      
      If a user now sends a burst of multicast messages that is big
      enough to cause broadcast link congestion, it will be put to sleep,
      and not be waked up when the congestion abates as it should be.
      
      This has two reasons. First, the flag that is used, TIPC_WAKEUP_USERS,
      is set correctly, but in the wrong field. Instead of setting it in the
      'action_flags' field of the arrival node struct, it is by mistake set
      in the dummy node struct that is owned by the broadcast link, where it
      will never tested for. Second, we cannot use the same flag for waking
      up unicast and multicast users, since the function tipc_node_unlock()
      needs to pick the wakeup pseudo messages to deliver from different
      queues. It must hence be able to distinguish between the two cases.
      
      This commit solves this problem by adding a new flag
      TIPC_WAKEUP_BCAST_USERS, and a new function tipc_bclink_wakeup_user().
      The latter is to be called by tipc_node_unlock() when the named flag,
      now set in the correct field, is encountered.
      
      v2: using explicit 'unsigned int' declaration instead of 'uint', as
      per comment from David Miller.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      908344cd
    • Eric Dumazet's avatar
      net: better IFF_XMIT_DST_RELEASE support · 02875878
      Eric Dumazet authored
      Testing xmit_more support with netperf and connected UDP sockets,
      I found strange dst refcount false sharing.
      
      Current handling of IFF_XMIT_DST_RELEASE is not optimal.
      
      Dropping dst in validate_xmit_skb() is certainly too late in case
      packet was queued by cpu X but dequeued by cpu Y
      
      The logical point to take care of drop/force is in __dev_queue_xmit()
      before even taking qdisc lock.
      
      As Julian Anastasov pointed out, need for skb_dst() might come from some
      packet schedulers or classifiers.
      
      This patch adds new helper to cleanly express needs of various drivers
      or qdiscs/classifiers.
      
      Drivers that need skb_dst() in their ndo_start_xmit() should call
      following helper in their setup instead of the prior :
      
      	dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
      ->
      	netif_keep_dst(dev);
      
      Instead of using a single bit, we use two bits, one being
      eventually rebuilt in bonding/team drivers.
      
      The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being
      rebuilt in bonding/team. Eventually, we could add something
      smarter later.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02875878
  4. 06 Oct, 2014 16 commits
  5. 05 Oct, 2014 13 commits