1. 30 May, 2020 1 commit
  2. 29 May, 2020 16 commits
    • Hangbin Liu's avatar
      neigh: fix ARP retransmit timer guard · 96d10d5b
      Hangbin Liu authored
      In commit 19e16d22 ("neigh: support smaller retrans_time settting")
      we add more accurate control for ARP and NS. But for ARP I forgot to
      update the latest guard in neigh_timer_handler(), then the next
      retransmit would be reset to jiffies + HZ/2 if we set the retrans_time
      less than 500ms. Fix it by setting the time_before() check to HZ/100.
      
      IPv6 does not have this issue.
      Reported-by: default avatarJianwen Ji <jiji@redhat.com>
      Fixes: 19e16d22 ("neigh: support smaller retrans_time settting")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96d10d5b
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2020-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · f2b122d3
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2020-05-28
      
      This series introduces some fixes to mlx5 driver.
      
      v1->v2:
       - Fix bad sha1, Jakub.
       - Added one more patch by Pablo.
         net/mlx5e: replace EINVAL in mlx5e_flower_parse_meta()
      
      Nothing major, the only patch worth mentioning is the suspend/resume crash
      fix by adding the missing pci device handlers, the fix is very straight
      forward and as Dexuan already expressed, the patch is important for Azure
      users to avoid crash on VM hibernation, patch is marked for -stable v4.6
      below.
      
      Conflict note:
      ('net/mlx5e: Fix MLX5_TC_CT dependencies') has a trivial one line conflict
      with current net-next, which can be resolved by simply using the line from
      net-next.
      
      Please pull and let me know if there is any problem.
      
      For -stable v4.6
       ('net/mlx5: Fix crash upon suspend/resume')
      
      For -stable v5.6
       ('net/mlx5e: replace EINVAL in mlx5e_flower_parse_meta()')
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2b122d3
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · f9e0ce3d
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2020-05-29
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 6 non-merge commits during the last 7 day(s) which contain
      a total of 4 files changed, 55 insertions(+), 34 deletions(-).
      
      The main changes are:
      
      1) minor verifier fix for fmod_ret progs, from Alexei.
      
      2) af_xdp overflow check, from Bjorn.
      
      3) minor verifier fix for 32bit assignment, from John.
      
      4) powerpc has non-overlapping addr space, from Petr.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9e0ce3d
    • John Fastabend's avatar
      bpf, selftests: Add a verifier test for assigning 32bit reg states to 64bit ones · cf66c29b
      John Fastabend authored
      Added a verifier test for assigning 32bit reg states to
      64bit where 32bit reg holds a constant value of 0.
      
      Without previous kernel verifier.c fix, the test in
      this patch will fail.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/159077335867.6014.2075350327073125374.stgit@john-Precision-5820-Tower
      cf66c29b
    • John Fastabend's avatar
      bpf, selftests: Verifier bounds tests need to be updated · e3effcdf
      John Fastabend authored
      After previous fix for zero extension test_verifier tests #65 and #66 now
      fail. Before the fix we can see the alu32 mov op at insn 10
      
      10: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=invP(id=0,
                    smin_value=4294967168,smax_value=4294967423,
                    umin_value=4294967168,umax_value=4294967423,
                    var_off=(0x0; 0x1ffffffff),
                    s32_min_value=-2147483648,s32_max_value=2147483647,
                    u32_min_value=0,u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      10: (bc) w1 = w1
      11: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=invP(id=0,
                    smin_value=0,smax_value=2147483647,
                    umin_value=0,umax_value=4294967295,
                    var_off=(0x0; 0xffffffff),
                    s32_min_value=-2147483648,s32_max_value=2147483647,
                    u32_min_value=0,u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      
      After the fix at insn 10 because we have 's32_min_value < 0' the following
      step 11 now has 'smax_value=U32_MAX' where before we pulled the s32_max_value
      bound into the smax_value as seen above in 11 with smax_value=2147483647.
      
      10: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=inv(id=0,
                   smin_value=4294967168,smax_value=4294967423,
                   umin_value=4294967168,umax_value=4294967423,
                   var_off=(0x0; 0x1ffffffff),
                   s32_min_value=-2147483648, s32_max_value=2147483647,
                   u32_min_value=0,u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      10: (bc) w1 = w1
      11: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=inv(id=0,
                   smin_value=0,smax_value=4294967295,
                   umin_value=0,umax_value=4294967295,
                   var_off=(0x0; 0xffffffff),
                   s32_min_value=-2147483648, s32_max_value=2147483647,
                   u32_min_value=0, u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      
      The fall out of this is by the time we get to the failing instruction at
      step 14 where previously we had the following:
      
      14: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=inv(id=0,
                   smin_value=72057594021150720,smax_value=72057594029539328,
                   umin_value=72057594021150720,umax_value=72057594029539328,
                   var_off=(0xffffffff000000; 0xffffff),
                   s32_min_value=-16777216,s32_max_value=-1,
                   u32_min_value=-16777216,u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      14: (0f) r0 += r1
      
      We now have,
      
      14: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=inv(id=0,
                   smin_value=0,smax_value=72057594037927935,
                   umin_value=0,umax_value=72057594037927935,
                   var_off=(0x0; 0xffffffffffffff),
                   s32_min_value=-2147483648,s32_max_value=2147483647,
                   u32_min_value=0,u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      14: (0f) r0 += r1
      
      In the original step 14 'smin_value=72057594021150720' this trips the logic
      in the verifier function check_reg_sane_offset(),
      
       if (smin >= BPF_MAX_VAR_OFF || smin <= -BPF_MAX_VAR_OFF) {
      	verbose(env, "value %lld makes %s pointer be out of bounds\n",
      		smin, reg_type_str[type]);
      	return false;
       }
      
      Specifically, the 'smin <= -BPF_MAX_VAR_OFF' check. But with the fix
      at step 14 we have bounds 'smin_value=0' so the above check is not tripped
      because BPF_MAX_VAR_OFF=1<<29.
      
      We have a smin_value=0 here because at step 10 the smaller smin_value=0 means
      the subtractions at steps 11 and 12 bring the smin_value negative.
      
      11: (17) r1 -= 2147483584
      12: (17) r1 -= 2147483584
      13: (77) r1 >>= 8
      
      Then the shift clears the top bit and smin_value is set to 0. Note we still
      have the smax_value in the fixed code so any reads will fail. An alternative
      would be to have reg_sane_check() do both smin and smax value tests.
      
      To fix the test we can omit the 'r1 >>=8' at line 13. This will change the
      err string, but keeps the intention of the test as suggseted by the title,
      "check after truncation of boundary-crossing range". If the verifier logic
      changes a different value is likely to be thrown in the error or the error
      will no longer be thrown forcing this test to be examined. With this change
      we see the new state at step 13.
      
      13: R0_w=map_value(id=0,off=0,ks=8,vs=8,imm=0)
          R1_w=invP(id=0,
                    smin_value=-4294967168,smax_value=127,
                    umin_value=0,umax_value=18446744073709551615,
                    s32_min_value=-2147483648,s32_max_value=2147483647,
                    u32_min_value=0,u32_max_value=-1)
          R10=fp0 fp-8_w=mmmmmmmm
      
      Giving the expected out of bounds error, "value -4294967168 makes map_value
      pointer be out of bounds" However, for unpriv case we see a different error
      now because of the mixed signed bounds pointer arithmatic. This seems OK so
      I've only added the unpriv_errstr for this. Another optino may have been to
      do addition on r1 instead of subtraction but I favor the approach above
      slightly.
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/159077333942.6014.14004320043595756079.stgit@john-Precision-5820-Tower
      e3effcdf
    • John Fastabend's avatar
      bpf: Fix a verifier issue when assigning 32bit reg states to 64bit ones · 3a71dc36
      John Fastabend authored
      With the latest trunk llvm (llvm 11), I hit a verifier issue for
      test_prog subtest test_verif_scale1.
      
      The following simplified example illustrate the issue:
          w9 = 0  /* R9_w=inv0 */
          r8 = *(u32 *)(r1 + 80)  /* __sk_buff->data_end */
          r7 = *(u32 *)(r1 + 76)  /* __sk_buff->data */
          ......
          w2 = w9 /* R2_w=inv0 */
          r6 = r7 /* R6_w=pkt(id=0,off=0,r=0,imm=0) */
          r6 += r2 /* R6_w=inv(id=0) */
          r3 = r6 /* R3_w=inv(id=0) */
          r3 += 14 /* R3_w=inv(id=0) */
          if r3 > r8 goto end
          r5 = *(u32 *)(r6 + 0) /* R6_w=inv(id=0) */
             <== error here: R6 invalid mem access 'inv'
          ...
        end:
      
      In real test_verif_scale1 code, "w9 = 0" and "w2 = w9" are in
      different basic blocks.
      
      In the above, after "r6 += r2", r6 becomes a scalar, which eventually
      caused the memory access error. The correct register state should be
      a pkt pointer.
      
      The inprecise register state starts at "w2 = w9".
      The 32bit register w9 is 0, in __reg_assign_32_into_64(),
      the 64bit reg->smax_value is assigned to be U32_MAX.
      The 64bit reg->smin_value is 0 and the 64bit register
      itself remains constant based on reg->var_off.
      
      In adjust_ptr_min_max_vals(), the verifier checks for a known constant,
      smin_val must be equal to smax_val. Since they are not equal,
      the verifier decides r6 is a unknown scalar, which caused later failure.
      
      The llvm10 does not have this issue as it generates different code:
          w9 = 0  /* R9_w=inv0 */
          r8 = *(u32 *)(r1 + 80)  /* __sk_buff->data_end */
          r7 = *(u32 *)(r1 + 76)  /* __sk_buff->data */
          ......
          r6 = r7 /* R6_w=pkt(id=0,off=0,r=0,imm=0) */
          r6 += r9 /* R6_w=pkt(id=0,off=0,r=0,imm=0) */
          r3 = r6 /* R3_w=pkt(id=0,off=0,r=0,imm=0) */
          r3 += 14 /* R3_w=pkt(id=0,off=14,r=0,imm=0) */
          if r3 > r8 goto end
          ...
      
      To fix the above issue, we can include zero in the test condition for
      assigning the s32_max_value and s32_min_value to their 64-bit equivalents
      smax_value and smin_value.
      
      Further, fix the condition to avoid doing zero extension bounds checks
      when s32_min_value <= 0. This could allow for the case where bounds
      32-bit bounds (-1,1) get incorrectly translated to (0,1) 64-bit bounds.
      When in-fact the -1 min value needs to force U32_MAX bound.
      
      Fixes: 3f50f132 ("bpf: Verifier, do explicit ALU32 bounds tracking")
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/159077331983.6014.5758956193749002737.stgit@john-Precision-5820-Tower
      3a71dc36
    • Alexei Starovoitov's avatar
      bpf: Fix use-after-free in fmod_ret check · 18644cec
      Alexei Starovoitov authored
      Fix the following issue:
      [  436.749342] BUG: KASAN: use-after-free in bpf_trampoline_put+0x39/0x2a0
      [  436.749995] Write of size 4 at addr ffff8881ef38b8a0 by task kworker/3:5/2243
      [  436.750712]
      [  436.752677] Workqueue: events bpf_prog_free_deferred
      [  436.753183] Call Trace:
      [  436.756483]  bpf_trampoline_put+0x39/0x2a0
      [  436.756904]  bpf_prog_free_deferred+0x16d/0x3d0
      [  436.757377]  process_one_work+0x94a/0x15b0
      [  436.761969]
      [  436.762130] Allocated by task 2529:
      [  436.763323]  bpf_trampoline_lookup+0x136/0x540
      [  436.763776]  bpf_check+0x2872/0xa0a8
      [  436.764144]  bpf_prog_load+0xb6f/0x1350
      [  436.764539]  __do_sys_bpf+0x16d7/0x3720
      [  436.765825]
      [  436.765988] Freed by task 2529:
      [  436.767084]  kfree+0xc6/0x280
      [  436.767397]  bpf_trampoline_put+0x1fd/0x2a0
      [  436.767826]  bpf_check+0x6832/0xa0a8
      [  436.768197]  bpf_prog_load+0xb6f/0x1350
      [  436.768594]  __do_sys_bpf+0x16d7/0x3720
      
      prog->aux->trampoline = tr should be set only when prog is valid.
      Otherwise prog freeing will try to put trampoline via prog->aux->trampoline,
      but it may not point to a valid trampoline.
      
      Fixes: 6ba43b76 ("bpf: Attachment verification for BPF_MODIFY_RETURN")
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarKP Singh <kpsingh@google.com>
      Link: https://lore.kernel.org/bpf/20200529043839.15824-2-alexei.starovoitov@gmail.com
      18644cec
    • Pablo Neira Ayuso's avatar
      net/mlx5e: replace EINVAL in mlx5e_flower_parse_meta() · a683012a
      Pablo Neira Ayuso authored
      The drivers reports EINVAL to userspace through netlink on invalid meta
      match. This is confusing since EINVAL is usually reserved for malformed
      netlink messages. Replace it by more meaningful codes.
      
      Fixes: 6d65bc64 ("net/mlx5e: Add mlx5e_flower_parse_meta support")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      a683012a
    • Vlad Buslov's avatar
      net/mlx5e: Fix MLX5_TC_CT dependencies · cb9a0641
      Vlad Buslov authored
      Change MLX5_TC_CT config dependencies to include MLX5_ESWITCH instead of
      MLX5_CORE_EN && NET_SWITCHDEV, which are already required by MLX5_ESWITCH.
      Without this change mlx5 fails to compile if user disables MLX5_ESWITCH
      without also manually disabling MLX5_TC_CT.
      
      Fixes: 4c3844d9 ("net/mlx5e: CT: Introduce connection tracking")
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Reviewed-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      cb9a0641
    • Tal Gilboa's avatar
      net/mlx5e: Properly set default values when disabling adaptive moderation · ebeaf084
      Tal Gilboa authored
      Add a call to mlx5e_reset_rx/tx_moderation() when enabling/disabling
      adaptive moderation, in order to select the proper default values.
      
      In order to do so, we separate the logic of selecting the moderation values
      and setting moderion mode (CQE/EQE based).
      
      Fixes: 0088cbbc ("net/mlx5e: Enable CQE based moderation on TX CQ")
      Fixes: 9908aa29 ("net/mlx5e: CQE based moderation")
      Signed-off-by: default avatarTal Gilboa <talgi@mellanox.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      ebeaf084
    • Aya Levin's avatar
      net/mlx5e: Fix arch depending casting issue in FEC · b623603b
      Aya Levin authored
      Change type of active_fec to u32 to match the type expected by
      mlx5e_get_fec_mode. Copy active_fec and configured_fec values to
      unsigned long before preforming bitwise manipulations.
      Take the same approach when configuring FEC over 50G link modes: copy
      the policy into an unsigned long and only than preform bitwise
      operations.
      
      Fixes: 2132b71f ("net/mlx5e: Advertise globaly supported FEC modes")
      Signed-off-by: default avatarAya Levin <ayal@mellanox.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      b623603b
    • Maor Dickman's avatar
      net/mlx5e: Remove warning "devices are not on same switch HW" · 20300aaf
      Maor Dickman authored
      On tunnel decap rule insertion, the indirect mechanism will attempt to
      offload the rule on all uplink representors which will trigger the
      "devices are not on same switch HW, can't offload forwarding" message
      for the uplink which isn't on the same switch HW as the VF representor.
      
      The above flow is valid and shouldn't cause warning message,
      fix by removing the warning and only report this flow using extack.
      
      Fixes: 32134847 ("net/mlx5e: Fix allowed tc redirect merged eswitch offload cases")
      Signed-off-by: default avatarMaor Dickman <maord@mellanox.com>
      Reviewed-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      20300aaf
    • Roi Dayan's avatar
      net/mlx5e: Fix stats update for matchall classifier · 0a2a6f49
      Roi Dayan authored
      It's bytes, packets, lastused.
      
      Fixes: fcb64c0f ("net/mlx5: E-Switch, add ingress rate support")
      Signed-off-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      0a2a6f49
    • Mark Bloch's avatar
      net/mlx5: Fix crash upon suspend/resume · 8fc3e29b
      Mark Bloch authored
      Currently a Linux system with the mlx5 NIC always crashes upon
      hibernation - suspend/resume.
      
      Add basic callbacks so the NIC could be suspended and resumed.
      
      Fixes: 9603b61d ("mlx5: Move pci device handling from mlx5_ib to mlx5_core")
      Tested-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarMark Bloch <markb@mellanox.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      8fc3e29b
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 942110fd
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2020-05-29
      
      1) Several fixes for ESP gro/gso in transport and beet mode when
         IPv6 extension headers are present. From Xin Long.
      
      2) Fix a wrong comment on XFRMA_OFFLOAD_DEV.
         From Antony Antony.
      
      3) Fix sk_destruct callback handling on ESP in TCP encapsulation.
         From Sabrina Dubroca.
      
      4) Fix a use after free in xfrm_output_gso when used with vxlan.
         From Xin Long.
      
      5) Fix secpath handling of VTI when used wiuth IPCOMP.
         From Xin Long.
      
      6) Fix an oops when deleting a x-netns xfrm interface.
         From Nicolas Dichtel.
      
      7) Fix a possible warning on policy updates. We had a case where it was
         possible to add two policies with the same lookup keys.
         From Xin Long.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      942110fd
    • Xin Long's avatar
      xfrm: fix a NULL-ptr deref in xfrm_local_error · f6a23d85
      Xin Long authored
      This patch is to fix a crash:
      
        [ ] kasan: GPF could be caused by NULL-ptr deref or user memory access
        [ ] general protection fault: 0000 [#1] SMP KASAN PTI
        [ ] RIP: 0010:ipv6_local_error+0xac/0x7a0
        [ ] Call Trace:
        [ ]  xfrm6_local_error+0x1eb/0x300
        [ ]  xfrm_local_error+0x95/0x130
        [ ]  __xfrm6_output+0x65f/0xb50
        [ ]  xfrm6_output+0x106/0x46f
        [ ]  udp_tunnel6_xmit_skb+0x618/0xbf0 [ip6_udp_tunnel]
        [ ]  vxlan_xmit_one+0xbc6/0x2c60 [vxlan]
        [ ]  vxlan_xmit+0x6a0/0x4276 [vxlan]
        [ ]  dev_hard_start_xmit+0x165/0x820
        [ ]  __dev_queue_xmit+0x1ff0/0x2b90
        [ ]  ip_finish_output2+0xd3e/0x1480
        [ ]  ip_do_fragment+0x182d/0x2210
        [ ]  ip_output+0x1d0/0x510
        [ ]  ip_send_skb+0x37/0xa0
        [ ]  raw_sendmsg+0x1b4c/0x2b80
        [ ]  sock_sendmsg+0xc0/0x110
      
      This occurred when sending a v4 skb over vxlan6 over ipsec, in which case
      skb->protocol == htons(ETH_P_IPV6) while skb->sk->sk_family == AF_INET in
      xfrm_local_error(). Then it will go to xfrm6_local_error() where it tries
      to get ipv6 info from a ipv4 sk.
      
      This issue was actually fixed by Commit 628e341f ("xfrm: make local
      error reporting more robust"), but brought back by Commit 844d4874
      ("xfrm: choose protocol family by skb protocol").
      
      So to fix it, we should call xfrm6_local_error() only when skb->protocol
      is htons(ETH_P_IPV6) and skb->sk->sk_family is AF_INET6.
      
      Fixes: 844d4874 ("xfrm: choose protocol family by skb protocol")
      Reported-by: default avatarXiumei Mu <xmu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      f6a23d85
  3. 28 May, 2020 5 commits
  4. 27 May, 2020 18 commits
    • Vladimir Oltean's avatar
      net: dsa: declare lockless TX feature for slave ports · 2b86cb82
      Vladimir Oltean authored
      Be there a platform with the following layout:
      
            Regular NIC
             |
             +----> DSA master for switch port
                     |
                     +----> DSA master for another switch port
      
      After changing DSA back to static lockdep class keys in commit
      1a33e10e ("net: partially revert dynamic lockdep key changes"), this
      kernel splat can be seen:
      
      [   13.361198] ============================================
      [   13.366524] WARNING: possible recursive locking detected
      [   13.371851] 5.7.0-rc4-02121-gc32a05ecd7af-dirty #988 Not tainted
      [   13.377874] --------------------------------------------
      [   13.383201] swapper/0/0 is trying to acquire lock:
      [   13.388004] ffff0000668ff298 (&dsa_slave_netdev_xmit_lock_key){+.-.}-{2:2}, at: __dev_queue_xmit+0x84c/0xbe0
      [   13.397879]
      [   13.397879] but task is already holding lock:
      [   13.403727] ffff0000661a1698 (&dsa_slave_netdev_xmit_lock_key){+.-.}-{2:2}, at: __dev_queue_xmit+0x84c/0xbe0
      [   13.413593]
      [   13.413593] other info that might help us debug this:
      [   13.420140]  Possible unsafe locking scenario:
      [   13.420140]
      [   13.426075]        CPU0
      [   13.428523]        ----
      [   13.430969]   lock(&dsa_slave_netdev_xmit_lock_key);
      [   13.435946]   lock(&dsa_slave_netdev_xmit_lock_key);
      [   13.440924]
      [   13.440924]  *** DEADLOCK ***
      [   13.440924]
      [   13.446860]  May be due to missing lock nesting notation
      [   13.446860]
      [   13.453668] 6 locks held by swapper/0/0:
      [   13.457598]  #0: ffff800010003de0 ((&idev->mc_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x0/0x400
      [   13.466593]  #1: ffffd4d3fb478700 (rcu_read_lock){....}-{1:2}, at: mld_sendpack+0x0/0x560
      [   13.474803]  #2: ffffd4d3fb478728 (rcu_read_lock_bh){....}-{1:2}, at: ip6_finish_output2+0x64/0xb10
      [   13.483886]  #3: ffffd4d3fb478728 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x6c/0xbe0
      [   13.492793]  #4: ffff0000661a1698 (&dsa_slave_netdev_xmit_lock_key){+.-.}-{2:2}, at: __dev_queue_xmit+0x84c/0xbe0
      [   13.503094]  #5: ffffd4d3fb478728 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x6c/0xbe0
      [   13.512000]
      [   13.512000] stack backtrace:
      [   13.516369] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc4-02121-gc32a05ecd7af-dirty #988
      [   13.530421] Call trace:
      [   13.532871]  dump_backtrace+0x0/0x1d8
      [   13.536539]  show_stack+0x24/0x30
      [   13.539862]  dump_stack+0xe8/0x150
      [   13.543271]  __lock_acquire+0x1030/0x1678
      [   13.547290]  lock_acquire+0xf8/0x458
      [   13.550873]  _raw_spin_lock+0x44/0x58
      [   13.554543]  __dev_queue_xmit+0x84c/0xbe0
      [   13.558562]  dev_queue_xmit+0x24/0x30
      [   13.562232]  dsa_slave_xmit+0xe0/0x128
      [   13.565988]  dev_hard_start_xmit+0xf4/0x448
      [   13.570182]  __dev_queue_xmit+0x808/0xbe0
      [   13.574200]  dev_queue_xmit+0x24/0x30
      [   13.577869]  neigh_resolve_output+0x15c/0x220
      [   13.582237]  ip6_finish_output2+0x244/0xb10
      [   13.586430]  __ip6_finish_output+0x1dc/0x298
      [   13.590709]  ip6_output+0x84/0x358
      [   13.594116]  mld_sendpack+0x2bc/0x560
      [   13.597786]  mld_ifc_timer_expire+0x210/0x390
      [   13.602153]  call_timer_fn+0xcc/0x400
      [   13.605822]  run_timer_softirq+0x588/0x6e0
      [   13.609927]  __do_softirq+0x118/0x590
      [   13.613597]  irq_exit+0x13c/0x148
      [   13.616918]  __handle_domain_irq+0x6c/0xc0
      [   13.621023]  gic_handle_irq+0x6c/0x160
      [   13.624779]  el1_irq+0xbc/0x180
      [   13.627927]  cpuidle_enter_state+0xb4/0x4d0
      [   13.632120]  cpuidle_enter+0x3c/0x50
      [   13.635703]  call_cpuidle+0x44/0x78
      [   13.639199]  do_idle+0x228/0x2c8
      [   13.642433]  cpu_startup_entry+0x2c/0x48
      [   13.646363]  rest_init+0x1ac/0x280
      [   13.649773]  arch_call_rest_init+0x14/0x1c
      [   13.653878]  start_kernel+0x490/0x4bc
      
      Lockdep keys themselves were added in commit ab92d68f ("net: core:
      add generic lockdep keys"), and it's very likely that this splat existed
      since then, but I have no real way to check, since this stacked platform
      wasn't supported by mainline back then.
      
      >From Taehee's own words:
      
        This patch was considered that all stackable devices have LLTX flag.
        But the dsa doesn't have LLTX, so this splat happened.
        After this patch, dsa shares the same lockdep class key.
        On the nested dsa interface architecture, which you illustrated,
        the same lockdep class key will be used in __dev_queue_xmit() because
        dsa doesn't have LLTX.
        So that lockdep detects deadlock because the same lockdep class key is
        used recursively although actually the different locks are used.
        There are some ways to fix this problem.
      
        1. using NETIF_F_LLTX flag.
        If possible, using the LLTX flag is a very clear way for it.
        But I'm so sorry I don't know whether the dsa could have LLTX or not.
      
        2. using dynamic lockdep again.
        It means that each interface uses a separate lockdep class key.
        So, lockdep will not detect recursive locking.
        But this way has a problem that it could consume lockdep class key
        too many.
        Currently, lockdep can have 8192 lockdep class keys.
         - you can see this number with the following command.
           cat /proc/lockdep_stats
           lock-classes:                         1251 [max: 8192]
           ...
           The [max: 8192] means that the maximum number of lockdep class keys.
        If too many lockdep class keys are registered, lockdep stops to work.
        So, using a dynamic(separated) lockdep class key should be considered
        carefully.
        In addition, updating lockdep class key routine might have to be existing.
        (lockdep_register_key(), lockdep_set_class(), lockdep_unregister_key())
      
        3. Using lockdep subclass.
        A lockdep class key could have 8 subclasses.
        The different subclass is considered different locks by lockdep
        infrastructure.
        But "lock-classes" is not counted by subclasses.
        So, it could avoid stopping lockdep infrastructure by an overflow of
        lockdep class keys.
        This approach should also have an updating lockdep class key routine.
        (lockdep_set_subclass())
      
        4. Using nonvalidate lockdep class key.
        The lockdep infrastructure supports nonvalidate lockdep class key type.
        It means this lockdep is not validated by lockdep infrastructure.
        So, the splat will not happen but lockdep couldn't detect real deadlock
        case because lockdep really doesn't validate it.
        I think this should be used for really special cases.
        (lockdep_set_novalidate_class())
      
      Further discussion here:
      https://patchwork.ozlabs.org/project/netdev/patch/20200503052220.4536-2-xiyou.wangcong@gmail.com/
      
      There appears to be no negative side-effect to declaring lockless TX for
      the DSA virtual interfaces, which means they handle their own locking.
      So that's what we do to make the splat go away.
      
      Patch tested in a wide variety of cases: unicast, multicast, PTP, etc.
      
      Fixes: ab92d68f ("net: core: add generic lockdep keys")
      Suggested-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b86cb82
    • Vladimir Oltean's avatar
      net: dsa: felix: send VLANs on CPU port as egress-tagged · 183be6f9
      Vladimir Oltean authored
      As explained in other commits before (b9cd75e6 and 87b0f983),
      ocelot switches have a single egress-untagged VLAN per port, and the
      driver would deny adding a second one while an egress-untagged VLAN
      already exists.
      
      But on the CPU port (where the VLAN configuration is implicit, because
      there is no net device for the bridge to control), the DSA core attempts
      to add a VLAN using the same flags as were used for the front-panel
      port. This would make adding any untagged VLAN fail due to the CPU port
      rejecting the configuration:
      
      bridge vlan add dev swp0 vid 100 pvid untagged
      [ 1865.854253] mscc_felix 0000:00:00.5: Port already has a native VLAN: 1
      [ 1865.860824] mscc_felix 0000:00:00.5: Failed to add VLAN 100 to port 5: -16
      
      (note that port 5 is the CPU port and not the front-panel swp0).
      
      So this hardware will send all VLANs as tagged towards the CPU.
      
      Fixes: 56051948 ("net: dsa: ocelot: add driver for Felix switch family")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      183be6f9
    • Arnd Bergmann's avatar
      bridge: multicast: work around clang bug · b3b6a84c
      Arnd Bergmann authored
      Clang-10 and clang-11 run into a corner case of the register
      allocator on 32-bit ARM, leading to excessive stack usage from
      register spilling:
      
      net/bridge/br_multicast.c:2422:6: error: stack frame size of 1472 bytes in function 'br_multicast_get_stats' [-Werror,-Wframe-larger-than=]
      
      Work around this by marking one of the internal functions as
      noinline_for_stack.
      
      Link: https://bugs.llvm.org/show_bug.cgi?id=45802#c9Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3b6a84c
    • Stefano Garzarella's avatar
      vsock: fix timeout in vsock_accept() · 7e0afbdf
      Stefano Garzarella authored
      The accept(2) is an "input" socket interface, so we should use
      SO_RCVTIMEO instead of SO_SNDTIMEO to set the timeout.
      
      So this patch replace sock_sndtimeo() with sock_rcvtimeo() to
      use the right timeout in the vsock_accept().
      
      Fixes: d021c344 ("VSOCK: Introduce VM Sockets")
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Reviewed-by: default avatarJorgen Hansen <jhansen@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e0afbdf
    • Heinrich Kuhn's avatar
      nfp: flower: fix used time of merge flow statistics · 5b186cd6
      Heinrich Kuhn authored
      Prior to this change the correct value for the used counter is calculated
      but not stored nor, therefore, propagated to user-space. In use-cases such
      as OVS use-case at least this results in active flows being removed from
      the hardware datapath. Which results in both unnecessary flow tear-down
      and setup, and packet processing on the host.
      
      This patch addresses the problem by saving the calculated used value
      which allows the value to propagate to user-space.
      
      Found by inspection.
      
      Fixes: aa6ce2ea ("nfp: flower: support stats update for merge flows")
      Signed-off-by: default avatarHeinrich Kuhn <heinrich.kuhn@netronome.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b186cd6
    • Davide Caratti's avatar
      net/sched: fix infinite loop in sch_fq_pie · bb2f930d
      Davide Caratti authored
      this command hangs forever:
      
       # tc qdisc add dev eth0 root fq_pie flows 65536
      
       watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [tc:1028]
       [...]
       CPU: 1 PID: 1028 Comm: tc Not tainted 5.7.0-rc6+ #167
       RIP: 0010:fq_pie_init+0x60e/0x8b7 [sch_fq_pie]
       Code: 4c 89 65 50 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 85 2a 02 00 00 48 8d 7d 10 4c 89 65 58 48 89 f8 48 c1 e8 03 42 80 3c 30 00 <0f> 85 a7 01 00 00 48 8d 7d 18 48 c7 45 10 46 c3 23 00 48 89 f8 48
       RSP: 0018:ffff888138d67468 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: 1ffff9200018d2b2 RBX: ffff888139c1c400 RCX: ffffffffffffffff
       RDX: 000000000000c5e8 RSI: ffffc900000e5000 RDI: ffffc90000c69590
       RBP: ffffc90000c69580 R08: fffffbfff79a9699 R09: fffffbfff79a9699
       R10: 0000000000000700 R11: fffffbfff79a9698 R12: ffffc90000c695d0
       R13: 0000000000000000 R14: dffffc0000000000 R15: 000000002347c5e8
       FS:  00007f01e1850e40(0000) GS:ffff88814c880000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 000000000067c340 CR3: 000000013864c000 CR4: 0000000000340ee0
       Call Trace:
        qdisc_create+0x3fd/0xeb0
        tc_modify_qdisc+0x3be/0x14a0
        rtnetlink_rcv_msg+0x5f3/0x920
        netlink_rcv_skb+0x121/0x350
        netlink_unicast+0x439/0x630
        netlink_sendmsg+0x714/0xbf0
        sock_sendmsg+0xe2/0x110
        ____sys_sendmsg+0x5b4/0x890
        ___sys_sendmsg+0xe9/0x160
        __sys_sendmsg+0xd3/0x170
        do_syscall_64+0x9a/0x370
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      we can't accept 65536 as a valid number for 'nflows', because the loop on
      'idx' in fq_pie_init() will never end. The extack message is correct, but
      it doesn't say that 0 is not a valid number for 'flows': while at it, fix
      this also. Add a tdc selftest to check correct validation of 'flows'.
      
      CC: Ivan Vecera <ivecera@redhat.com>
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Reviewed-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb2f930d
    • Pablo Neira Ayuso's avatar
      netfilter: nf_conntrack_pptp: fix compilation warning with W=1 build · 4946ea5c
      Pablo Neira Ayuso authored
      >> include/linux/netfilter/nf_conntrack_pptp.h:13:20: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
      extern const char *const pptp_msg_name(u_int16_t msg);
      ^~~~~~
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Fixes: 4c559f15 ("netfilter: nf_conntrack_pptp: prevent buffer overflows in debug code")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      4946ea5c
    • Pablo Neira Ayuso's avatar
      netfilter: conntrack: comparison of unsigned in cthelper confirmation · 94945ad2
      Pablo Neira Ayuso authored
      net/netfilter/nf_conntrack_core.c: In function nf_confirm_cthelper:
      net/netfilter/nf_conntrack_core.c:2117:15: warning: comparison of unsigned expression in < 0 is always false [-Wtype-limits]
       2117 |   if (protoff < 0 || (frag_off & htons(~0x7)) != 0)
            |               ^
      
      ipv6_skip_exthdr() returns a signed integer.
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Fixes: 703acd70 ("netfilter: nfnetlink_cthelper: unbreak userspace helper support")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      94945ad2
    • Nathan Chancellor's avatar
      netfilter: conntrack: Pass value of ctinfo to __nf_conntrack_update · 46c1e062
      Nathan Chancellor authored
      Clang warns:
      
      net/netfilter/nf_conntrack_core.c:2068:21: warning: variable 'ctinfo' is
      uninitialized when used here [-Wuninitialized]
              nf_ct_set(skb, ct, ctinfo);
                                 ^~~~~~
      net/netfilter/nf_conntrack_core.c:2024:2: note: variable 'ctinfo' is
      declared here
              enum ip_conntrack_info ctinfo;
              ^
      1 warning generated.
      
      nf_conntrack_update was split up into nf_conntrack_update and
      __nf_conntrack_update, where the assignment of ctinfo is in
      nf_conntrack_update but it is used in __nf_conntrack_update.
      
      Pass the value of ctinfo from nf_conntrack_update to
      __nf_conntrack_update so that uninitialized memory is not used
      and everything works properly.
      
      Fixes: ee04805f ("netfilter: conntrack: make conntrack userspace helpers work again")
      Link: https://github.com/ClangBuiltLinux/linux/issues/1039Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      46c1e062
    • Eric Dumazet's avatar
      crypto: chelsio/chtls: properly set tp->lsndtime · a4976a3e
      Eric Dumazet authored
      TCP tp->lsndtime unit/base is tcp_jiffies32, not tcp_time_stamp()
      
      Fixes: 36bedb3f ("crypto: chtls - Inline TLS record Tx")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Ayush Sawal <ayush.sawal@chelsio.com>
      Cc: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4976a3e
    • Chris Packham's avatar
      net: sctp: Fix spelling in Kconfig help · 9a233d32
      Chris Packham authored
      Change 'handeled' to 'handled' in the Kconfig help for SCTP.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a233d32
    • David S. Miller's avatar
      Merge branch 'bnxt_en-Bug-fixes' · 09cb9f26
      David S. Miller authored
      Michael Chan says:
      
      ====================
      bnxt_en: Bug fixes.
      
      3 bnxt_en driver fixes, covering a bug in preserving the counters during
      some resets, proper error code when flashing NVRAM fails, and an
      endian bug when extracting the firmware response message length.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09cb9f26
    • Edwin Peer's avatar
      bnxt_en: fix firmware message length endianness · 2a5a8800
      Edwin Peer authored
      The explicit mask and shift is not the appropriate way to parse fields
      out of a little endian struct. The length field is internally __le16
      and the strategy employed only happens to work on little endian machines
      because the offset used is actually incorrect (length is at offset 6).
      
      Also remove the related and no longer used definitions from bnxt.h.
      
      Fixes: 845adfe4 ("bnxt_en: Improve valid bit checking in firmware response message.")
      Signed-off-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a5a8800
    • Vasundhara Volam's avatar
      bnxt_en: Fix return code to "flash_device". · 95ec1f47
      Vasundhara Volam authored
      When NVRAM directory is not found, return the error code
      properly as per firmware command failure instead of the hardcode
      -ENOBUFS.
      
      Fixes: 3a707bed ("bnxt_en: Return -EAGAIN if fw command returns BUSY")
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95ec1f47
    • Michael Chan's avatar
      bnxt_en: Fix accumulation of bp->net_stats_prev. · b8056e84
      Michael Chan authored
      We have logic to maintain network counters across resets by storing
      the counters in bp->net_stats_prev before reset.  But not all resets
      will clear the counters.  Certain resets that don't need to change
      the number of rings do not clear the counters.  The current logic
      accumulates the counters before all resets, causing big jumps in
      the counters after some resets, such as ethtool -G.
      
      Fix it by only accumulating the counters during reset if the irq_re_init
      parameter is set.  The parameter signifies that all rings and interrupts
      will be reset and that means that the counters will also be reset.
      Reported-by: default avatarVijayendra Suman <vijayendra.suman@oracle.com>
      Fixes: b8875ca3 ("bnxt_en: Save ring statistics before reset.")
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8056e84
    • Daniele Palmas's avatar
      net: usb: qmi_wwan: add Telit LE910C1-EUX composition · 591612aa
      Daniele Palmas authored
      Add support for Telit LE910C1-EUX composition
      
      0x1031: tty, tty, tty, rmnet
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      591612aa
    • Willem de Bruijn's avatar
      net: check untrusted gso_size at kernel entry · 6dd912f8
      Willem de Bruijn authored
      Syzkaller again found a path to a kernel crash through bad gso input:
      a packet with gso size exceeding len.
      
      These packets are dropped in tcp_gso_segment and udp[46]_ufo_fragment.
      But they may affect gso size calculations earlier in the path.
      
      Now that we have thlen as of commit 9274124f ("net: stricter
      validation of untrusted gso packets"), check gso_size at entry too.
      
      Fixes: bfd5f4a3 ("packet: Add GSO/csum offload support.")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6dd912f8
    • Paolo Abeni's avatar
      mptcp: avoid NULL-ptr derefence on fallback · 0a82e230
      Paolo Abeni authored
      In the MPTCP receive path we must cope with TCP fallback
      on blocking recvmsg(). Currently in such code path we detect
      the fallback condition, but we don't fetch the struct socket
      required for fallback.
      
      The above allowed syzkaller to trigger a NULL pointer
      dereference:
      
      general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
      CPU: 1 PID: 7226 Comm: syz-executor523 Not tainted 5.7.0-rc6-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:sock_recvmsg_nosec net/socket.c:886 [inline]
      RIP: 0010:sock_recvmsg+0x92/0x110 net/socket.c:904
      Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 44 89 6c 24 04 e8 53 18 1d fb 4d 8d 6f 20 4c 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 ef e8 20 12 5b fb bd a0 00 00 00 49 03 6d
      RSP: 0018:ffffc90001077b98 EFLAGS: 00010202
      RAX: 0000000000000004 RBX: ffffc90001077dc0 RCX: dffffc0000000000
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: 0000000000000000 R08: ffffffff86565e59 R09: ffffed10115afeaa
      R10: ffffed10115afeaa R11: 0000000000000000 R12: 1ffff9200020efbc
      R13: 0000000000000020 R14: ffffc90001077de0 R15: 0000000000000000
      FS:  00007fc6a3abe700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004d0050 CR3: 00000000969f0000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       mptcp_recvmsg+0x18d5/0x19b0 net/mptcp/protocol.c:891
       inet_recvmsg+0xf6/0x1d0 net/ipv4/af_inet.c:838
       sock_recvmsg_nosec net/socket.c:886 [inline]
       sock_recvmsg net/socket.c:904 [inline]
       __sys_recvfrom+0x2f3/0x470 net/socket.c:2057
       __do_sys_recvfrom net/socket.c:2075 [inline]
       __se_sys_recvfrom net/socket.c:2071 [inline]
       __x64_sys_recvfrom+0xda/0xf0 net/socket.c:2071
       do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      Address the issue initializing the struct socket reference
      before entering the fallback code.
      
      Reported-and-tested-by: syzbot+c6bfc3db991edc918432@syzkaller.appspotmail.com
      Suggested-by: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Fixes: 8ab183de ("mptcp: cope with later TCP fallback")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a82e230