1. 22 Jul, 2019 12 commits
  2. 19 Jul, 2019 5 commits
  3. 18 Jul, 2019 14 commits
  4. 17 Jul, 2019 9 commits
    • David Ahern's avatar
      ipv6: rt6_check should return NULL if 'from' is NULL · 49d05fe2
      David Ahern authored
      Paul reported that l2tp sessions were broken after the commit referenced
      in the Fixes tag. Prior to this commit rt6_check returned NULL if the
      rt6_info 'from' was NULL - ie., the dst_entry was disconnected from a FIB
      entry. Restore that behavior.
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: default avatarPaul Donohue <linux-kernel@PaulSD.com>
      Tested-by: default avatarPaul Donohue <linux-kernel@PaulSD.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49d05fe2
    • Jon Maloy's avatar
      tipc: initialize 'validated' field of received packets · 866e5fd8
      Jon Maloy authored
      The tipc_msg_validate() function leaves a boolean flag 'validated' in
      the validated buffer's control block, to avoid performing this action
      more than once. However, at reception of new packets, the position of
      this field may already have been set by lower layer protocols, so
      that the packet is erroneously perceived as already validated by TIPC.
      
      We fix this by initializing the said field to 'false' before performing
      the initial validation.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      866e5fd8
    • David S. Miller's avatar
      Merge branch 'ipv4-relax-source-validation-check-for-loopback-packets' · 7b379472
      David S. Miller authored
      Cong Wang says:
      
      ====================
      ipv4: relax source validation check for loopback packets
      
      This patchset fixes a corner case when loopback packets get dropped
      by rp_filter when we route them from veth to lo. Patch 1 is the fix
      and patch 2 provides a simplified test case for this scenario.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b379472
    • Cong Wang's avatar
      selftests: add a test case for rp_filter · adb701d6
      Cong Wang authored
      Add a test case to simulate the loopback packet case fixed
      in the previous patch.
      
      This test gets passed after the fix:
      
      IPv4 rp_filter tests
          TEST: rp_filter passes local packets                                [ OK ]
          TEST: rp_filter passes loopback packets                             [ OK ]
      
      Cc: David Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      adb701d6
    • Cong Wang's avatar
      fib: relax source validation check for loopback packets · 66f82095
      Cong Wang authored
      In a rare case where we redirect local packets from veth to lo,
      these packets fail to pass the source validation when rp_filter
      is turned on, as the tracing shows:
      
        <...>-311708 [040] ..s1 7951180.957825: fib_table_lookup: table 254 oif 0 iif 1 src 10.53.180.130 dst 10.53.180.130 tos 0 scope 0 flags 0
        <...>-311708 [040] ..s1 7951180.957826: fib_table_lookup_nh: nexthop dev eth0 oif 4 src 10.53.180.130
      
      So, the fib table lookup returns eth0 as the nexthop even though
      the packets are local and should be routed to loopback nonetheless,
      but they can't pass the dev match check in fib_info_nh_uses_dev()
      without this patch.
      
      It should be safe to relax this check for this special case, as
      normally packets coming out of loopback device still have skb_dst
      so they won't even hit this slow path.
      
      Cc: Julian Anastasov <ja@ssi.bg>
      Cc: David Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66f82095
    • David S. Miller's avatar
      Merge branch 'mlxsw-Two-fixes' · f1bf3e2a
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Two fixes
      
      This patchset contains two fixes for mlxsw.
      
      Patch #1 from Petr fixes an issue in which DSCP rewrite can occur even
      if the egress port was switched to Trust L2 mode where priority mapping
      is based on PCP.
      
      Patch #2 fixes a problem where packets can be learned on a non-existing
      FID if a tc filter with a redirect action is configured on a bridged
      port. The problem and fix are explained in detail in the commit message.
      
      Please consider both patches for 5.2.y
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1bf3e2a
    • Ido Schimmel's avatar
      mlxsw: spectrum: Do not process learned records with a dummy FID · 577fa14d
      Ido Schimmel authored
      The switch periodically sends notifications about learned FDB entries.
      Among other things, the notification includes the FID (Filtering
      Identifier) and the port on which the MAC was learned.
      
      In case the driver does not have the FID defined on the relevant port,
      the following error will be periodically generated:
      
      mlxsw_spectrum2 0000:06:00.0 swp32: Failed to find a matching {Port, VID} following FDB notification
      
      This is not supposed to happen under normal conditions, but can happen
      if an ingress tc filter with a redirect action is installed on a bridged
      port. The redirect action will cause the packet's FID to be changed to
      the dummy FID and a learning notification will be emitted with this FID
      - which is not defined on the bridged port.
      
      Fix this by having the driver ignore learning notifications generated
      with the dummy FID and delete them from the device.
      
      Another option is to chain an ignore action after the redirect action
      which will cause the device to disable learning, but this means that we
      need to consume another action whenever a redirect action is used. In
      addition, the scenario described above is merely a corner case.
      
      Fixes: cedbb8b2 ("mlxsw: spectrum_flower: Set dummy FID before forward action")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarAlex Kushnarov <alexanderk@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Tested-by: default avatarAlex Kushnarov <alexanderk@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      577fa14d
    • Petr Machata's avatar
      mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed · dedfde2f
      Petr Machata authored
      Spectrum systems use DSCP rewrite map to update DSCP field in egressing
      packets to correspond to priority that the packet has. Whether rewriting
      will take place is determined at the point when the packet ingresses the
      switch: if the port is in Trust L3 mode, packet priority is determined from
      the DSCP map at the port, and DSCP rewrite will happen. If the port is in
      Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
      rewrite will happen.
      
      The driver determines the port trust mode based on whether any DSCP
      prioritization rules are in effect at given port. If there are any, trust
      level is L3, otherwise it's L2. When the last DSCP rule is removed, the
      port is switched to trust L2. Under that scenario, if DSCP of a packet
      should be rewritten, it should be rewritten to 0.
      
      However, when switching to Trust L2, the driver neglects to also update the
      DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
      egressing through this port, if they have the right priority, will have
      their DSCP set according to this rule.
      
      Fix by first configuring the rewrite map, and only then switching to trust
      L2 and bailing out.
      
      Fixes: b2b1dab6 ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Reported-by: default avatarAlex Veber <alexve@mellanox.com>
      Tested-by: default avatarAlex Veber <alexve@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dedfde2f
    • Rosen Penev's avatar
      net: ag71xx: Add missing header · a6574227
      Rosen Penev authored
      ag71xx uses devm_ioremap_nocache. This fixes usage of an implicit function
      
      Fixes: d51b6ce4 ("net: ethernet: add ag71xx driver")
      Signed-off-by: default avatarRosen Penev <rosenp@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6574227