1. 05 Sep, 2024 10 commits
    • Eric Dumazet's avatar
      ila: call nf_unregister_net_hooks() sooner · 031ae728
      Eric Dumazet authored
      syzbot found an use-after-free Read in ila_nf_input [1]
      
      Issue here is that ila_xlat_exit_net() frees the rhashtable,
      then call nf_unregister_net_hooks().
      
      It should be done in the reverse way, with a synchronize_rcu().
      
      This is a good match for a pre_exit() method.
      
      [1]
       BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
       BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
       BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]
       BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
      Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16
      
      CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
      Call Trace:
       <TASK>
        __dump_stack lib/dump_stack.c:93 [inline]
        dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
        print_address_description mm/kasan/report.c:377 [inline]
        print_report+0x169/0x550 mm/kasan/report.c:488
        kasan_report+0x143/0x180 mm/kasan/report.c:601
        rht_key_hashfn include/linux/rhashtable.h:159 [inline]
        __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
        rhashtable_lookup include/linux/rhashtable.h:646 [inline]
        rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
        ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]
        ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
        ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190
        nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
        nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
        nf_hook include/linux/netfilter.h:269 [inline]
        NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312
        __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
        __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775
        process_backlog+0x662/0x15b0 net/core/dev.c:6108
        __napi_poll+0xcb/0x490 net/core/dev.c:6772
        napi_poll net/core/dev.c:6841 [inline]
        net_rx_action+0x89b/0x1240 net/core/dev.c:6963
        handle_softirqs+0x2c4/0x970 kernel/softirq.c:554
        run_ksoftirqd+0xca/0x130 kernel/softirq.c:928
        smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164
        kthread+0x2f0/0x390 kernel/kthread.c:389
        ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
        ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
       </TASK>
      
      The buggy address belongs to the physical page:
      page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620
      flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
      page_type: 0xbfffffff(buddy)
      raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000
      raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000
      page dumped because: kasan: bad access detected
      page_owner tracks the page as freed
      page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187
        set_page_owner include/linux/page_owner.h:32 [inline]
        post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
        prep_new_page mm/page_alloc.c:1501 [inline]
        get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
        __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
        __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
        alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
        ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103
        __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130
        __do_kmalloc_node mm/slub.c:4146 [inline]
        __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164
        __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650
        bucket_table_alloc lib/rhashtable.c:186 [inline]
        rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071
        ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613
        ops_init+0x359/0x610 net/core/net_namespace.c:139
        setup_net+0x515/0xca0 net/core/net_namespace.c:343
        copy_net_ns+0x4e2/0x7b0 net/core/net_namespace.c:508
        create_new_namespaces+0x425/0x7b0 kernel/nsproxy.c:110
        unshare_nsproxy_namespaces+0x124/0x180 kernel/nsproxy.c:228
        ksys_unshare+0x619/0xc10 kernel/fork.c:3328
        __do_sys_unshare kernel/fork.c:3399 [inline]
        __se_sys_unshare kernel/fork.c:3397 [inline]
        __x64_sys_unshare+0x38/0x40 kernel/fork.c:3397
      page last free pid 11846 tgid 11846 stack trace:
        reset_page_owner include/linux/page_owner.h:25 [inline]
        free_pages_prepare mm/page_alloc.c:1094 [inline]
        free_unref_page+0xd22/0xea0 mm/page_alloc.c:2612
        __folio_put+0x2c8/0x440 mm/swap.c:128
        folio_put include/linux/mm.h:1486 [inline]
        free_large_kmalloc+0x105/0x1c0 mm/slub.c:4565
        kfree+0x1c4/0x360 mm/slub.c:4588
        rhashtable_free_and_destroy+0x7c6/0x920 lib/rhashtable.c:1169
        ila_xlat_exit_net+0x55/0x110 net/ipv6/ila/ila_xlat.c:626
        ops_exit_list net/core/net_namespace.c:173 [inline]
        cleanup_net+0x802/0xcc0 net/core/net_namespace.c:640
        process_one_work kernel/workqueue.c:3231 [inline]
        process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
        worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
        kthread+0x2f0/0x390 kernel/kthread.c:389
        ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
        ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
      
      Memory state around the buggy address:
       ffff88806461ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88806461ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff888064620000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                            ^
       ffff888064620080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff888064620100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      
      Fixes: 7f00feaf ("ila: Add generic ILA translation facility")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Reviewed-by: default avatarFlorian Westphal <fw@strlen.de>
      Link: https://patch.msgid.link/20240904144418.1162839-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      031ae728
    • Arkadiusz Kubalewski's avatar
      tools/net/ynl: fix cli.py --subscribe feature · 6fda63c4
      Arkadiusz Kubalewski authored
      Execution of command:
      ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml /
      	--subscribe "monitor" --sleep 10
      fails with:
        File "/repo/./tools/net/ynl/cli.py", line 109, in main
          ynl.check_ntf()
        File "/repo/tools/net/ynl/lib/ynl.py", line 924, in check_ntf
          op = self.rsp_by_value[nl_msg.cmd()]
      KeyError: 19
      
      Parsing Generic Netlink notification messages performs lookup for op in
      the message. The message was not yet decoded, and is not yet considered
      GenlMsg, thus msg.cmd() returns Generic Netlink family id (19) instead of
      proper notification command id (i.e.: DPLL_CMD_PIN_CHANGE_NTF=13).
      
      Allow the op to be obtained within NetlinkProtocol.decode(..) itself if the
      op was not passed to the decode function, thus allow parsing of Generic
      Netlink notifications without causing the failure.
      Suggested-by: default avatarDonald Hunter <donald.hunter@gmail.com>
      Link: https://lore.kernel.org/netdev/m2le0n5xpn.fsf@gmail.com/
      Fixes: 0a966d60 ("tools/net/ynl: Fix extack decoding for directional ops")
      Signed-off-by: default avatarArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Reviewed-by: default avatarDonald Hunter <donald.hunter@gmail.com>
      Link: https://patch.msgid.link/20240904135034.316033-1-arkadiusz.kubalewski@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6fda63c4
    • Vadim Fedorenko's avatar
      MAINTAINERS: fix ptp ocp driver maintainers address · 20d664eb
      Vadim Fedorenko authored
      While checking the latest series for ptp_ocp driver I realised that
      MAINTAINERS file has wrong item about email on linux.dev domain.
      
      Fixes: 795fd934 ("ptp_ocp: adjust MAINTAINERS and mailmap")
      Signed-off-by: default avatarVadim Fedorenko <vadim.fedorenko@linux.dev>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Link: https://patch.msgid.link/20240904131855.559078-1-vadim.fedorenko@linux.devSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      20d664eb
    • Jamie Bainbridge's avatar
      selftests: net: enable bind tests · e4af74a5
      Jamie Bainbridge authored
      bind_wildcard is compiled but not run, bind_timewait is not compiled.
      
      These two tests complete in a very short time, use the test harness
      properly, and seem reasonable to enable.
      
      The author of the tests confirmed via email that these were
      intended to be run.
      
      Enable these two tests.
      
      Fixes: 13715acf ("selftest: Add test for bind() conflicts.")
      Fixes: 2c042e8e ("tcp: Add selftest for bind() and TIME_WAIT.")
      Signed-off-by: default avatarJamie Bainbridge <jamie.bainbridge@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Link: https://patch.msgid.link/5a009b26cf5fb1ad1512d89c61b37e2fac702323.1725430322.git.jamie.bainbridge@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e4af74a5
    • Pawel Dembicki's avatar
      net: dsa: vsc73xx: fix possible subblocks range of CAPT block · 8e69c96d
      Pawel Dembicki authored
      CAPT block (CPU Capture Buffer) have 7 sublocks: 0-3, 4, 6, 7.
      Function 'vsc73xx_is_addr_valid' allows to use only block 0 at this
      moment.
      
      This patch fix it.
      
      Fixes: 05bd97fc ("net: dsa: Add Vitesse VSC73xx DSA router driver")
      Signed-off-by: default avatarPawel Dembicki <paweldembicki@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <florian.fainelli@broadcom.com>
      Link: https://patch.msgid.link/20240903203340.1518789-1-paweldembicki@gmail.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      8e69c96d
    • Toke Høiland-Jørgensen's avatar
      sched: sch_cake: fix bulk flow accounting logic for host fairness · 546ea84d
      Toke Høiland-Jørgensen authored
      In sch_cake, we keep track of the count of active bulk flows per host,
      when running in dst/src host fairness mode, which is used as the
      round-robin weight when iterating through flows. The count of active
      bulk flows is updated whenever a flow changes state.
      
      This has a peculiar interaction with the hash collision handling: when a
      hash collision occurs (after the set-associative hashing), the state of
      the hash bucket is simply updated to match the new packet that collided,
      and if host fairness is enabled, that also means assigning new per-host
      state to the flow. For this reason, the bulk flow counters of the
      host(s) assigned to the flow are decremented, before new state is
      assigned (and the counters, which may not belong to the same host
      anymore, are incremented again).
      
      Back when this code was introduced, the host fairness mode was always
      enabled, so the decrement was unconditional. When the configuration
      flags were introduced the *increment* was made conditional, but
      the *decrement* was not. Which of course can lead to a spurious
      decrement (and associated wrap-around to U16_MAX).
      
      AFAICT, when host fairness is disabled, the decrement and wrap-around
      happens as soon as a hash collision occurs (which is not that common in
      itself, due to the set-associative hashing). However, in most cases this
      is harmless, as the value is only used when host fairness mode is
      enabled. So in order to trigger an array overflow, sch_cake has to first
      be configured with host fairness disabled, and while running in this
      mode, a hash collision has to occur to cause the overflow. Then, the
      qdisc has to be reconfigured to enable host fairness, which leads to the
      array out-of-bounds because the wrapped-around value is retained and
      used as an array index. It seems that syzbot managed to trigger this,
      which is quite impressive in its own right.
      
      This patch fixes the issue by introducing the same conditional check on
      decrement as is used on increment.
      
      The original bug predates the upstreaming of cake, but the commit listed
      in the Fixes tag touched that code, meaning that this patch won't apply
      before that.
      
      Fixes: 71263992 ("sch_cake: Make the dual modes fairer")
      Reported-by: syzbot+7fe7b81d602cc1e6b94d@syzkaller.appspotmail.com
      Signed-off-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Link: https://patch.msgid.link/20240903160846.20909-1-toke@redhat.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      546ea84d
    • Jakub Kicinski's avatar
      docs: netdev: document guidance on cleanup.h · c82299fb
      Jakub Kicinski authored
      Document what was discussed multiple times on list and various
      virtual / in-person conversations. guard() being okay in functions
      <= 20 LoC is a bit of my own invention. If the function is trivial
      it should be fine, but feel free to disagree :)
      
      We'll obviously revisit this guidance as time passes and we and other
      subsystems get more experience.
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Link: https://patch.msgid.link/20240830171443.3532077-1-kuba@kernel.orgSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      c82299fb
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · f0417c50
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      ice: fix synchronization between .ndo_bpf() and reset
      
      Larysa Zaremba says:
      
      PF reset can be triggered asynchronously, by tx_timeout or by a user. With some
      unfortunate timings both ice_vsi_rebuild() and .ndo_bpf will try to access and
      modify XDP rings at the same time, causing system crash.
      
      The first patch factors out rtnl-locked code from VSI rebuild code to avoid
      deadlock. The following changes lock rebuild and .ndo_bpf() critical sections
      with an internal mutex as well and provide complementary fixes.
      
      * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
        ice: do not bring the VSI up, if it was down before the XDP setup
        ice: remove ICE_CFG_BUSY locking from AF_XDP code
        ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset
        ice: check for XDP rings instead of bpf program when unconfiguring
        ice: protect XDP configuration with a mutex
        ice: move netif_queue_set_napi to rtnl-protected sections
      ====================
      
      Link: https://patch.msgid.link/20240903183034.3530411-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f0417c50
    • Jakub Kicinski's avatar
      Merge tag 'wireless-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless · 2603d315
      Jakub Kicinski authored
      Kalle Valo says:
      
      ====================
      wireless fixes for v6.11
      
      Hopefully final fixes for v6.11 and this time only fixes to ath11k
      driver. We need to revert hibernation support due to reported
      regressions and we have a fix for kernel crash introduced in
      v6.11-rc1.
      
      * tag 'wireless-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
        MAINTAINERS: wifi: cw1200: add net-cw1200.h
        Revert "wifi: ath11k: support hibernation"
        Revert "wifi: ath11k: restore country code during resume"
        wifi: ath11k: fix NULL pointer dereference in ath11k_mac_get_eirp_power()
      ====================
      
      Link: https://patch.msgid.link/20240904135906.5986EC4CECA@smtp.kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2603d315
    • Sean Anderson's avatar
      net: xilinx: axienet: Fix race in axienet_stop · 858430db
      Sean Anderson authored
      axienet_dma_err_handler can race with axienet_stop in the following
      manner:
      
      CPU 1                       CPU 2
      ======================      ==================
      axienet_stop()
          napi_disable()
          axienet_dma_stop()
                                  axienet_dma_err_handler()
                                      napi_disable()
                                      axienet_dma_stop()
                                      axienet_dma_start()
                                      napi_enable()
          cancel_work_sync()
          free_irq()
      
      Fix this by setting a flag in axienet_stop telling
      axienet_dma_err_handler not to bother doing anything. I chose not to use
      disable_work_sync to allow for easier backporting.
      Signed-off-by: default avatarSean Anderson <sean.anderson@linux.dev>
      Fixes: 8a3b7a25 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
      Link: https://patch.msgid.link/20240903175141.4132898-1-sean.anderson@linux.devSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      858430db
  2. 04 Sep, 2024 5 commits
    • Jonas Gorski's avatar
      net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN · bee2ef94
      Jonas Gorski authored
      When userspace wants to take over a fdb entry by setting it as
      EXTERN_LEARNED, we set both flags BR_FDB_ADDED_BY_EXT_LEARN and
      BR_FDB_ADDED_BY_USER in br_fdb_external_learn_add().
      
      If the bridge updates the entry later because its port changed, we clear
      the BR_FDB_ADDED_BY_EXT_LEARN flag, but leave the BR_FDB_ADDED_BY_USER
      flag set.
      
      If userspace then wants to take over the entry again,
      br_fdb_external_learn_add() sees that BR_FDB_ADDED_BY_USER and skips
      setting the BR_FDB_ADDED_BY_EXT_LEARN flags, thus silently ignores the
      update.
      
      Fix this by always allowing to set BR_FDB_ADDED_BY_EXT_LEARN regardless
      if this was a user fdb entry or not.
      
      Fixes: 710ae728 ("net: bridge: Mark FDB entries that were added by user as such")
      Signed-off-by: default avatarJonas Gorski <jonas.gorski@bisdn.de>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Link: https://patch.msgid.link/20240903081958.29951-1-jonas.gorski@bisdn.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bee2ef94
    • Hayes Wang's avatar
      r8152: fix the firmware doesn't work · 8487b4af
      Hayes Wang authored
      generic_ocp_write() asks the parameter "size" must be 4 bytes align.
      Therefore, write the bp would fail, if the mac->bp_num is odd. Align the
      size to 4 for fixing it. The way may write an extra bp, but the
      rtl8152_is_fw_mac_ok() makes sure the value must be 0 for the bp whose
      index is more than mac->bp_num. That is, there is no influence for the
      firmware.
      
      Besides, I check the return value of generic_ocp_write() to make sure
      everything is correct.
      
      Fixes: e5c266a6 ("r8152: set bp in bulk")
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Link: https://patch.msgid.link/20240903063333.4502-1-hayeswang@realtek.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8487b4af
    • Kuniyuki Iwashima's avatar
      fou: Fix null-ptr-deref in GRO. · 7e419693
      Kuniyuki Iwashima authored
      We observed a null-ptr-deref in fou_gro_receive() while shutting down
      a host.  [0]
      
      The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol
      in struct fou.
      
      When fou_release() is called due to netns dismantle or explicit tunnel
      teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.
      Then, the tunnel socket is destroyed after a single RCU grace period.
      
      So, in-flight udp4_gro_receive() could find the socket and execute the
      FOU GRO handler, where sk->sk_user_data could be NULL.
      
      Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL
      checks in FOU GRO handlers.
      
      [0]:
      BUG: kernel NULL pointer dereference, address: 0000000000000008
       PF: supervisor read access in kernel mode
       PF: error_code(0x0000) - not-present page
      PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0
      SMP PTI
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1
      Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
      RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
      Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42
      RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297
      RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010
      RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08
      RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002
      R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400
      R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0
      FS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       <IRQ>
       ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
       ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)
       ? no_context (arch/x86/mm/fault.c:752)
       ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)
       ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)
       ? fou_gro_receive (net/ipv4/fou.c:233) [fou]
       udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)
       udp4_gro_receive (net/ipv4/udp_offload.c:604)
       inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))
       dev_gro_receive (net/core/dev.c:6035 (discriminator 4))
       napi_gro_receive (net/core/dev.c:6170)
       ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]
       ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]
       napi_poll (net/core/dev.c:6847)
       net_rx_action (net/core/dev.c:6917)
       __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)
       asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)
      </IRQ>
       do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)
       irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)
       common_interrupt (arch/x86/kernel/irq.c:239)
       asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)
      RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)
      Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00
      RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246
      RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900
      RDX: ffff93daee800000 RSI: ffff93daee87dc00 RDI: ffff93daee87dc64
      RBP: 0000000000000001 R08: ffffffffb5e7b6c0 R09: 0000000000000044
      R10: ffff93daee831b04 R11: 00000000000001cd R12: 0000000000000001
      R13: ffffffffb5e7b740 R14: 0000000000000001 R15: 0000000000000000
       ? sched_clock_cpu (kernel/sched/clock.c:371)
       acpi_idle_enter (drivers/acpi/processor_idle.c:712 (discriminator 3))
       cpuidle_enter_state (drivers/cpuidle/cpuidle.c:237)
       cpuidle_enter (drivers/cpuidle/cpuidle.c:353)
       cpuidle_idle_call (kernel/sched/idle.c:158 kernel/sched/idle.c:239)
       do_idle (kernel/sched/idle.c:302)
       cpu_startup_entry (kernel/sched/idle.c:395 (discriminator 1))
       start_kernel (init/main.c:1048)
       secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:310)
      Modules linked in: udp_diag tcp_diag inet_diag nft_nat ipip tunnel4 dummy fou ip_tunnel nft_masq nft_chain_nat nf_nat wireguard nft_ct curve25519_x86_64 libcurve25519_generic nf_conntrack libchacha20poly1305 nf_defrag_ipv6 nf_defrag_ipv4 nft_objref chacha_x86_64 nft_counter nf_tables nfnetlink poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper mousedev psmouse button ena ptp pps_core crc32c_intel
      CR2: 0000000000000008
      
      Fixes: d92283e3 ("fou: change to use UDP socket GRO")
      Reported-by: default avatarAlphonse Kurian <alkurian@amazon.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Link: https://patch.msgid.link/20240902173927.62706-1-kuniyu@amazon.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7e419693
    • Guillaume Nault's avatar
      bareudp: Fix device stats updates. · 4963d234
      Guillaume Nault authored
      Bareudp devices update their stats concurrently.
      Therefore they need proper atomic increments.
      
      Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Link: https://patch.msgid.link/04b7b9d0b480158eb3ab4366ec80aa2ab7e41fcb.1725031794.git.gnault@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4963d234
    • Souradeep Chakrabarti's avatar
      net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup · b6ecc662
      Souradeep Chakrabarti authored
      Currently napi_disable() gets called during rxq and txq cleanup,
      even before napi is enabled and hrtimer is initialized. It causes
      kernel panic.
      
      ? page_fault_oops+0x136/0x2b0
        ? page_counter_cancel+0x2e/0x80
        ? do_user_addr_fault+0x2f2/0x640
        ? refill_obj_stock+0xc4/0x110
        ? exc_page_fault+0x71/0x160
        ? asm_exc_page_fault+0x27/0x30
        ? __mmdrop+0x10/0x180
        ? __mmdrop+0xec/0x180
        ? hrtimer_active+0xd/0x50
        hrtimer_try_to_cancel+0x2c/0xf0
        hrtimer_cancel+0x15/0x30
        napi_disable+0x65/0x90
        mana_destroy_rxq+0x4c/0x2f0
        mana_create_rxq.isra.0+0x56c/0x6d0
        ? mana_uncfg_vport+0x50/0x50
        mana_alloc_queues+0x21b/0x320
        ? skb_dequeue+0x5f/0x80
      
      Cc: stable@vger.kernel.org
      Fixes: e1b5683f ("net: mana: Move NAPI from EQ to CQ")
      Signed-off-by: default avatarSouradeep Chakrabarti <schakrabarti@linux.microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Reviewed-by: default avatarShradha Gupta <shradhagupta@linux.microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6ecc662
  3. 03 Sep, 2024 23 commits
  4. 02 Sep, 2024 2 commits