1. 02 5月, 2016 7 次提交
    • J
      gre: do not pull header in ICMP error processing · b7f8fe25
      Jiri Benc 提交于
      iptunnel_pull_header expects that IP header was already pulled; with this
      expectation, it pulls the tunnel header. This is not true in gre_err.
      Furthermore, ipv4_update_pmtu and ipv4_redirect expect that skb->data points
      to the IP header.
      
      We cannot pull the tunnel header in this path. It's just a matter of not
      calling iptunnel_pull_header - we don't need any of its effects.
      
      Fixes: bda7bb46 ("gre: Allow multiple protocol listener for gre protocol.")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7f8fe25
    • T
      net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case · 2c94b537
      Tim Bingham 提交于
      Prior to commit d92cff89 ("net_dbg_ratelimited: turn into no-op
      when !DEBUG") the implementation of net_dbg_ratelimited() was buggy
      for both the DEBUG and CONFIG_DYNAMIC_DEBUG cases.
      
      The bug was that net_ratelimit() was being called and, despite
      returning true, nothing was being printed to the console. This
      resulted in messages like the following -
      
      "net_ratelimit: %d callbacks suppressed"
      
      with no other output nearby.
      
      After commit d92cff89 ("net_dbg_ratelimited: turn into no-op when
      !DEBUG") the bug is fixed for the DEBUG case. However, there's no
      output at all for CONFIG_DYNAMIC_DEBUG case.
      
      This patch restores debug output (if enabled) for the
      CONFIG_DYNAMIC_DEBUG case.
      
      Add a definition of net_dbg_ratelimited() for the CONFIG_DYNAMIC_DEBUG
      case. The implementation takes care to check that dynamic debugging is
      enabled before calling net_ratelimit().
      
      Fixes: d92cff89 ("net_dbg_ratelimited: turn into no-op when !DEBUG")
      Signed-off-by: NTim Bingham <tbingham@akamai.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c94b537
    • H
      tipc: only process unicast on intended node · efe79050
      Hamish Martin 提交于
      We have observed complete lock up of broadcast-link transmission due to
      unacknowledged packets never being removed from the 'transmq' queue. This
      is traced to nodes having their ack field set beyond the sequence number
      of packets that have actually been transmitted to them.
      Consider an example where node 1 has sent 10 packets to node 2 on a
      link and node 3 has sent 20 packets to node 2 on another link. We
      see examples of an ack from node 2 destined for node 3 being treated as
      an ack from node 2 at node 1. This leads to the ack on the node 1 to node
      2 link being increased to 20 even though we have only sent 10 packets.
      When node 1 does get around to sending further packets, none of the
      packets with sequence numbers less than 21 are actually removed from the
      transmq.
      To resolve this we reinstate some code lost in commit d999297c ("tipc:
      reduce locking scope during packet reception") which ensures that only
      messages destined for the receiving node are processed by that node. This
      prevents the sequence numbers from getting out of sync and resolves the
      packet leakage, thereby resolving the broadcast-link transmission
      lock-ups we observed.
      
      While we are aware that this change only patches over a root problem that
      we still haven't identified, this is a sanity test that it is always
      legitimate to do. It will remain in the code even after we identify and
      fix the real problem.
      Reviewed-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
      Reviewed-by: NJohn Thompson <john.thompson@alliedtelesis.co.nz>
      Signed-off-by: NHamish Martin <hamish.martin@alliedtelesis.co.nz>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efe79050
    • M
      cxgb3: fix out of bounds read · 0b86a2a1
      Michal Schmidt 提交于
      An out of bounds read of 2 bytes was discovered in cxgb3 with KASAN.
      
      t3_config_rss() expects both arrays it gets as parameters to have
      terminators. setup_rss(), the caller, forgets to add a terminator to
      one of the arrays. Thankfully the iteration in t3_config_rss() stops
      anyway, but in the last iteration the check for the terminator
      is an out of bounds read.
      
      Add the missing terminator to rspq_map[].
      Reported-by: NJan Stancek <jstancek@redhat.com>
      Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b86a2a1
    • A
      net/smscx5xx: use the device tree for mac address · c489565b
      Arnd Bergmann 提交于
      This takes the MAC address for smsc75xx/smsc95xx USB network devices
      from a the device tree. This is required to get a usable persistent
      address on the popular beagleboard, whose hardware designers
      accidentally forgot that an ethernet device really requires an a
      MAC address to be functional.
      
      The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores
      the MAC address in ROM accessible via VC4 firmware.
      
      The smsc75xx and smsc95xx drivers are just two copies of the
      same code, so better fix both.
      
      [lkundrak@v3.sk: updated to use of_get_property() as per suggestion from
      Arnd, reworded the message and comments a bit]
      Tested-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c489565b
    • C
      soreuseport: Fix TCP listener hash collision · 90e5d0db
      Craig Gallek 提交于
      I forgot to include a check for listener port equality when deciding
      if two sockets should belong to the same reuseport group.  This was
      not caught previously because it's only necessary when two listening
      sockets for the same user happen to hash to the same listener bucket.
      The same error does not exist in the UDP path.
      
      Fixes: c125e80b("soreuseport: fast reuseport TCP socket selection")
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90e5d0db
    • W
      net: l2tp: fix reversed udp6 checksum flags · 018f8258
      Wang Shanker 提交于
      This patch fixes a bug which causes the behavior of whether to ignore
      udp6 checksum of udp6 encapsulated l2tp tunnel contrary to what
      userspace program requests.
      
      When the flag `L2TP_ATTR_UDP_ZERO_CSUM6_RX` is set by userspace, it is
      expected that udp6 checksums of received packets of the l2tp tunnel
      to create should be ignored. In `l2tp_netlink.c`:
      `l2tp_nl_cmd_tunnel_create()`, `cfg.udp6_zero_rx_checksums` is set
      according to the flag, and then passed to `l2tp_core.c`:
      `l2tp_tunnel_create()` and then `l2tp_tunnel_sock_create()`. In
      `l2tp_tunnel_sock_create()`, `udp_conf.use_udp6_rx_checksums` is set
      the same to `cfg.udp6_zero_rx_checksums`. However, if we want the
      checksum to be ignored, `udp_conf.use_udp6_rx_checksums` should be set
      to `false`, i.e. be set to the contrary. Similarly, the same should be
      done to `udp_conf.use_udp6_tx_checksums`.
      Signed-off-by: NMiao Wang <shankerwangmiao@gmail.com>
      Acked-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      018f8258
  2. 30 4月, 2016 1 次提交
  3. 29 4月, 2016 32 次提交