1. 29 May, 2019 15 commits
    • Huazhong Tan's avatar
      net: hns3: use HCLGE_STATE_ROCE_REGISTERED to indicate PF ROCE client has registered · 2a0bfc36
      Huazhong Tan authored
      When PF ROCE client's init_instance() succeeds, it means this client
      has been registered successfully, so we use HCLGE_STATE_ROCE_REGISTERED
      to indicate that. And before calling PF ROCE client's uninit_instance(),
      we clear this state.
      
      So any operation of the ROCE client from HCLGE is not allowed if this
      state is not set.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a0bfc36
    • Huazhong Tan's avatar
      net: hns3: use HCLGE_STATE_NIC_REGISTERED to indicate PF NIC client has registered · bd9109c9
      Huazhong Tan authored
      When PF NIC client's init_instance() succeeds, it means this client
      has been registered successfully, so we use HCLGE_STATE_NIC_REGISTERED
      to indicate that. And before calling PF NIC client's uninit_instance(),
      we clear this state.
      
      So any operation of PF NIC client from HCLGE is not allowed if this
      state is not set.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd9109c9
    • Zhongzhu Liu's avatar
      net: hns3: add support for dump firmware statistics by debugfs · 33a90e2f
      Zhongzhu Liu authored
      This patch prints firmware statistics information.
      
      debugfs command:
      echo dump m7 info > cmd
      
      estuary:/dbg/hns3/0000:7d:00.0$ echo dump m7 info > cmd
      [  172.577240] hns3 0000:7d:00.0: 0x00000000  0x00000000  0x00000000
      [  172.583471] hns3 0000:7d:00.0: 0x00000000  0x00000000  0x00000000
      [  172.589552] hns3 0000:7d:00.0: 0x00000030  0x00000000  0x00000000
      [  172.595632] hns3 0000:7d:00.0: 0x00000000  0x00000000  0x00000000
      estuary:/dbg/hns3/0000:7d:00.0$
      Signed-off-by: default avatarZhongzhu Liu <liuzhongzhu@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33a90e2f
    • Yunsheng Lin's avatar
      net: hns3: fix for HNS3_RXD_GRO_SIZE_M macro · eff858c1
      Yunsheng Lin authored
      According to hardware user menual, the GRO_SIZE is 14 bits width,
      the HNS3_RXD_GRO_SIZE_M is 10 bits width now, which may cause
      hardware GRO received packet error problem.
      
      Fixes: a6d53b97 ("net: hns3: Adds GRO params to SKB for the stack")
      Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eff858c1
    • Jian Shen's avatar
      net: hns3: fix compile warning without CONFIG_RFS_ACCEL · 4c152276
      Jian Shen authored
      The ifdef condition of function hclge_add_fd_entry_by_arfs() is
      unnecessary. It may cause compile warning when CONFIG_RFS_ACCEL
      is not chosen. This patch fixes it by removing the ifdef condition.
      
      Fixes: d93ed94f ("net: hns3: add aRFS support for PF")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c152276
    • Xue Chaojing's avatar
      hinic: fix a bug in set rx mode · 66350023
      Xue Chaojing authored
      in set_rx_mode, __dev_mc_sync and netdev_for_each_mc_addr will
      repeatedly set the multicast mac address. so we delete this loop.
      Signed-off-by: default avatarXue Chaojing <xuechaojing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66350023
    • David S. Miller's avatar
      Merge branch 'inet-frags-followup' · 2e56571d
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      inet: frags: followup to 'inet-frags-avoid-possible-races-at-netns-dismantle'
      
      Latest patch series ('inet-frags-avoid-possible-races-at-netns-dismantle')
      brought another syzbot report shown in the third patch changelog.
      
      While fixing the issue, I had to call inet_frags_fini() later
      in IPv6 and ilowpan.
      
      Also I believe a completion is needed to ensure proper dismantle
      at module removal.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e56571d
    • Eric Dumazet's avatar
      inet: frags: fix use-after-free read in inet_frag_destroy_rcu · dc93f46b
      Eric Dumazet authored
      As caught by syzbot [1], the rcu grace period that is respected
      before fqdir_rwork_fn() proceeds and frees fqdir is not enough
      to prevent inet_frag_destroy_rcu() being run after the freeing.
      
      We need a proper rcu_barrier() synchronization to replace
      the one we had in inet_frags_fini()
      
      We also have to fix a potential problem at module removal :
      inet_frags_fini() needs to make sure that all queued work queues
      (fqdir_rwork_fn) have completed, otherwise we might
      call kmem_cache_destroy() too soon and get another use-after-free.
      
      [1]
      BUG: KASAN: use-after-free in inet_frag_destroy_rcu+0xd9/0xe0 net/ipv4/inet_fragment.c:201
      Read of size 8 at addr ffff88806ed47a18 by task swapper/1/0
      
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.2.0-rc1+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
       inet_frag_destroy_rcu+0xd9/0xe0 net/ipv4/inet_fragment.c:201
       __rcu_reclaim kernel/rcu/rcu.h:222 [inline]
       rcu_do_batch kernel/rcu/tree.c:2092 [inline]
       invoke_rcu_callbacks kernel/rcu/tree.c:2310 [inline]
       rcu_core+0xba5/0x1500 kernel/rcu/tree.c:2291
       __do_softirq+0x25c/0x94c kernel/softirq.c:293
       invoke_softirq kernel/softirq.c:374 [inline]
       irq_exit+0x180/0x1d0 kernel/softirq.c:414
       exiting_irq arch/x86/include/asm/apic.h:536 [inline]
       smp_apic_timer_interrupt+0x13b/0x550 arch/x86/kernel/apic/apic.c:1068
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806
       </IRQ>
      RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
      Code: ff ff 48 89 df e8 f2 95 8c fa eb 82 e9 07 00 00 00 0f 00 2d e4 45 4b 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d d4 45 4b 00 fb f4 <c3> 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 e8 8e 18 42 fa e8 99
      RSP: 0018:ffff8880a98e7d78 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
      RAX: 1ffffffff1164e11 RBX: ffff8880a98d4340 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000006 RDI: ffff8880a98d4bbc
      RBP: ffff8880a98e7da8 R08: ffff8880a98d4340 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
      R13: ffffffff88b27078 R14: 0000000000000001 R15: 0000000000000000
       arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:571
       default_idle_call+0x36/0x90 kernel/sched/idle.c:94
       cpuidle_idle_call kernel/sched/idle.c:154 [inline]
       do_idle+0x377/0x560 kernel/sched/idle.c:263
       cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:354
       start_secondary+0x34e/0x4c0 arch/x86/kernel/smpboot.c:267
       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
      
      Allocated by task 8877:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_kmalloc mm/kasan/common.c:489 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
       kmem_cache_alloc_trace+0x151/0x750 mm/slab.c:3555
       kmalloc include/linux/slab.h:547 [inline]
       kzalloc include/linux/slab.h:742 [inline]
       fqdir_init include/net/inet_frag.h:115 [inline]
       ipv6_frags_init_net+0x48/0x460 net/ipv6/reassembly.c:513
       ops_init+0xb3/0x410 net/core/net_namespace.c:130
       setup_net+0x2d3/0x740 net/core/net_namespace.c:316
       copy_net_ns+0x1df/0x340 net/core/net_namespace.c:439
       create_new_namespaces+0x400/0x7b0 kernel/nsproxy.c:107
       unshare_nsproxy_namespaces+0xc2/0x200 kernel/nsproxy.c:206
       ksys_unshare+0x440/0x980 kernel/fork.c:2692
       __do_sys_unshare kernel/fork.c:2760 [inline]
       __se_sys_unshare kernel/fork.c:2758 [inline]
       __x64_sys_unshare+0x31/0x40 kernel/fork.c:2758
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 17:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
       __cache_free mm/slab.c:3432 [inline]
       kfree+0xcf/0x220 mm/slab.c:3755
       fqdir_rwork_fn+0x33/0x40 net/ipv4/inet_fragment.c:154
       process_one_work+0x989/0x1790 kernel/workqueue.c:2269
       worker_thread+0x98/0xe40 kernel/workqueue.c:2415
       kthread+0x354/0x420 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      The buggy address belongs to the object at ffff88806ed47a00
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 24 bytes inside of
       512-byte region [ffff88806ed47a00, ffff88806ed47c00)
      The buggy address belongs to the page:
      page:ffffea0001bb51c0 refcount:1 mapcount:0 mapping:ffff8880aa400940 index:0x0
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea000282a788 ffffea0001bb53c8 ffff8880aa400940
      raw: 0000000000000000 ffff88806ed47000 0000000100000006 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88806ed47900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88806ed47980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88806ed47a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
       ffff88806ed47a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88806ed47b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 3c8fc878 ("inet: frags: rework rhashtable dismantle")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc93f46b
    • Eric Dumazet's avatar
      inet: frags: call inet_frags_fini() after unregister_pernet_subsys() · ae7352d3
      Eric Dumazet authored
      Both IPv6 and 6lowpan are calling inet_frags_fini() too soon.
      
      inet_frags_fini() is dismantling a kmem_cache, that might be needed
      later when unregister_pernet_subsys() eventually has to remove
      frags queues from hash tables and free them.
      
      This fixes potential use-after-free, and is a prereq for the following patch.
      
      Fixes: d4ad4d22 ("inet: frags: use kmem_cache for inet_frag_queue")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae7352d3
    • Eric Dumazet's avatar
      inet: frags: uninline fqdir_init() · 6b73d197
      Eric Dumazet authored
      fqdir_init() is not fast path and is getting bigger.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b73d197
    • Willem de Bruijn's avatar
      selftests/net: ipv6 flowlabel · 3fb321fd
      Willem de Bruijn authored
      Test the IPv6 flowlabel control and datapath interfaces:
      
      Acquire and release the right to use flowlabels with socket option
      IPV6_FLOWLABEL_MGR.
      
      Then configure flowlabels on send and read them on recv with cmsg
      IPV6_FLOWINFO. Also verify auto-flowlabel if not explicitly set.
      
      This helped identify the issue fixed in commit 95c16925 ("ipv6:
      invert flowlabel sharing check in process and user mode")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3fb321fd
    • Camelia Groza's avatar
      enetc: Enable TC offloading with mqprio · cbe9e835
      Camelia Groza authored
      Add support to configure multiple prioritized TX traffic
      classes with mqprio.
      
      Configure one BD ring per TC for the moment, one netdev
      queue per TC.
      Signed-off-by: default avatarCamelia Groza <camelia.groza@nxp.com>
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbe9e835
    • David S. Miller's avatar
      Merge branch 'stmmac-SPDX' · 7f334323
      David S. Miller authored
      Neil Armstrong says:
      
      ====================
      net: stmmac: dwmac-meson: update with SPDX Licence identifier
      
      Update the SPDX Licence identifier for the Amlogic Meson6 and Meson8 dwmac
      glue drivers.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f334323
    • Neil Armstrong's avatar
    • Neil Armstrong's avatar
  2. 28 May, 2019 2 commits
  3. 27 May, 2019 11 commits
  4. 26 May, 2019 12 commits
    • David S. Miller's avatar
      Merge branch 'inet-frags-avoid-possible-races-at-netns-dismantle' · 8fb91c35
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      inet: frags: avoid possible races at netns dismantle
      
      This patch series fixes a race happening on netns dismantle with
      frag queues. While rhashtable_free_and_destroy() is running,
      concurrent timers might run inet_frag_kill() and attempt
      rhashtable_remove_fast() calls. This is not allowed by
      rhashtable logic.
      
      Since I do not want to add expensive synchronize_rcu() calls
      in the netns dismantle path, I had to no longer inline
      netns_frags structures, but dynamically allocate them.
      
      The ten first patches make this preparation, so that
      the last patch clearly shows the fix.
      
      As this patch series is not exactly trivial, I chose to
      target 5.3. We will backport it once soaked a bit.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8fb91c35
    • Eric Dumazet's avatar
      inet: frags: rework rhashtable dismantle · 3c8fc878
      Eric Dumazet authored
      syszbot found an interesting use-after-free [1] happening
      while IPv4 fragment rhashtable was destroyed at netns dismantle.
      
      While no insertions can possibly happen at the time a dismantling
      netns is destroying this rhashtable, timers can still fire and
      attempt to remove elements from this rhashtable.
      
      This is forbidden, since rhashtable_free_and_destroy() has
      no synchronization against concurrent inserts and deletes.
      
      Add a new fqdir->dead flag so that timers do not attempt
      a rhashtable_remove_fast() operation.
      
      We also have to respect an RCU grace period before starting
      the rhashtable_free_and_destroy() from process context,
      thus we use rcu_work infrastructure.
      
      This is a refinement of a prior rough attempt to fix this bug :
      https://marc.info/?l=linux-netdev&m=153845936820900&w=2
      
      Since the rhashtable cleanup is now deferred to a work queue,
      netns dismantles should be slightly faster.
      
      [1]
      BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:194 [inline]
      BUG: KASAN: use-after-free in rhashtable_last_table+0x162/0x180 lib/rhashtable.c:212
      Read of size 8 at addr ffff8880a6497b70 by task kworker/0:0/5
      
      CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.2.0-rc1+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events rht_deferred_worker
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
       __read_once_size include/linux/compiler.h:194 [inline]
       rhashtable_last_table+0x162/0x180 lib/rhashtable.c:212
       rht_deferred_worker+0x111/0x2030 lib/rhashtable.c:411
       process_one_work+0x989/0x1790 kernel/workqueue.c:2269
       worker_thread+0x98/0xe40 kernel/workqueue.c:2415
       kthread+0x354/0x420 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Allocated by task 32687:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_kmalloc mm/kasan/common.c:489 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
       __do_kmalloc_node mm/slab.c:3620 [inline]
       __kmalloc_node+0x4e/0x70 mm/slab.c:3627
       kmalloc_node include/linux/slab.h:590 [inline]
       kvmalloc_node+0x68/0x100 mm/util.c:431
       kvmalloc include/linux/mm.h:637 [inline]
       kvzalloc include/linux/mm.h:645 [inline]
       bucket_table_alloc+0x90/0x480 lib/rhashtable.c:178
       rhashtable_init+0x3f4/0x7b0 lib/rhashtable.c:1057
       inet_frags_init_net include/net/inet_frag.h:109 [inline]
       ipv4_frags_init_net+0x182/0x410 net/ipv4/ip_fragment.c:683
       ops_init+0xb3/0x410 net/core/net_namespace.c:130
       setup_net+0x2d3/0x740 net/core/net_namespace.c:316
       copy_net_ns+0x1df/0x340 net/core/net_namespace.c:439
       create_new_namespaces+0x400/0x7b0 kernel/nsproxy.c:107
       unshare_nsproxy_namespaces+0xc2/0x200 kernel/nsproxy.c:206
       ksys_unshare+0x440/0x980 kernel/fork.c:2692
       __do_sys_unshare kernel/fork.c:2760 [inline]
       __se_sys_unshare kernel/fork.c:2758 [inline]
       __x64_sys_unshare+0x31/0x40 kernel/fork.c:2758
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 7:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
       __cache_free mm/slab.c:3432 [inline]
       kfree+0xcf/0x220 mm/slab.c:3755
       kvfree+0x61/0x70 mm/util.c:460
       bucket_table_free+0x69/0x150 lib/rhashtable.c:108
       rhashtable_free_and_destroy+0x165/0x8b0 lib/rhashtable.c:1155
       inet_frags_exit_net+0x3d/0x50 net/ipv4/inet_fragment.c:152
       ipv4_frags_exit_net+0x73/0x90 net/ipv4/ip_fragment.c:695
       ops_exit_list.isra.0+0xaa/0x150 net/core/net_namespace.c:154
       cleanup_net+0x3fb/0x960 net/core/net_namespace.c:553
       process_one_work+0x989/0x1790 kernel/workqueue.c:2269
       worker_thread+0x98/0xe40 kernel/workqueue.c:2415
       kthread+0x354/0x420 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      The buggy address belongs to the object at ffff8880a6497b40
       which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 48 bytes inside of
       1024-byte region [ffff8880a6497b40, ffff8880a6497f40)
      The buggy address belongs to the page:
      page:ffffea0002992580 refcount:1 mapcount:0 mapping:ffff8880aa400ac0 index:0xffff8880a64964c0 compound_mapcount: 0
      flags: 0x1fffc0000010200(slab|head)
      raw: 01fffc0000010200 ffffea0002916e88 ffffea000218fe08 ffff8880aa400ac0
      raw: ffff8880a64964c0 ffff8880a6496040 0000000100000005 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880a6497a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a6497a80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff8880a6497b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                                   ^
       ffff8880a6497b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a6497c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 648700f7 ("inet: frags: use rhashtables for reassembly units")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c8fc878
    • Eric Dumazet's avatar
      net: dynamically allocate fqdir structures · 4907abc6
      Eric Dumazet authored
      Following patch will add rcu grace period before fqdir
      rhashtable destruction, so we need to dynamically allocate
      fqdir structures to not force expensive synchronize_rcu() calls
      in netns dismantle path.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4907abc6
    • Eric Dumazet's avatar
      net: add a net pointer to struct fqdir · a39aca67
      Eric Dumazet authored
      fqdir will soon be dynamically allocated.
      
      We need to reach the struct net pointer from fqdir,
      so add it, and replace the various container_of() constructs
      by direct access to the new field.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a39aca67
    • Eric Dumazet's avatar
      net: rename inet_frags_init_net() to fdir_init() · 9cce45f2
      Eric Dumazet authored
      And pass an extra parameter, since we will soon
      dynamically allocate fqdir structures.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cce45f2
    • Eric Dumazet's avatar
      ieee820154: 6lowpan: no longer reference init_net in lowpan_frags_ns_ctl_table · d2dfd435
      Eric Dumazet authored
      (struct net *)->ieee802154_lowpan.fqdir will soon be a pointer, so make
      sure lowpan_frags_ns_ctl_table[] does not reference init_net.
      
      lowpan_frags_ns_sysctl_register() can perform the needed initialization
      for all netns.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2dfd435
    • Eric Dumazet's avatar
      netfilter: ipv6: nf_defrag: no longer reference init_net in nf_ct_frag6_sysctl_table · 3bb13dd4
      Eric Dumazet authored
      (struct net *)->nf_frag.fqdir will soon be a pointer, so make
      sure nf_ct_frag6_sysctl_table[] does not reference init_net.
      
      nf_ct_frag6_sysctl_register() can perform the needed initialization
      for all netns.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bb13dd4
    • Eric Dumazet's avatar
      ipv6: no longer reference init_net in ip6_frags_ns_ctl_table[] · 8668d0e2
      Eric Dumazet authored
      (struct net *)->ipv6.fqdir will soon be a pointer, so make
      sure ip6_frags_ns_ctl_table[] does not reference init_net.
      
      ip6_frags_ns_ctl_register() can perform the needed initialization
      for all netns.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8668d0e2
    • Eric Dumazet's avatar
      ipv4: no longer reference init_net in ip4_frags_ns_ctl_table[] · 8dfdb313
      Eric Dumazet authored
      (struct net *)->ipv4.fqdir will soon be a pointer, so make
      sure ip4_frags_ns_ctl_table[] does not reference init_net.
      
      ip4_frags_ns_ctl_register() can perform the needed initialization
      for all netns.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8dfdb313
    • Eric Dumazet's avatar
      net: rename struct fqdir fields · 803fdd99
      Eric Dumazet authored
      Rename the @frags fields from structs netns_ipv4, netns_ipv6,
      netns_nf_frag and netns_ieee802154_lowpan to @fqdir
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      803fdd99
    • Eric Dumazet's avatar
      89fb9005
    • Eric Dumazet's avatar
      inet: rename netns_frags to fqdir · 6ce3b4dc
      Eric Dumazet authored
      1) struct netns_frags is renamed to struct fqdir
        This structure is really holding many frag queues in a hash table.
      
      2) (struct inet_frag_queue)->net field is renamed to fqdir
        since net is generally associated to a 'struct net' pointer
        in networking stack.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ce3b4dc