1. 14 Jul, 2024 3 commits
    • Lorenzo Bianconi's avatar
      net: airoha: Introduce ethernet support for EN7581 SoC · 23020f04
      Lorenzo Bianconi authored
      Add airoha_eth driver in order to introduce ethernet support for
      Airoha EN7581 SoC available on EN7581 development board (en7581-evb).
      EN7581 mac controller is mainly composed by the Frame Engine (PSE+PPE)
      and QoS-DMA (QDMA) modules. FE is used for traffic offloading (just
      basic functionalities are currently supported) while QDMA is used for
      DMA operations and QOS functionalities between the mac layer and the
      external modules conncted to the FE GDM ports (e.g MT7530 DSA switch
      or external phys).
      A general overview of airoha_eth architecture is reported below:
      
                     ┌───────┐                                     ┌───────┐
                     │ QDMA2 │                                     │ QDMA1 │
                     └───┬───┘                                     └───┬───┘
                         │                                             │
                 ┌───────▼─────────────────────────────────────────────▼────────┐
                 │                                                              │
                 │       P5                                            P0       │
                 │                                                              │
                 │                                                              │
                 │                                                              │    ┌──────┐
                 │                                                           P3 ├────► GDM3 │
                 │                                                              │    └──────┘
                 │                                                              │
                 │                                                              │
      ┌─────┐    │                                                              │
      │ PPE ◄────┤ P4                          PSE                              │
      └─────┘    │                                                              │
                 │                                                              │
                 │                                                              │
                 │                                                              │    ┌──────┐
                 │                                                           P9 ├────► GDM4 │
                 │                                                              │    └──────┘
                 │                                                              │
                 │                                                              │
                 │                                                              │
                 │        P2                                           P1       │
                 └─────────┬───────────────────────────────────────────┬────────┘
                           │                                           │
                       ┌───▼──┐                                     ┌──▼───┐
                       │ GDM2 │                                     │ GDM1 │
                       └──────┘                                     └──┬───┘
                                                                       │
                                                                  ┌────▼─────┐
                                                                  │  MT7530  │
                                                                  └──────────┘
      
      Currently only hw LAN features (QDMA1+GDM1) are available while hw WAN
      (QDMA2+GDM{2,3,4}) ones will be added with subsequent patches introducing
      traffic offloading support.
      Tested-by: default avatarBenjamin Larsson <benjamin.larsson@genexis.eu>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://patch.msgid.link/274945d2391c195098ab180a46d0617b18b9e42c.1720818878.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      23020f04
    • Lorenzo Bianconi's avatar
      dt-bindings: net: airoha: Add EN7581 ethernet controller · 6bc8719c
      Lorenzo Bianconi authored
      Introduce device-tree binding documentation for Airoha EN7581 ethernet
      mac controller.
      Reviewed-by: default avatarRob Herring (Arm) <robh@kernel.org>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://patch.msgid.link/7dfecf8aa4e6519562a94455b95c49e1b3c858a0.1720818878.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6bc8719c
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · 861f34e6
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      ice: Switch API optimizations
      
      Marcin Szycik says:
      
      Optimize the process of creating a recipe in the switch block by removing
      duplicate switch ID words and changing how result indexes are fitted into
      recipes. In many cases this can decrease the number of recipes required to
      add a certain set of rules, potentially allowing a more varied set of rules
      to be created. Total rule count will also increase, since less words will
      be left unused/wasted. There are only 64 rules available in total, so every
      one counts.
      
      After this modification, many fields and some structs became unused or were
      simplified, resulting in overall simpler implementation.
      
      * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
        ice: Add tracepoint for adding and removing switch rules
        ice: Remove unused members from switch API
        ice: Optimize switch recipe creation
        ice: remove unused recipe bookkeeping data
        ice: Simplify bitmap setting in adding recipe
        ice: Remove reading all recipes before adding a new one
        ice: Remove unused struct ice_prot_lkup_ext members
      ====================
      
      Link: https://patch.msgid.link/20240711181312.2019606-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      861f34e6
  2. 13 Jul, 2024 35 commits
  3. 12 Jul, 2024 2 commits
    • Tengda Wu's avatar
      selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() · e435b043
      Tengda Wu authored
      This test verifies that resolve_prog_type() works as expected when
      `attach_prog_fd` is not passed in.
      
      `prog->aux->dst_prog` in resolve_prog_type() is assigned by
      `attach_prog_fd`, and would be NULL if `attach_prog_fd` is not provided.
      
      Loading EXT prog with bpf_dynptr_from_skb() kfunc call in this way will
      lead to null-pointer-deref.
      
      Verify that the null-pointer-deref bug in resolve_prog_type() is fixed.
      Signed-off-by: default avatarTengda Wu <wutengda@huaweicloud.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20240711145819.254178-3-wutengda@huaweicloud.com
      e435b043
    • Tengda Wu's avatar
      bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT · f7866c35
      Tengda Wu authored
      When loading a EXT program without specifying `attr->attach_prog_fd`,
      the `prog->aux->dst_prog` will be null. At this time, calling
      resolve_prog_type() anywhere will result in a null pointer dereference.
      
      Example stack trace:
      
      [    8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
      [    8.108262] Mem abort info:
      [    8.108384]   ESR = 0x0000000096000004
      [    8.108547]   EC = 0x25: DABT (current EL), IL = 32 bits
      [    8.108722]   SET = 0, FnV = 0
      [    8.108827]   EA = 0, S1PTW = 0
      [    8.108939]   FSC = 0x04: level 0 translation fault
      [    8.109102] Data abort info:
      [    8.109203]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
      [    8.109399]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      [    8.109614]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
      [    8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000
      [    8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000
      [    8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
      [    8.112783] Modules linked in:
      [    8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1
      [    8.113230] Hardware name: linux,dummy-virt (DT)
      [    8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [    8.113429] pc : may_access_direct_pkt_data+0x24/0xa0
      [    8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8
      [    8.113798] sp : ffff80008283b9f0
      [    8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001
      [    8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000
      [    8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000
      [    8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff
      [    8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720
      [    8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720
      [    8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4
      [    8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f
      [    8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c
      [    8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000
      [    8.114126] Call trace:
      [    8.114159]  may_access_direct_pkt_data+0x24/0xa0
      [    8.114202]  bpf_check+0x3bc/0x28c0
      [    8.114214]  bpf_prog_load+0x658/0xa58
      [    8.114227]  __sys_bpf+0xc50/0x2250
      [    8.114240]  __arm64_sys_bpf+0x28/0x40
      [    8.114254]  invoke_syscall.constprop.0+0x54/0xf0
      [    8.114273]  do_el0_svc+0x4c/0xd8
      [    8.114289]  el0_svc+0x3c/0x140
      [    8.114305]  el0t_64_sync_handler+0x134/0x150
      [    8.114331]  el0t_64_sync+0x168/0x170
      [    8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)
      [    8.118672] ---[ end trace 0000000000000000 ]---
      
      One way to fix it is by forcing `attach_prog_fd` non-empty when
      bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`
      API broken which use verifier log to probe prog type and will log
      nothing if we reject invalid EXT prog before bpf_check().
      
      Another way is by adding null check in resolve_prog_type().
      
      The issue was introduced by commit 4a9c7bbe ("bpf: Resolve to
      prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wanted
      to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before
      that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows
      the logic below:
      
        prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type;
      
      It implies that when EXT program is not yet attached to `dst_prog`,
      the prog type should be EXT itself. This code worked fine in the past.
      So just keep using it.
      
      Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog`
      is not present in resolve_prog_type().
      
      Fixes: 4a9c7bbe ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT")
      Signed-off-by: default avatarTengda Wu <wutengda@huaweicloud.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20240711145819.254178-2-wutengda@huaweicloud.com
      f7866c35