commit a5acb54d4066f27e9707af9d93f047f542d5ad88
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 6 07:56:16 2023 +0100

    Linux 5.10.167
    
    Link: https://lore.kernel.org/r/20230203101006.422534094@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6446369fb9f083ce032448c5047da08e298b22e6
Author: Yan Zhai <yan@cloudflare.com>
Date:   Mon Jan 30 12:51:48 2023 -0800

    net: fix NULL pointer in skb_segment_list
    
    commit 876e8ca8366735a604bac86ff7e2732fc9d85d2d upstream.
    
    Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
    introduced UDP listifyed GRO. The segmentation relies on frag_list being
    untouched when passing through the network stack. This assumption can be
    broken sometimes, where frag_list itself gets pulled into linear area,
    leaving frag_list being NULL. When this happens it can trigger
    following NULL pointer dereference, and panic the kernel. Reverse the
    test condition should fix it.
    
    [19185.577801][    C1] BUG: kernel NULL pointer dereference, address:
    ...
    [19185.663775][    C1] RIP: 0010:skb_segment_list+0x1cc/0x390
    ...
    [19185.834644][    C1] Call Trace:
    [19185.841730][    C1]  <TASK>
    [19185.848563][    C1]  __udp_gso_segment+0x33e/0x510
    [19185.857370][    C1]  inet_gso_segment+0x15b/0x3e0
    [19185.866059][    C1]  skb_mac_gso_segment+0x97/0x110
    [19185.874939][    C1]  __skb_gso_segment+0xb2/0x160
    [19185.883646][    C1]  udp_queue_rcv_skb+0xc3/0x1d0
    [19185.892319][    C1]  udp_unicast_rcv_skb+0x75/0x90
    [19185.900979][    C1]  ip_protocol_deliver_rcu+0xd2/0x200
    [19185.910003][    C1]  ip_local_deliver_finish+0x44/0x60
    [19185.918757][    C1]  __netif_receive_skb_one_core+0x8b/0xa0
    [19185.927834][    C1]  process_backlog+0x88/0x130
    [19185.935840][    C1]  __napi_poll+0x27/0x150
    [19185.943447][    C1]  net_rx_action+0x27e/0x5f0
    [19185.951331][    C1]  ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core]
    [19185.960848][    C1]  __do_softirq+0xbc/0x25d
    [19185.968607][    C1]  irq_exit_rcu+0x83/0xb0
    [19185.976247][    C1]  common_interrupt+0x43/0xa0
    [19185.984235][    C1]  asm_common_interrupt+0x22/0x40
    ...
    [19186.094106][    C1]  </TASK>
    
    Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
    Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Yan Zhai <yan@cloudflare.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/r/Y9gt5EUizK1UImEP@debian
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f9db1209f59844839175b5b907d3778cafde93d
Author: Soenke Huster <soenke.huster@eknoes.de>
Date:   Fri Jan 14 17:44:02 2022 +0100

    Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt
    
    commit 3afee2118132e93e5f6fa636dfde86201a860ab3 upstream.
    
    This event is just specified for SCO and eSCO link types.
    On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR
    of an existing LE connection, LE link type and a status that triggers the
    second case of the packet processing a NULL pointer dereference happens,
    as conn->link is NULL.
    
    Signed-off-by: Soenke Huster <soenke.huster@eknoes.de>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Ovidiu Panait <ovidiu.panait@eng.windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d744c03c04a76b3732b18c034bb5d872c3808b7b
Author: Dave Hansen <dave.hansen@intel.com>
Date:   Thu Sep 22 11:47:45 2022 -0700

    ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems
    
    commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream.
    
    Old, circa 2002 chipsets have a bug: they don't go idle when they are
    supposed to.  So, a workaround was added to slow the CPU down and
    ensure that the CPU waits a bit for the chipset to actually go idle.
    This workaround is ancient and has been in place in some form since
    the original kernel ACPI implementation.
    
    But, this workaround is very painful on modern systems.  The "inl()"
    can take thousands of cycles (see Link: for some more detailed
    numbers and some fun kernel archaeology).
    
    First and foremost, modern systems should not be using this code.
    Typical Intel systems have not used it in over a decade because it is
    horribly inferior to MWAIT-based idle.
    
    Despite this, people do seem to be tripping over this workaround on
    AMD system today.
    
    Limit the "dummy wait" workaround to Intel systems.  Keep Modern AMD
    systems from tripping over the workaround.  Remotely modern Intel
    systems use intel_idle instead of this code and will, in practice,
    remain unaffected by the dummy wait.
    
    Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/
    Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd0050b7ffa87c7b260d563646af612f4112a778
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Nov 30 17:08:00 2022 +0800

    dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init
    
    [ Upstream commit 1417f59ac0b02130ee56c0c50794b9b257be3d17 ]
    
    If the function sdma_load_context() fails, the sdma_desc will be
    freed, but the allocated desc->bd is forgot to be freed.
    
    We already met the sdma_load_context() failure case and the log as
    below:
    [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready
    ...
    
    In this case, the desc->bd will not be freed without this change.
    
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Link: https://lore.kernel.org/r/20221130090800.102035-1-hui.wang@canonical.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19c9a2ba46996f2dbc5bfbf1e8f3dc50b347c91c
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Jan 3 19:28:33 2023 +0800

    blk-cgroup: fix missing pd_online_fn() while activating policy
    
    [ Upstream commit e3ff8887e7db757360f97634e0d6f4b8e27a8c46 ]
    
    If the policy defines pd_online_fn(), it should be called after
    pd_init_fn(), like blkg_create().
    
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20230103112833.2013432-1-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1c0263f1eb4deee132e11e52ee6982435460d81
Author: Hao Sun <sunhao.th@gmail.com>
Date:   Fri Jan 6 16:48:38 2023 +0800

    bpf: Skip task with pid=1 in send_signal_common()
    
    [ Upstream commit a3d81bc1eaef48e34dd0b9b48eefed9e02a06451 ]
    
    The following kernel panic can be triggered when a task with pid=1 attaches
    a prog that attempts to send killing signal to itself, also see [1] for more
    details:
    
      Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
      Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
      panic+0x2c4/0x60f kernel/panic.c:275
      do_exit.cold+0x63/0xe4 kernel/exit.c:789
      do_group_exit+0xd4/0x2a0 kernel/exit.c:950
      get_signal+0x2460/0x2600 kernel/signal.c:2858
      arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
      exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
      exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
      __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
      syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
      do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    So skip task with pid=1 in bpf_send_signal_common() to avoid the panic.
    
      [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com
    
    Signed-off-by: Hao Sun <sunhao.th@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/bpf/20230106084838.12690-1-sunhao.th@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f185468631238a98c0cf98e0403a90dc3eab5c70
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Dec 4 10:44:17 2022 +0100

    arm64: dts: imx8mq-thor96: fix no-mmc property for SDHCI
    
    [ Upstream commit ef10d57936ead5e817ef7cea6a87531085e77773 ]
    
    There is no "no-emmc" property, so intention for SD/SDIO only nodes was
    to use "no-mmc".
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a26cef004146cc49463e88a8511269d5a414067e
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Dec 2 17:49:21 2022 +0100

    ARM: dts: vf610: Fix pca9548 i2c-mux node names
    
    [ Upstream commit 42825d1f269355d63554ab3c3762611e4d8053e9 ]
    
    "make dtbs_check":
    
        arch/arm/boot/dts/vf610-zii-dev-rev-b.dtb: tca9548@70: $nodename:0: 'tca9548@70' does not match '^(i2c-?)?mux'
                From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
        arch/arm/boot/dts/vf610-zii-dev-rev-b.dtb: tca9548@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3', 'i2c@4' were unexpected)
                From schema: /scratch/geert/linux/linux-renesas/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
        ...
    
    Fix this by renaming PCA9548 nodes to "i2c-mux", to match the I2C bus
    multiplexer/switch DT bindings and the Generic Names Recommendation in
    the Devicetree Specification.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67a8beb8544e4b15ea27620439b1c63c3fbdd187
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Dec 2 17:49:18 2022 +0100

    ARM: dts: imx: Fix pca9547 i2c-mux node name
    
    [ Upstream commit f78985f9f58380eec37f82c8a2c765aa7670fc29 ]
    
    "make dtbs_check":
    
        arch/arm/boot/dts/imx53-ppd.dtb: i2c-switch@70: $nodename:0: 'i2c-switch@70' does not match '^(i2c-?)?mux'
                From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
        arch/arm/boot/dts/imx53-ppd.dtb: i2c-switch@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3', 'i2c@4', 'i2c@5', 'i2c@6', 'i2c@7' were unexpected)
                From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
    
    Fix this by renaming the PCA9547 node to "i2c-mux", to match the I2C bus
    multiplexer/switch DT bindings and the Generic Names Recommendation in
    the Devicetree Specification.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>