Linux 6.0.9

 
ALSA: arm: pxa: pxa2xx-ac97-lib: fix return value check of platform_get_irq() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Sat Oct 29 16:20:01 2022 +0800

    ALSA: arm: pxa: pxa2xx-ac97-lib: fix return value check of platform_get_irq()
    
    [ Upstream commit 46cf1954de3f324dc7f9472c12c3bd03b268a11b ]
    
    platform_get_irq() returns negative error number on failure, fix the
    return value check in pxa2xx_ac97_hw_probe() and assign the error code
    to 'ret'.
    
    Fixes: 2548e6c76ebf ("ARM: pxa: pxa2xx-ac97-lib: use IRQ resource")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/ca0132: add quirk for EVGA Z390 DARK [+ + +]
Author: Xian Wang <[email protected]>
Date:   Fri Nov 4 13:29:13 2022 -0700

    ALSA: hda/ca0132: add quirk for EVGA Z390 DARK
    
    commit 0c423e2ffa7edd3f8f9bcf17ce73fa9c7509b99e upstream.
    
    The Z390 DARK mainboard uses a CA0132 audio controller. The quirk is
    needed to enable surround sound and 3.5mm headphone jack handling in
    the front audio connector as well as in the rear of the board when in
    stereo mode.
    
    Page 97 of the linked manual contains instructions to setup the
    controller.
    
    Signed-off-by: Xian Wang <[email protected]>
    Cc: [email protected]
    Link: https://www.evga.com/support/manuals/files/131-CS-E399.pdf
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/hdmi - enable runtime pm for more AMD display audio [+ + +]
Author: Evan Quan <[email protected]>
Date:   Tue Nov 8 16:47:46 2022 +0800

    ALSA: hda/hdmi - enable runtime pm for more AMD display audio
    
    commit fdcc4c22b7ab20e90b97f8bc6225d876b72b8f16 upstream.
    
    We are able to power down the GPU and audio via the GPU driver
    so flag these asics as supporting runtime pm.
    
    Signed-off-by: Evan Quan <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Add Positivo C6300 model quirk [+ + +]
Author: Edson Juliano Drosdeck <[email protected]>
Date:   Wed Nov 9 13:17:32 2022 -0400

    ALSA: hda/realtek: Add Positivo C6300 model quirk
    
    commit 79e28f2ab3440e08f5fbf65648b008341c37b496 upstream.
    
    Positivo Master C6300 (1849:a233) require quirk for anabling headset-mic
    
    Signed-off-by: Edson Juliano Drosdeck <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Add quirk for ASUS Zenbook using CS35L41 [+ + +]
Author: Stefan Binding <[email protected]>
Date:   Fri Oct 28 11:27:42 2022 +0100

    ALSA: hda/realtek: Add quirk for ASUS Zenbook using CS35L41
    
    commit 8d06679b25fc6813eb2438fac7fa13f4f3c2ef37 upstream.
    
    This Asus Zenbook laptop use Realtek HDA codec combined with
    2xCS35L41 Amplifiers using I2C with Internal Boost.
    
    Signed-off-by: Stefan Binding <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: fix potential memleak in 'add_widget_node' [+ + +]
Author: Ye Bin <[email protected]>
Date:   Thu Nov 10 22:45:39 2022 +0800

    ALSA: hda: fix potential memleak in 'add_widget_node'
    
    commit 9a5523f72bd2b0d66eef3d58810c6eb7b5ffc143 upstream.
    
    As 'kobject_add' may allocated memory for 'kobject->name' when return error.
    And in this function, if call 'kobject_add' failed didn't free kobject.
    So call 'kobject_put' to recycling resources.
    
    Signed-off-by: Ye Bin <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: memalloc: Don't fall back for SG-buffer with IOMMU [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Thu Nov 10 14:22:16 2022 +0100

    ALSA: memalloc: Don't fall back for SG-buffer with IOMMU
    
    [ Upstream commit 9736a325137b62499d2b4be3fc2d742b131f75da ]
    
    When the non-contiguous page allocation for SG buffer allocation
    fails, the memalloc helper tries to fall back to the old page
    allocation methods.  This would, however, result in the bogus page
    addresses when IOMMU is enabled.  Usually in such a case, the fallback
    allocation should fail as well, but occasionally it succeeds and
    hitting a bad access.
    
    The fallback was thought for non-IOMMU case, and as the error from
    dma_alloc_noncontiguous() with IOMMU essentially implies a fatal
    memory allocation error, we should return the error straightforwardly
    without fallback.  This avoids the corner case like the above.
    
    The patch also renames the local variable "dma_ops" with snd_ prefix
    for avoiding the name conflict.
    
    Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again")
    Reported-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]m
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: memalloc: Try dma_alloc_noncontiguous() at first [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Sat Nov 12 09:47:18 2022 +0100

    ALSA: memalloc: Try dma_alloc_noncontiguous() at first
    
    commit 9d8e536d36e75e76614fe09ffab9a1df95b8b666 upstream.
    
    The latest fix for the non-contiguous memalloc helper changed the
    allocation method for a non-IOMMU system to use only the fallback
    allocator.  This should have worked, but it caused a problem sometimes
    when too many non-contiguous pages are allocated that can't be treated
    by HD-audio controller.
    
    As a quirk workaround, go back to the original strategy: use
    dma_alloc_noncontiguous() at first, and apply the fallback only when
    it fails, but only for non-IOMMU case.
    
    We'll need a better fix in the fallback code as well, but this
    workaround should paper over most cases.
    
    Fixes: 9736a325137b ("ALSA: memalloc: Don't fall back for SG-buffer with IOMMU")
    Reported-by: Linus Torvalds <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]om
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: usb-audio: Add DSD support for Accuphase DAC-60 [+ + +]
Author: Jussi Laako <[email protected]>
Date:   Wed Nov 9 00:12:41 2022 +0200

    ALSA: usb-audio: Add DSD support for Accuphase DAC-60
    
    commit 8cbd4725ffff3eface1f5f3397af02acad5b2831 upstream.
    
    Accuphase DAC-60 option card supports native DSD up to DSD256,
    but doesn't have support for auto-detection. Explicitly enable
    DSD support for the correct altsetting.
    
    Signed-off-by: Jussi Laako <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: usb-audio: Add quirk entry for M-Audio Micro [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Nov 8 15:07:21 2022 +0100

    ALSA: usb-audio: Add quirk entry for M-Audio Micro
    
    commit 2f01a612d4758b45f775dbb88a49cf534ba47275 upstream.
    
    M-Audio Micro (0762:201a) defines the descriptor as vendor-specific,
    while the content seems class-compliant.  Just overriding the probe
    makes the device working.
    
    Reported-by: Ash Logan <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: usb-audio: Yet more regression for for the delayed card registration [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Nov 8 07:58:23 2022 +0100

    ALSA: usb-audio: Yet more regression for for the delayed card registration
    
    commit 971cb608d1c5d95533a43b549bb8ec9637f10043 upstream.
    
    Although we tried to fix the regression for the recent changes with
    the delayed card registration, it doesn't seem covering the all
    cases; e.g. on Roland EDIROL M-100FX, where the generic quirk for
    Roland devices is applied, it misses the card registration because the
    detection of the last interface (apparently for MIDI) fails.
    
    This patch is an attempt to recover from those failures by calling the
    card register also at the error path for the secondary interfaces.
    The card register condition is also extended to match with the old
    check in the previous patch, too (i.e. the simple check of the
    interface number) for catching the probe with errors.
    
    Fixes: 39efc9c8a973 ("ALSA: usb-audio: Fix last interface check for registration")
    Cc: <[email protected]>
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1205111
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arch/x86/mm/hugetlbpage.c: pud_huge() returns 0 when using 2-level paging [+ + +]
Author: Naoya Horiguchi <[email protected]>
Date:   Mon Nov 7 11:10:10 2022 +0900

    arch/x86/mm/hugetlbpage.c: pud_huge() returns 0 when using 2-level paging
    
    commit 1fdbed657a4726639c4f17841fd2a0fb646c746e upstream.
    
    The following bug is reported to be triggered when starting X on x86-32
    system with i915:
    
      [  225.777375] kernel BUG at mm/memory.c:2664!
      [  225.777391] invalid opcode: 0000 [#1] PREEMPT SMP
      [  225.777405] CPU: 0 PID: 2402 Comm: Xorg Not tainted 6.1.0-rc3-bdg+ #86
      [  225.777415] Hardware name:  /8I865G775-G, BIOS F1 08/29/2006
      [  225.777421] EIP: __apply_to_page_range+0x24d/0x31c
      [  225.777437] Code: ff ff 8b 55 e8 8b 45 cc e8 0a 11 ec ff 89 d8 83 c4 28 5b 5e 5f 5d c3 81 7d e0 a0 ef 96 c1 74 ad 8b 45 d0 e8 2d 83 49 00 eb a3 <0f> 0b 25 00 f0 ff ff 81 eb 00 00 00 40 01 c3 8b 45 ec 8b 00 e8 76
      [  225.777446] EAX: 00000001 EBX: c53a3b58 ECX: b5c00000 EDX: c258aa00
      [  225.777454] ESI: b5c00000 EDI: b5900000 EBP: c4b0fdb4 ESP: c4b0fd80
      [  225.777462] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010202
      [  225.777470] CR0: 80050033 CR2: b5900000 CR3: 053a3000 CR4: 000006d0
      [  225.777479] Call Trace:
      [  225.777486]  ? i915_memcpy_init_early+0x63/0x63 [i915]
      [  225.777684]  apply_to_page_range+0x21/0x27
      [  225.777694]  ? i915_memcpy_init_early+0x63/0x63 [i915]
      [  225.777870]  remap_io_mapping+0x49/0x75 [i915]
      [  225.778046]  ? i915_memcpy_init_early+0x63/0x63 [i915]
      [  225.778220]  ? mutex_unlock+0xb/0xd
      [  225.778231]  ? i915_vma_pin_fence+0x6d/0xf7 [i915]
      [  225.778420]  vm_fault_gtt+0x2a9/0x8f1 [i915]
      [  225.778644]  ? lock_is_held_type+0x56/0xe7
      [  225.778655]  ? lock_is_held_type+0x7a/0xe7
      [  225.778663]  ? 0xc1000000
      [  225.778670]  __do_fault+0x21/0x6a
      [  225.778679]  handle_mm_fault+0x708/0xb21
      [  225.778686]  ? mt_find+0x21e/0x5ae
      [  225.778696]  exc_page_fault+0x185/0x705
      [  225.778704]  ? doublefault_shim+0x127/0x127
      [  225.778715]  handle_exception+0x130/0x130
      [  225.778723] EIP: 0xb700468a
    
    Recently pud_huge() got aware of non-present entry by commit 3a194f3f8ad0
    ("mm/hugetlb: make pud_huge() and follow_huge_pud() aware of non-present
    pud entry") to handle some special states of gigantic page.  However, it's
    overlooked that pud_none() always returns false when running with 2-level
    paging, and as a result pud_huge() can return true pointlessly.
    
    Introduce "#if CONFIG_PGTABLE_LEVELS > 2" to pud_huge() to deal with this.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3a194f3f8ad0 ("mm/hugetlb: make pud_huge() and follow_huge_pud() aware of non-present pud entry")
    Signed-off-by: Naoya Horiguchi <[email protected]>
    Reported-by: Ville Syrjälä <[email protected]>
    Tested-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Miaohe Lin <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Liu Shixin <[email protected]>
    Cc: Mike Kravetz <[email protected]>
    Cc: Muchun Song <[email protected]>
    Cc: Oscar Salvador <[email protected]>
    Cc: Yang Shi <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: efi: Fix handling of misaligned runtime regions and drop warning [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Sun Nov 6 15:53:54 2022 +0100

    arm64: efi: Fix handling of misaligned runtime regions and drop warning
    
    commit 9b9eaee9828fe98b030cf43ac50065a54a2f5d52 upstream.
    
    Currently, when mapping the EFI runtime regions in the EFI page tables,
    we complain about misaligned regions in a rather noisy way, using
    WARN().
    
    Not only does this produce a lot of irrelevant clutter in the log, it is
    factually incorrect, as misaligned runtime regions are actually allowed
    by the EFI spec as long as they don't require conflicting memory types
    within the same 64k page.
    
    So let's drop the warning, and tweak the code so that we
    - take both the start and end of the region into account when checking
      for misalignment
    - only revert to RWX mappings for non-code regions if misaligned code
      regions are also known to exist.
    
    Cc: <[email protected]>
    Acked-by: Linus Torvalds <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ata: libata-scsi: fix SYNCHRONIZE CACHE (16) command failure [+ + +]
Author: Shin'ichiro Kawasaki <[email protected]>
Date:   Mon Nov 7 13:02:29 2022 +0900

    ata: libata-scsi: fix SYNCHRONIZE CACHE (16) command failure
    
    commit ea045fd344cb15c164e9ffc8b8cffb6883df8475 upstream.
    
    SAT SCSI/ATA Translation specification requires SCSI SYNCHRONIZE CACHE
    (10) and (16) commands both shall be translated to ATA flush command.
    Also, ZBC Zoned Block Commands specification mandates SYNCHRONIZE CACHE
    (16) command support. However, libata translates only SYNCHRONIZE CACHE
    (10). This results in SYNCHRONIZE CACHE (16) command failures on SATA
    drives and then libata translation does not conform to ZBC. To avoid the
    failure, add support for SYNCHRONIZE CACHE (16).
    
    Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
    Cc: [email protected]
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bnxt_en: Fix possible crash in bnxt_hwrm_set_coal() [+ + +]
Author: Michael Chan <[email protected]>
Date:   Thu Nov 3 19:33:26 2022 -0400

    bnxt_en: Fix possible crash in bnxt_hwrm_set_coal()
    
    [ Upstream commit 6d81ea3765dfa6c8a20822613c81edad1c4a16a0 ]
    
    During the error recovery sequence, the rtnl_lock is not held for the
    entire duration and some datastructures may be freed during the sequence.
    Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure
    that the device is fully operational before proceeding to reconfigure
    the coalescing settings.
    
    This will fix a possible crash like this:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    PGD 0 P4D 0
    Oops: 0000 [#1] SMP NOPTI
    CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-348.el8.x86_64 #1
    Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019
    RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en]
    Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6
    RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5
    RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28
    RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c
    R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0
    FS:  00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     ethnl_set_coalesce+0x3ce/0x4c0
     genl_family_rcv_msg_doit.isra.15+0x10f/0x150
     genl_family_rcv_msg+0xb3/0x160
     ? coalesce_fill_reply+0x480/0x480
     genl_rcv_msg+0x47/0x90
     ? genl_family_rcv_msg+0x160/0x160
     netlink_rcv_skb+0x4c/0x120
     genl_rcv+0x24/0x40
     netlink_unicast+0x196/0x230
     netlink_sendmsg+0x204/0x3d0
     sock_sendmsg+0x4c/0x50
     __sys_sendto+0xee/0x160
     ? syscall_trace_enter+0x1d3/0x2c0
     ? __audit_syscall_exit+0x249/0x2a0
     __x64_sys_sendto+0x24/0x30
     do_syscall_64+0x5b/0x1a0
     entry_SYSCALL_64_after_hwframe+0x65/0xca
    RIP: 0033:0x7f38524163bb
    
    Fixes: 2151fe0830fd ("bnxt_en: Handle RESET_NOTIFY async event from firmware.")
    Reviewed-by: Somnath Kotur <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bnxt_en: fix potentially incorrect return value for ndo_rx_flow_steer [+ + +]
Author: Alex Barba <[email protected]>
Date:   Thu Nov 3 19:33:27 2022 -0400

    bnxt_en: fix potentially incorrect return value for ndo_rx_flow_steer
    
    [ Upstream commit 02597d39145bb0aa81d04bf39b6a913ce9a9d465 ]
    
    In the bnxt_en driver ndo_rx_flow_steer returns '0' whenever an entry
    that we are attempting to steer is already found.  This is not the
    correct behavior.  The return code should be the value/index that
    corresponds to the entry.  Returning zero all the time causes the
    RFS records to be incorrect unless entry '0' is the correct one.  As
    flows migrate to different cores this can create entries that are not
    correct.
    
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Reported-by: Akshay Navgire <[email protected]>
    Signed-off-by: Alex Barba <[email protected]>
    Signed-off-by: Andy Gospodarek <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, sock_map: Move cancel_work_sync() out of sock lock [+ + +]
Author: Cong Wang <[email protected]>
Date:   Tue Nov 1 21:34:17 2022 -0700

    bpf, sock_map: Move cancel_work_sync() out of sock lock
    
    [ Upstream commit 8bbabb3fddcd0f858be69ed5abc9b470a239d6f2 ]
    
    Stanislav reported a lockdep warning, which is caused by the
    cancel_work_sync() called inside sock_map_close(), as analyzed
    below by Jakub:
    
    psock->work.func = sk_psock_backlog()
      ACQUIRE psock->work_mutex
        sk_psock_handle_skb()
          skb_send_sock()
            __skb_send_sock()
              sendpage_unlocked()
                kernel_sendpage()
                  sock->ops->sendpage = inet_sendpage()
                    sk->sk_prot->sendpage = tcp_sendpage()
                      ACQUIRE sk->sk_lock
                        tcp_sendpage_locked()
                      RELEASE sk->sk_lock
      RELEASE psock->work_mutex
    
    sock_map_close()
      ACQUIRE sk->sk_lock
      sk_psock_stop()
        sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED)
        cancel_work_sync()
          __cancel_work_timer()
            __flush_work()
              // wait for psock->work to finish
      RELEASE sk->sk_lock
    
    We can move the cancel_work_sync() out of the sock lock protection,
    but still before saved_close() was called.
    
    Fixes: 799aa7f98d53 ("skmsg: Avoid lock_sock() in sk_psock_backlog()")
    Reported-by: Stanislav Fomichev <[email protected]>
    Signed-off-by: Cong Wang <[email protected]>
    Signed-off-by: Daniel Borkmann <dan[email protected]>
    Tested-by: Jakub Sitnicki <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Acked-by: Jakub Sitnicki <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues [+ + +]
Author: Wang Yufen <[email protected]>
Date:   Tue Nov 1 09:31:36 2022 +0800

    bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues
    
    [ Upstream commit 8ec95b94716a1e4d126edc3fb2bc426a717e2dba ]
    
    When running `test_sockmap` selftests, the following warning appears:
    
      WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0
      Call Trace:
      <TASK>
      inet_csk_destroy_sock+0x55/0x110
      tcp_rcv_state_process+0xd28/0x1380
      ? tcp_v4_do_rcv+0x77/0x2c0
      tcp_v4_do_rcv+0x77/0x2c0
      __release_sock+0x106/0x130
      __tcp_close+0x1a7/0x4e0
      tcp_close+0x20/0x70
      inet_release+0x3c/0x80
      __sock_release+0x3a/0xb0
      sock_close+0x14/0x20
      __fput+0xa3/0x260
      task_work_run+0x59/0xb0
      exit_to_user_mode_prepare+0x1b3/0x1c0
      syscall_exit_to_user_mode+0x19/0x50
      do_syscall_64+0x48/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged
    while msg has more_data"), where I used msg->sg.size to replace the tosend,
    causing breakage:
    
      if (msg->apply_bytes && msg->apply_bytes < tosend)
        tosend = psock->apply_bytes;
    
    Fixes: 84472b436e76 ("bpf, sockmap: Fix more uncharged while msg has more_data")
    Reported-by: Jakub Sitnicki <[email protected]>
    Signed-off-by: Wang Yufen <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Acked-by: Jakub Sitnicki <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, verifier: Fix memory leak in array reallocation for stack state [+ + +]
Author: Kees Cook <[email protected]>
Date:   Fri Oct 28 19:54:30 2022 -0700

    bpf, verifier: Fix memory leak in array reallocation for stack state
    
    [ Upstream commit 42378a9ca55347102bbf86708776061d8fe3ece2 ]
    
    If an error (NULL) is returned by krealloc(), callers of realloc_array()
    were setting their allocation pointers to NULL, but on error krealloc()
    does not touch the original allocation. This would result in a memory
    resource leak. Instead, free the old allocation on the error handling
    path.
    
    The memory leak information is as follows as also reported by Zhengchao:
    
      unreferenced object 0xffff888019801800 (size 256):
      comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0
        [<0000000086712a0b>] krealloc+0x83/0xd0
        [<00000000139aab02>] realloc_array+0x82/0xe2
        [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186
        [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341
        [<0000000081780455>] do_check_common+0x5358/0xb350
        [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d
        [<000000002973c690>] bpf_prog_load+0x13db/0x2240
        [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0
        [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0
        [<0000000056fedaf5>] do_syscall_64+0x35/0x80
        [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: c69431aab67a ("bpf: verifier: Improve function state reallocation")
    Reported-by: Zhengchao Shao <[email protected]>
    Reported-by: Kees Cook <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: Bill Wendling <[email protected]>
    Cc: Lorenz Bauer <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Add helper macro bpf_for_each_reg_in_vstate [+ + +]
Author: Kumar Kartikeya Dwivedi <[email protected]>
Date:   Sun Sep 4 22:41:28 2022 +0200

    bpf: Add helper macro bpf_for_each_reg_in_vstate
    
    [ Upstream commit b239da34203f49c40b5d656220c39647c3ff0b3c ]
    
    For a lot of use cases in future patches, we will want to modify the
    state of registers part of some same 'group' (e.g. same ref_obj_id). It
    won't just be limited to releasing reference state, but setting a type
    flag dynamically based on certain actions, etc.
    
    Hence, we need a way to easily pass a callback to the function that
    iterates over all registers in current bpf_verifier_state in all frames
    upto (and including) the curframe.
    
    While in C++ we would be able to easily use a lambda to pass state and
    the callback together, sadly we aren't using C++ in the kernel. The next
    best thing to avoid defining a function for each case seems like
    statement expressions in GNU C. The kernel already uses them heavily,
    hence they can passed to the macro in the style of a lambda. The
    statement expression will then be substituted in the for loop bodies.
    
    Variables __state and __reg are set to current bpf_func_state and reg
    for each invocation of the expression inside the passed in verifier
    state.
    
    Then, convert mark_ptr_or_null_regs, clear_all_pkt_pointers,
    release_reference, find_good_pkt_pointers, find_equal_scalars to
    use bpf_for_each_reg_in_vstate.
    
    Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Stable-dep-of: f1db20814af5 ("bpf: Fix wrong reg type conversion in release_reference()")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix wrong reg type conversion in release_reference() [+ + +]
Author: Youlin Li <[email protected]>
Date:   Thu Nov 3 17:34:39 2022 +0800

    bpf: Fix wrong reg type conversion in release_reference()
    
    [ Upstream commit f1db20814af532f85e091231223e5e4818e8464b ]
    
    Some helper functions will allocate memory. To avoid memory leaks, the
    verifier requires the eBPF program to release these memories by calling
    the corresponding helper functions.
    
    When a resource is released, all pointer registers corresponding to the
    resource should be invalidated. The verifier use release_references() to
    do this job, by apply  __mark_reg_unknown() to each relevant register.
    
    It will give these registers the type of SCALAR_VALUE. A register that
    will contain a pointer value at runtime, but of type SCALAR_VALUE, which
    may allow the unprivileged user to get a kernel pointer by storing this
    register into a map.
    
    Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this
    problem.
    
    Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier")
    Signed-off-by: Youlin Li <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE [+ + +]
Author: Pu Lehui <[email protected]>
Date:   Wed Nov 2 16:40:34 2022 +0800

    bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE
    
    [ Upstream commit 34de8e6e0e1f66e431abf4123934a2581cb5f133 ]
    
    When using bpftool to pin {PROG, MAP, LINK} without FILE,
    segmentation fault will occur. The reson is that the lack
    of FILE will cause strlen to trigger NULL pointer dereference.
    The corresponding stacktrace is shown below:
    
    do_pin
      do_pin_any
        do_pin_fd
          mount_bpffs_for_pin
            strlen(name) <- NULL pointer dereference
    
    Fix it by adding validation to the common process.
    
    Fixes: 75a1e792c335 ("tools: bpftool: Allow all prog/map handles for pinning objects")
    Signed-off-by: Pu Lehui <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: fix match incorrectly in dev_args_match_device [+ + +]
Author: Liu Shixin <[email protected]>
Date:   Thu Nov 3 16:33:01 2022 +0800

    btrfs: fix match incorrectly in dev_args_match_device
    
    commit 0fca385d6ebc3cabb20f67bcf8a71f1448bdc001 upstream.
    
    syzkaller found a failed assertion:
    
      assertion failed: (args->devid != (u64)-1) || args->missing, in fs/btrfs/volumes.c:6921
    
    This can be triggered when we set devid to (u64)-1 by ioctl. In this
    case, the match of devid will be skipped and the match of device may
    succeed incorrectly.
    
    Patch 562d7b1512f7 introduced this function which is used to match device.
    This function contains two matching scenarios, we can distinguish them by
    checking the value of args->missing rather than check whether args->devid
    and args->uuid is default value.
    
    Reported-by: [email protected]
    Fixes: 562d7b1512f7 ("btrfs: handle device lookup with btrfs_dev_lookup_args")
    CC: [email protected] # 5.16+
    Reviewed-by: Nikolay Borisov <[email protected]>
    Signed-off-by: Liu Shixin <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: selftests: fix wrong error check in btrfs_free_dummy_root() [+ + +]
Author: Zhang Xiaoxu <[email protected]>
Date:   Tue Nov 1 10:53:54 2022 +0800

    btrfs: selftests: fix wrong error check in btrfs_free_dummy_root()
    
    commit 9b2f20344d450137d015b380ff0c2e2a6a170135 upstream.
    
    The btrfs_alloc_dummy_root() uses ERR_PTR as the error return value
    rather than NULL, if error happened, there will be a NULL pointer
    dereference:
    
      BUG: KASAN: null-ptr-deref in btrfs_free_dummy_root+0x21/0x50 [btrfs]
      Read of size 8 at addr 000000000000002c by task insmod/258926
    
      CPU: 2 PID: 258926 Comm: insmod Tainted: G        W          6.1.0-rc2+ #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x34/0x44
       kasan_report+0xb7/0x140
       kasan_check_range+0x145/0x1a0
       btrfs_free_dummy_root+0x21/0x50 [btrfs]
       btrfs_test_free_space_cache+0x1a8c/0x1add [btrfs]
       btrfs_run_sanity_tests+0x65/0x80 [btrfs]
       init_btrfs_fs+0xec/0x154 [btrfs]
       do_one_initcall+0x87/0x2a0
       do_init_module+0xdf/0x320
       load_module+0x3006/0x3390
       __do_sys_finit_module+0x113/0x1b0
       do_syscall_64+0x35/0x80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Fixes: aaedb55bc08f ("Btrfs: add tests for btrfs_get_extent")
    CC: [email protected] # 4.9+
    Reviewed-by: Anand Jain <[email protected]>
    Signed-off-by: Zhang Xiaoxu <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: zoned: clone zoned device info when cloning a device [+ + +]
Author: Johannes Thumshirn <[email protected]>
Date:   Fri Nov 4 07:12:33 2022 -0700

    btrfs: zoned: clone zoned device info when cloning a device
    
    commit 21e61ec6d0bb786818490e926aa9aeb4de95ad0d upstream.
    
    When cloning a btrfs_device, we're not cloning the associated
    btrfs_zoned_device_info structure of the device in case of a zoned
    filesystem.
    
    Later on this leads to a NULL pointer dereference when accessing the
    device's zone_info for instance when setting a zone as active.
    
    This was uncovered by fstests' testcase btrfs/161.
    
    CC: [email protected] # 5.15+
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: zoned: initialize device's zone info for seeding [+ + +]
Author: Johannes Thumshirn <[email protected]>
Date:   Fri Nov 4 07:12:34 2022 -0700

    btrfs: zoned: initialize device's zone info for seeding
    
    commit a8d1b1647bf8244a5f270538e9e636e2657fffa3 upstream.
    
    When performing seeding on a zoned filesystem it is necessary to
    initialize each zoned device's btrfs_zoned_device_info structure,
    otherwise mounting the filesystem will cause a NULL pointer dereference.
    
    This was uncovered by fstests' testcase btrfs/163.
    
    CC: [email protected] # 5.15+
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
can: af_can: fix NULL pointer dereference in can_rx_register() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Fri Oct 28 16:56:50 2022 +0800

    can: af_can: fix NULL pointer dereference in can_rx_register()
    
    [ Upstream commit 8aa59e355949442c408408c2d836e561794c40a1 ]
    
    It causes NULL pointer dereference when testing as following:
    (a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.
    (b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan
        link device, and bind vxcan device to bond device (can also use
        ifenslave command to bind vxcan device to bond device).
    (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.
    (d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.
    
    The bond device invokes the can-raw protocol registration interface to
    receive CAN packets. However, ml_priv is not allocated to the dev,
    dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,
    it will occur the NULL pointer dereference issue.
    
    The following is the stack information:
    BUG: kernel NULL pointer dereference, address: 0000000000000008
    PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP
    RIP: 0010:can_rx_register+0x12d/0x1e0
    Call Trace:
    <TASK>
    raw_enable_filters+0x8d/0x120
    raw_enable_allfilters+0x3b/0x130
    raw_bind+0x118/0x4f0
    __sys_bind+0x163/0x1a0
    __x64_sys_bind+0x1e/0x30
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    </TASK>
    
    Fixes: 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Reviewed-by: Marc Kleine-Budde <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: dev: fix skb drop check [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Wed Nov 2 10:54:31 2022 +0100

    can: dev: fix skb drop check
    
    commit ae64438be1923e3c1102d90fd41db7afcfaf54cc upstream.
    
    In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only
    mode") the priv->ctrlmode element is read even on virtual CAN
    interfaces that do not create the struct can_priv at startup. This
    out-of-bounds read may lead to CAN frame drops for virtual CAN
    interfaces like vcan and vxcan.
    
    This patch mainly reverts the original commit and adds a new helper
    for CAN interface drivers that provide the required information in
    struct can_priv.
    
    Fixes: a6d190f8c767 ("can: skb: drop tx skb if in listen only mode")
    Reported-by: Dariusz Stojaczyk <[email protected]>
    Cc: Vincent Mailhol <[email protected]>
    Cc: Max Staudt <[email protected]>
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Acked-by: Vincent Mailhol <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Cc: [email protected] # 6.0.x
    [mkl: patch pch_can, too]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: fix tx state handling for echo tx processing [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Fri Nov 4 15:25:51 2022 +0100

    can: isotp: fix tx state handling for echo tx processing
    
    commit 866337865f3747c68a3e7bb837611e39cec1ecd6 upstream.
    
    In commit 4b7fe92c0690 ("can: isotp: add local echo tx processing for
    consecutive frames") the data flow for consecutive frames (CF) has been
    reworked to improve the reliability of long data transfers.
    
    This rework did not touch the transmission and the tx state changes of
    single frame (SF) transfers which likely led to the WARN in the
    isotp_tx_timer_handler() catching a wrong tx state. This patch makes use
    of the improved frame processing for SF frames and sets the ISOTP_SENDING
    state in isotp_sendmsg() within the cmpxchg() condition handling.
    
    A review of the state machine and the timer handling additionally revealed
    a missing echo timeout handling in the case of the burst mode in
    isotp_rcv_echo() and removes a potential timer configuration uncertainty
    in isotp_rcv_fc() when the receiver requests consecutive frames.
    
    Fixes: 4b7fe92c0690 ("can: isotp: add local echo tx processing for consecutive frames")
    Link: https://lore.kernel.org/linux-can/[email protected]om/T/#u
    Reported-by: Wei Chen <[email protected]>
    Cc: [email protected] # v6.0
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: j1939: j1939_send_one(): fix missing CAN header initialization [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Fri Nov 4 08:50:00 2022 +0100

    can: j1939: j1939_send_one(): fix missing CAN header initialization
    
    commit 3eb3d283e8579a22b81dd2ac3987b77465b2a22f upstream.
    
    The read access to struct canxl_frame::len inside of a j1939 created
    skbuff revealed a missing initialization of reserved and later filled
    elements in struct can_frame.
    
    This patch initializes the 8 byte CAN header with zero.
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Cc: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/linux-can/[email protected]
    Reported-by: [email protected]
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Cc: [email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: rcar_canfd: Add missing ECC error checks for channels 2-7 [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Fri Oct 28 12:06:45 2022 +0200

    can: rcar_canfd: Add missing ECC error checks for channels 2-7
    
    commit 8b043dfb3dc7c32f9c2c0c93e3c2de346ee5e358 upstream.
    
    When introducing support for R-Car V3U, which has 8 instead of 2
    channels, the ECC error bitmask was extended to take into account the
    extra channels, but rcar_canfd_global_error() was not updated to act
    upon the extra bits.
    
    Replace the RCANFD_GERFL_EEF[01] macros by a new macro that takes the
    channel number, fixing R-Car V3U while simplifying the code.
    
    Fixes: 45721c406dcf50d4 ("can: rcar_canfd: Add support for r8a779a0 SoC")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Biju Das <[email protected]>
    Link: https://lore.kernel.org/all/4edb2e[email protected]glider.be
    Cc: [email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
capabilities: fix undefined behavior in bit shift for CAP_TO_MASK [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Mon Oct 31 19:25:36 2022 +0800

    capabilities: fix undefined behavior in bit shift for CAP_TO_MASK
    
    [ Upstream commit 46653972e3ea64f79e7f8ae3aa41a4d3fdb70a13 ]
    
    Shifting signed 32-bit value by 31 bits is undefined, so changing
    significant bit to unsigned. The UBSAN warning calltrace like below:
    
    UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2
    left shift of 1 by 31 places cannot be represented in type 'int'
    Call Trace:
     <TASK>
     dump_stack_lvl+0x7d/0xa5
     dump_stack+0x15/0x1b
     ubsan_epilogue+0xe/0x4e
     __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
     cap_task_prctl+0x561/0x6f0
     security_task_prctl+0x5a/0xb0
     __x64_sys_prctl+0x61/0x8f0
     do_syscall_64+0x58/0x80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
     </TASK>
    
    Fixes: e338d263a76a ("Add 64-bit capability support to the kernel")
    Signed-off-by: Gaosheng Cui <[email protected]>
    Acked-by: Andrew G. Morgan <[email protected]>
    Reviewed-by: Serge Hallyn <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxgb4vf: shut down the adapter when t4vf_update_port_info() failed in cxgb4vf_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Nov 9 09:21:00 2022 +0800

    cxgb4vf: shut down the adapter when t4vf_update_port_info() failed in cxgb4vf_open()
    
    [ Upstream commit c6092ea1e6d7bd12acd881f6aa2b5054cd70e096 ]
    
    When t4vf_update_port_info() failed in cxgb4vf_open(), resources applied
    during adapter goes up are not cleared. Fix it. Only be compiled, not be
    tested.
    
    Fixes: 18d79f721e0a ("cxgb4vf: Update port information in cxgb4vf_open()")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl/region: Recycle region ids [+ + +]
Author: Dan Williams <[email protected]>
Date:   Thu Nov 3 17:31:00 2022 -0700

    cxl/region: Recycle region ids
    
    [ Upstream commit 8f401ec1c8975eabfe4c089de91cbe058deabf71 ]
    
    At region creation time the next region-id is atomically cached so that
    there is predictability of region device names. If that region is
    destroyed and then a new one is created the region id increments. That
    ends up looking like a memory leak, or is otherwise surprising that
    identifiers roll forward even after destroying all previously created
    regions.
    
    Try to reuse rather than free old region ids at region release time.
    
    While this fixes a cosmetic issue, the needlessly advancing memory
    region-id gives the appearance of a memory leak, hence the "Fixes" tag,
    but no "Cc: stable" tag.
    
    Cc: Ben Widawsky <[email protected]>
    Cc: Jonathan Cameron <[email protected]>
    Fixes: 779dd20cfb56 ("cxl/region: Add region creation support")
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Vishal Verma <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]ntel.com
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: apple-admac: Fix grabbing of channels in of_xlate [+ + +]
Author: Martin Povišer <[email protected]>
Date:   Wed Oct 19 15:23:23 2022 +0200

    dmaengine: apple-admac: Fix grabbing of channels in of_xlate
    
    [ Upstream commit 8454f880c24bca0d9d4bfb6ed4a4a5429a4d9b20 ]
    
    The of_xlate callback is supposed to return the channel after already
    having 'grabbed' it for private use, so fill that in.
    
    Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver")
    Signed-off-by: Martin Povišer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: at_hdmac: Check return code of dma_async_device_register [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:49 2022 +0300

    dmaengine: at_hdmac: Check return code of dma_async_device_register
    
    commit c47e6403fa099f200868d6b106701cb42d181d2b upstream.
    
    dma_async_device_register() can fail, check the return code and display an
    error.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Do not call the complete callback on device_terminate_all [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:39 2022 +0300

    dmaengine: at_hdmac: Do not call the complete callback on device_terminate_all
    
    commit f645f85ae1104f8bd882f962ac0a69a1070076dd upstream.
    
    The method was wrong because it violated the dmaengine API. For aborted
    transfers the complete callback should not be called. Fix the behavior and
    do not call the complete callback on device_terminate_all.
    
    Fixes: 808347f6a317 ("dmaengine: at_hdmac: add DMA slave transfers")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Don't allow CPU to reorder channel enable [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:47 2022 +0300

    dmaengine: at_hdmac: Don't allow CPU to reorder channel enable
    
    commit 580ee84405c27d6ed419abe4d2b3de1968abdafd upstream.
    
    at_hdmac uses __raw_writel for register writes. In the absence of a
    barrier, the CPU may reorder the register operations.
    Introduce a write memory barrier so that the CPU does not reorder the
    channel enable, thus the start of the transfer, without making sure that
    all the pre-required register fields are already written.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Don't start transactions at tx_submit level [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:36 2022 +0300

    dmaengine: at_hdmac: Don't start transactions at tx_submit level
    
    commit 7176a6a8982d311e50a7c1168868d26e65bbba19 upstream.
    
    tx_submit is supposed to push the current transaction descriptor to a
    pending queue, waiting for issue_pending() to be called. issue_pending()
    must start the transfer, not tx_submit(), thus remove atc_dostart() from
    atc_tx_submit(). Clients of at_xdmac that assume that tx_submit() starts
    the transfer must be updated and call dma_async_issue_pending() if they
    miss to call it.
    The vdbg print was moved to after the lock is released. It is desirable to
    do the prints without the lock held if possible, and because the if
    statement disappears there's no reason why to do the print while holding
    the lock.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix at_lli struct definition [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:35 2022 +0300

    dmaengine: at_hdmac: Fix at_lli struct definition
    
    commit f1171bbdd2ba2a50ee64bb198a78c268a5baf5f1 upstream.
    
    Those hardware registers are all of 32 bits, while dma_addr_t ca be of
    type u64 or u32 depending on CONFIG_ARCH_DMA_ADDR_T_64BIT. Force u32 to
    comply with what the hardware expects.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix completion of unissued descriptor in case of errors [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:46 2022 +0300

    dmaengine: at_hdmac: Fix completion of unissued descriptor in case of errors
    
    commit ef2cb4f0ce479f77607b04c4b0414bf32f863ee8 upstream.
    
    In case the controller detected an error, the code took the chance to move
    all the queued (submitted) descriptors to the active (issued) list. This
    was wrong as if there were any descriptors in the submitted list they were
    moved to the issued list without actually issuing them to the controller,
    thus a completion could be raised without even fireing the descriptor.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix concurrency over descriptor [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:42 2022 +0300

    dmaengine: at_hdmac: Fix concurrency over descriptor
    
    commit 06988949df8c3007ad82036d3606d8ae72ed9000 upstream.
    
    The descriptor was added to the free_list before calling the callback,
    which could result in reissuing of the same descriptor and calling of a
    single callback for both. Move the decriptor to the free list after the
    callback is invoked.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix concurrency over the active list [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:44 2022 +0300

    dmaengine: at_hdmac: Fix concurrency over the active list
    
    commit 03ed9ba357cc78116164b90b87f45eacab60b561 upstream.
    
    The tasklet (atc_advance_work()) did not held the channel lock when
    retrieving the first active descriptor, causing concurrency problems if
    issue_pending() was called in between. If issue_pending() was called
    exactly after the lock was released in the tasklet (atc_advance_work()),
    atc_chain_complete() could complete a descriptor for which the controller
    has not yet raised an interrupt.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix concurrency problems by removing atc_complete_all() [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:41 2022 +0300

    dmaengine: at_hdmac: Fix concurrency problems by removing atc_complete_all()
    
    commit c6babed879fbe82796a601bf097649e07382db46 upstream.
    
    atc_complete_all() had concurrency bugs, thus remove it:
    1/ atc_complete_all() in its entirety was buggy, as when the atchan->queue
    list (the one that contains descriptors that are not yet issued to the
    hardware) contained descriptors, it fired just the first from the
    atchan->queue, but moved all the desc from atchan->queue to
    atchan->active_list and considered them all as fired. This could result in
    calling the completion of a descriptor that was not yet issued to the
    hardware.
    2/ when in tasklet at atc_advance_work() time, atchan->active_list was
    queried without holding the lock of the chan. This can result in
    atchan->active_list concurrency problems between the tasklet and
    issue_pending().
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix descriptor handling when issuing it to hardware [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:45 2022 +0300

    dmaengine: at_hdmac: Fix descriptor handling when issuing it to hardware
    
    commit ba2423633ba646e1df20e30cb3cf35495c16f173 upstream.
    
    As it was before, the descriptor was issued to the hardware without adding
    it to the active (issued) list. This could result in a completion of other
    descriptor, or/and in the descriptor never being completed.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix impossible condition [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:48 2022 +0300

    dmaengine: at_hdmac: Fix impossible condition
    
    commit 28cbe5a0a46a6637adbda52337d7b2777fc04027 upstream.
    
    The iterator can not be greater than ATC_MAX_DSCR_TRIALS, as the for loop
    will stop when i == ATC_MAX_DSCR_TRIALS. While here, use the common "i"
    name for the iterator.
    
    Fixes: 93dce3a6434f ("dmaengine: at_hdmac: fix residue computation")
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Fix premature completion of desc in issue_pending [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:38 2022 +0300

    dmaengine: at_hdmac: Fix premature completion of desc in issue_pending
    
    commit fcd37565efdaffeac179d0f0ce980ac79bfdf569 upstream.
    
    Multiple calls to atc_issue_pending() could result in a premature
    completion of a descriptor from the atchan->active list, as the method
    always completed the first active descriptor from the list. Instead,
    issue_pending() should just take the first transaction descriptor from the
    pending queue, move it to active_list and start the transfer.
    
    Fixes: dc78baa2b90b ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Free the memset buf without holding the chan lock [+ + +]
Author: Tudor Ambarus <[email protected].com>
Date:   Tue Oct 25 12:02:43 2022 +0300

    dmaengine: at_hdmac: Free the memset buf without holding the chan lock
    
    commit 6ba826cbb57d675f447b59323204d1473bbd5593 upstream.
    
    There's no need to hold the channel lock when freeing the memset buf, as
    the operation has already completed. Free the memset buf without holding
    the channel lock.
    
    Fixes: 4d112426c344 ("dmaengine: hdmac: Add memset capabilities")
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Protect atchan->status with the channel lock [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:40 2022 +0300

    dmaengine: at_hdmac: Protect atchan->status with the channel lock
    
    commit 6e5ad28d16f082efeae3d0bd2e31f24bed218019 upstream.
    
    Now that the complete callback call was removed from
    device_terminate_all(), we can protect the atchan->status with the channel
    lock. The atomic bitops on atchan->status do not substitute proper locking
    on the status, as one could still modify the status after the lock was
    dropped in atc_terminate_all() but before the atomic bitops were executed.
    
    Fixes: 078a6506141a ("dmaengine: at_hdmac: Fix deadlocks")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: at_hdmac: Start transfer for cyclic channels in issue_pending [+ + +]
Author: Tudor Ambarus <[email protected]>
Date:   Tue Oct 25 12:02:37 2022 +0300

    dmaengine: at_hdmac: Start transfer for cyclic channels in issue_pending
    
    commit 8a47221fc28417ff8a32a4f92d4448a56c3cf7e1 upstream.
    
    Cyclic channels must too call issue_pending in order to start a transfer.
    Start the transfer in issue_pending regardless of the type of channel.
    This wrongly worked before, because in the past the transfer was started
    at tx_submit level when only a desc in the transfer list.
    
    Fixes: 53830cc75974 ("dmaengine: at_hdmac: add cyclic DMA operation support")
    Reported-by: Peter Rosin <[email protected]>
    Signed-off-by: Tudor Ambarus <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Acked-by: Nicolas Ferre <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: idxd: Do not enable user type Work Queue without Shared Virtual Addressing [+ + +]
Author: Fenghua Yu <[email protected]>
Date:   Fri Oct 14 15:25:41 2022 -0700

    dmaengine: idxd: Do not enable user type Work Queue without Shared Virtual Addressing
    
    commit 0ec8ce07394442d722806fe61b901a5b2b17249d upstream.
    
    When the idxd_user_drv driver is bound to a Work Queue (WQ) device
    without IOMMU or with IOMMU Passthrough without Shared Virtual
    Addressing (SVA), the application gains direct access to physical
    memory via the device by programming physical address to a submitted
    descriptor. This allows direct userspace read and write access to
    arbitrary physical memory. This is inconsistent with the security
    goals of a good kernel API.
    
    Unlike vfio_pci driver, the IDXD char device driver does not provide any
    ways to pin user pages and translate the address from user VA to IOVA or
    PA without IOMMU SVA. Therefore the application has no way to instruct the
    device to perform DMA function. This makes the char device not usable for
    normal application usage.
    
    Since user type WQ without SVA cannot be used for normal application usage
    and presents the security issue, bind idxd_user_drv driver and enable user
    type WQ only when SVA is enabled (i.e. user PASID is enabled).
    
    Fixes: 448c3de8ac83 ("dmaengine: idxd: create user driver for wq 'device'")
    Cc: [email protected]
    Suggested-by: Arjan Van De Ven <[email protected]>
    Signed-off-by: Fenghua Yu <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Jerry Snitselaar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: idxd: Fix max batch size for Intel IAA [+ + +]
Author: Xiaochen Shen <[email protected]>
Date:   Sat Oct 1 04:15:27 2022 +0800

    dmaengine: idxd: Fix max batch size for Intel IAA
    
    [ Upstream commit e8dbd6445dd6b38c4c50410a86f13158486ee99a ]
    
    >From Intel IAA spec [1], Intel IAA does not support batch processing.
    
    Two batch related default values for IAA are incorrect in current code:
    (1) The max batch size of device is set during device initialization,
        that indicates batch is supported. It should be always 0 on IAA.
    (2) The max batch size of work queue is set to WQ_DEFAULT_MAX_BATCH (32)
        as the default value regardless of Intel DSA or IAA device during
        work queue setup and cleanup. It should be always 0 on IAA.
    
    Fix the issues by setting the max batch size of device and max batch
    size of work queue to 0 on IAA device, that means batch is not
    supported.
    
    [1]: https://cdrdv2.intel.com/v1/dl/getContent/721858
    
    Fixes: 23084545dbb0 ("dmaengine: idxd: set max_xfer and max_batch for RO device")
    Fixes: 92452a72ebdf ("dmaengine: idxd: set defaults for wq configs")
    Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators")
    Signed-off-by: Xiaochen Shen <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Fenghua Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: idxd: fix RO device state error after been disabled/reset [+ + +]
Author: Fengqian Gao <[email protected]>
Date:   Fri Sep 30 11:28:35 2022 +0800

    dmaengine: idxd: fix RO device state error after been disabled/reset
    
    [ Upstream commit 0b8c97a1d8c1bb6a853b8bb1778e8fef17b86fc9 ]
    
    When IDXD is not configurable, that means its WQ, engine, and group
    configurations cannot be changed. But it can be disabled and its state
    should be set as disabled regardless it's configurable or not.
    
    Fix this by setting device state IDXD_DEV_DISABLED for read-only device
    as well in idxd_device_clear_state().
    
    Fixes: cf4ac3fef338 ("dmaengine: idxd: fix lockdep warning on device driver removal")
    Signed-off-by: Fengqian Gao <[email protected]>
    Reviewed-by: Xiaochen Shen <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Reviewed-by: Fenghua Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon Oct 24 21:50:09 2022 +0200

    dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()
    
    [ Upstream commit 081195d17a0c4c636da2b869bd5809d42e8cbb13 ]
    
    A clk_prepare_enable() call in the probe is not balanced by a corresponding
    clk_disable_unprepare() in the remove function.
    
    Add the missing call.
    
    Fixes: 3cd2c313f1d6 ("dmaengine: mv_xor_v2: Fix clock resource by adding a register clock")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/r/e9e3837a680[email protected]wanadoo.fr
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: pxa_dma: use platform_get_irq_optional [+ + +]
Author: Doug Brown <[email protected]>
Date:   Mon Sep 5 17:07:09 2022 -0700

    dmaengine: pxa_dma: use platform_get_irq_optional
    
    [ Upstream commit b3d726cb8497c6b12106fd617d46eef11763ea86 ]
    
    The first IRQ is required, but IRQs 1 through (nb_phy_chans - 1) are
    optional, because on some platforms (e.g. PXA168) there is a single IRQ
    shared between all channels.
    
    This change inhibits a flood of "IRQ index # not found" messages at
    startup. Tested on a PXA168-based device.
    
    Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
    Signed-off-by: Doug Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: stm32-dma: fix potential race between pause and resume [+ + +]
Author: Amelie Delaunay <[email protected]>
Date:   Mon Oct 24 10:36:11 2022 +0200

    dmaengine: stm32-dma: fix potential race between pause and resume
    
    [ Upstream commit 140fd5e74a1cc7413df88c735fff5ec64d33c1d3 ]
    
    When disabling dma channel, a TCF flag is set and as TCIE is enabled, an
    interrupt is raised.
    On a busy system, the interrupt may have latency and the user can ask for
    dmaengine_resume while stm32-dma driver has not yet managed the complete
    pause (backup of registers to restore state in resume).
    To avoid such a case, instead of waiting the interrupt to backup the
    registers, do it just after disabling the channel and discard Transfer
    Complete interrupt in case the channel is paused.
    
    Fixes: 099a9a94be0e ("dmaengine: stm32-dma: add device_pause/device_resume support")
    Signed-off-by: Amelie Delaunay <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dmaengine: ti: k3-udma-glue: fix memory leak when register device fail [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Thu Oct 20 14:28:27 2022 +0800

    dmaengine: ti: k3-udma-glue: fix memory leak when register device fail
    
    [ Upstream commit ac2b9f34f02052709aea7b34bb2a165e1853eb41 ]
    
    If device_register() fails, it should call put_device() to give
    up reference, the name allocated in dev_set_name() can be freed
    in callback function kobject_cleanup().
    
    Fixes: 5b65781d06ea ("dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA")
    Signed-off-by: Yang Yingliang <[email protected]>
    Acked-by: Peter Ujfalusi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmanegine: idxd: reformat opcap output to match bitmap_parse() input [+ + +]
Author: Dave Jiang <[email protected]>
Date:   Sat Sep 17 09:12:19 2022 -0700

    dmanegine: idxd: reformat opcap output to match bitmap_parse() input
    
    [ Upstream commit a8563a33a5e26064061f2fb34215c97f0e2995f4 ]
    
    To make input and output consistent and prepping for the per WQ operation
    configuration support, change the output of opcap display to match the
    input that is expected by bitmap_parse() helper function. The output will
    be a bitmap with field width as the number of bits using the %*pb format
    specifier for printk() family.
    
    Signed-off-by: Dave Jiang <[email protected]>
    Co-developed-by: Fenghua Yu <[email protected]>
    Signed-off-by: Fenghua Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Stable-dep-of: e8dbd6445dd6 ("dmaengine: idxd: Fix max batch size for Intel IAA")
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers: net: xgene: disable napi when register irq failed in xgene_enet_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Mon Nov 7 12:30:32 2022 +0800

    drivers: net: xgene: disable napi when register irq failed in xgene_enet_open()
    
    [ Upstream commit ce9e57feeed81d17d5e80ed86f516ff0d39c3867 ]
    
    When failed to register irq in xgene_enet_open() for opening device,
    napi isn't disabled. When open xgene device next time, it will reports
    a invalid opcode issue. Fix it. Only be compiled, not be tested.
    
    Fixes: aeb20b6b3f4e ("drivers: net: xgene: fix: ifconfig up/down crash")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Acquire FCLK DPM levels on DCN32 [+ + +]
Author: Dillon Varone <[email protected]>
Date:   Wed Sep 28 15:44:38 2022 -0400

    drm/amd/display: Acquire FCLK DPM levels on DCN32
    
    [ Upstream commit d6170e418d1d3ae7e98cb6d96d1444e880131bbf ]
    
    [Why & How]
    Acquire FCLK DPM levels to properly construct DML clock limits. Further
    add new logic to keep number of indices for each clock in clk_mgr.
    
    Tested-by: Daniel Wheeler <[email protected]>
    Reviewed-by: Jun Lei <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Dillon Varone <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: e59843c4cdd6 ("drm/amd/display: Limit dcn32 to 1950Mhz display clock")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix reg timeout in enc314_enable_fifo [+ + +]
Author: Nicholas Kazlauskas <[email protected]>
Date:   Thu Oct 27 15:34:33 2022 -0400

    drm/amd/display: Fix reg timeout in enc314_enable_fifo
    
    commit ce62198d8b62734a985d22652e75a649be052390 upstream.
    
    [Why]
    The link enablement sequence can end up resetting the encoder while
    the PHY symclk isn't yet on.
    
    This means that waiting for symclk on will timeout, along with the reset
    bit never asserting high.
    
    This causes unnecessary delay when enabling the link and produces a
    warning affecting multiple IGT tests.
    
    [How]
    Don't wait for the symclk to be on here because firmware already does.
    
    Don't wait for reset if we know the symclk isn't on.
    
    Split the reset into a helper function that checks the bit and decides
    whether or not a delay is sufficient.
    
    Reviewed-by: Roman Li <[email protected]>
    Acked-by: Alan Liu <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.0.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Limit dcn32 to 1950Mhz display clock [+ + +]
Author: Jun Lei <[email protected]>
Date:   Thu Oct 20 11:46:44 2022 -0400

    drm/amd/display: Limit dcn32 to 1950Mhz display clock
    
    [ Upstream commit e59843c4cdd68a369591630088171eeacce9859f ]
    
    [why]
    Hardware team recommends we limit dispclock to 1950Mhz for all DCN3.2.x
    
    [how]
    Limit to 1950 when initializing clocks.
    
    Tested-by: Mark Broadworth <[email protected]>
    Reviewed-by: Alvin Lee <[email protected]>
    Acked-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Jun Lei <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.0.x
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Set memclk levels to be at least 1 for dcn32 [+ + +]
Author: Dillon Varone <[email protected]>
Date:   Thu Oct 20 11:46:48 2022 -0400

    drm/amd/display: Set memclk levels to be at least 1 for dcn32
    
    [ Upstream commit 6cb5cec16c380be4cf9776a8c23b72e9fe742fd1 ]
    
    [Why]
    Cannot report 0 memclk levels even when SMU does not provide any.
    
    [How]
    When memclk levels reported by SMU is 0, set levels to 1.
    
    Tested-by: Mark Broadworth <[email protected]>
    Reviewed-by: Martin Leung <[email protected]>
    Acked-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Dillon Varone <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.0.x
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Update SR watermarks for DCN314 [+ + +]
Author: Nicholas Kazlauskas <[email protected]>
Date:   Tue Oct 25 11:26:04 2022 -0400

    drm/amd/display: Update SR watermarks for DCN314
    
    commit 632d06985235d988c9d7e6eec8fa655be0761fd0 upstream.
    
    [Why & How]
    New values requested by hardware after fine-tuning.
    Update for all memory types.
    
    Reviewed-by: Jun Lei <[email protected]>
    Acked-by: Alan Liu <[email protected]>
    Signed-off-by: Nicholas Kazlauskas <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.0.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd/pm: update SMU IP v13.0.4 msg interface header [+ + +]
Author: Tim Huang <[email protected]>
Date:   Thu Nov 3 11:05:19 2022 +0800

    drm/amd/pm: update SMU IP v13.0.4 msg interface header
    
    commit bc66c9ab162d2a633ee3eb864d7bc2369e79c1e4 upstream.
    
    Some of the unused messages that were used earlier in development have
    been freed up as spare messages, no intended functional changes.
    
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Tim Huang <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Reviewed-by: Yifan Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.0.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: disable BACO on special BEIGE_GOBY card [+ + +]
Author: Guchun Chen <[email protected]>
Date:   Mon Nov 7 16:46:59 2022 +0800

    drm/amdgpu: disable BACO on special BEIGE_GOBY card
    
    commit 0c85c067c9d9d7a1b2cc2e01a236d5d0d4a872b5 upstream.
    
    Still avoid intermittent failure.
    
    Signed-off-by: Guchun Chen <[email protected]>
    Reviewed-by: Lijo Lazar <[email protected]>
    Acked-by: Evan Quan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: Fix the lpfn checking condition in drm buddy [+ + +]
Author: Ma Jun <[email protected]>
Date:   Wed Sep 14 20:53:31 2022 +0800

    drm/amdgpu: Fix the lpfn checking condition in drm buddy
    
    commit e0b26b9482461e9528552f54fa662c2269f75b3f upstream.
    
    Because the value of man->size is changed during suspend/resume process,
    use mgr->mm.size instead of man->size here for lpfn checking.
    
    Signed-off-by: Ma Jun <[email protected]>
    Suggested-by: Christian König <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Christian König <[email protected]>
    Cc: "Limonciello, Mario" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: workaround for TLB seq race [+ + +]
Author: Christian König <[email protected]>
Date:   Wed Nov 2 14:55:13 2022 +0100

    drm/amdgpu: workaround for TLB seq race
    
    commit 77c092e054262b594614bad5e5f47e57c5d29639 upstream.
    
    It can happen that we query the sequence value before the callback
    had a chance to run.
    
    Workaround that by grabbing the fence lock and releasing it again.
    Should be replaced by hw handling soon.
    
    Signed-off-by: Christian König <[email protected]>
    CC: [email protected] # 5.19+
    Fixes: 5255e146c99a6 ("drm/amdgpu: rework TLB flushing")
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2113
    Acked-by: Alex Deucher <[email protected]>
    Acked-by: Philip Yang <[email protected]>
    Tested-by: Stefan Springer <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdkfd: Fix error handling in criu_checkpoint [+ + +]
Author: Felix Kuehling <[email protected]>
Date:   Tue Nov 1 15:02:48 2022 -0400

    drm/amdkfd: Fix error handling in criu_checkpoint
    
    commit b91c23e099f0b65d62159da13458c5eefa76083f upstream.
    
    Checkpoint BOs last. That way we don't need to close dmabuf FDs if
    something else fails later. This avoids problematic access to user mode
    memory in the error handling code path.
    
    criu_checkpoint_bos has its own error handling and cleanup that does not
    depend on access to user memory.
    
    In the private data, keep BOs before the remaining objects. This is
    necessary to restore things in the correct order as restoring events
    depends on the events-page BO being restored first.
    
    Fixes: be072b06c739 ("drm/amdkfd: CRIU export BOs as prime dmabuf objects")
    Reported-by: Jann Horn <[email protected]>
    CC: Rajneesh Bhardwaj <[email protected]>
    Signed-off-by: Felix Kuehling <[email protected]>
    Reviewed-and-tested-by: Rajneesh Bhardwaj <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdkfd: Fix error handling in kfd_criu_restore_events [+ + +]
Author: Felix Kuehling <[email protected]>
Date:   Thu Nov 3 17:01:46 2022 -0400

    drm/amdkfd: Fix error handling in kfd_criu_restore_events
    
    commit 66f7903779fbbc620bf1040017e4833ef6a0b541 upstream.
    
    mutex_unlock before the exit label because all the error code paths that
    jump there didn't take that lock. This fixes unbalanced locking errors
    in case of restore errors.
    
    Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events")
    Signed-off-by: Felix Kuehling <[email protected]>
    Reviewed-by: Rajneesh Bhardwaj <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram() [+ + +]
Author: Yang Li <[email protected]>
Date:   Wed Oct 26 10:00:54 2022 +0800

    drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
    
    [ Upstream commit 5b994354af3cab770bf13386469c5725713679af ]
    
    ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced.
    
    Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
    Reported-by: Abaci Robot <[email protected]>
    Signed-off-by: Yang Li <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdkfd: handle CPU fault on COW mapping [+ + +]
Author: Philip Yang <[email protected]>
Date:   Wed Sep 7 12:30:12 2022 -0400

    drm/amdkfd: handle CPU fault on COW mapping
    
    [ Upstream commit e1f84eef313f4820cca068a238c645d0a38c6a9b ]
    
    If CPU page fault in a page with zone_device_data svm_bo from another
    process, that means it is COW mapping in the child process and the
    range is migrated to VRAM by parent process. Migrate the parent
    process range back to system memory to recover the CPU page fault.
    
    Signed-off-by: Philip Yang <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 5b994354af3c ("drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdkfd: Migrate in CPU page fault use current mm [+ + +]
Author: Philip Yang <[email protected]>
Date:   Thu Sep 8 17:56:09 2022 -0400

    drm/amdkfd: Migrate in CPU page fault use current mm
    
    commit 3a876060892ba52dd67d197c78b955e62657d906 upstream.
    
    migrate_vma_setup shows below warning because we don't hold another
    process mm mmap_lock. We should use current vmf->vma->vm_mm instead, the
    caller already hold current mmap lock inside CPU page fault handler.
    
     WARNING: CPU: 10 PID: 3054 at include/linux/mmap_lock.h:155 find_vma
     Call Trace:
      walk_page_range+0x76/0x150
      migrate_vma_setup+0x18a/0x640
      svm_migrate_vram_to_ram+0x245/0xa10 [amdgpu]
      svm_migrate_to_ram+0x36f/0x470 [amdgpu]
      do_swap_page+0xcfe/0xec0
      __handle_mm_fault+0x96b/0x15e0
      handle_mm_fault+0x13f/0x3e0
      do_user_addr_fault+0x1e7/0x690
    
    Fixes: e1f84eef313f ("drm/amdkfd: handle CPU fault on COW mapping")
    Signed-off-by: Philip Yang <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/dmabuf: fix sg_table handling in map_dma_buf [+ + +]
Author: Matthew Auld <[email protected]>
Date:   Fri Oct 28 16:50:26 2022 +0100

    drm/i915/dmabuf: fix sg_table handling in map_dma_buf
    
    commit f90daa975911961b65070ec72bd7dd8d448f9ef7 upstream.
    
    We need to iterate over the original entries here for the sg_table,
    pulling out the struct page for each one, to be remapped. However
    currently this incorrectly iterates over the final dma mapped entries,
    which is likely just one gigantic sg entry if the iommu is enabled,
    leading to us only mapping the first struct page (and any physically
    contiguous pages following it), even if there is potentially lots more
    data to follow.
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
    Fixes: 1286ff739773 ("i915: add dmabuf/prime buffer sharing support.")
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Lionel Landwerlin <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: Ville Syrjälä <[email protected]>
    Cc: Michael J. Ruhl <[email protected]>
    Cc: <[email protected]> # v3.5+
    Reviewed-by: Michael J. Ruhl <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 28d52f99bbca7227008cf580c9194c9b3516968e)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/gvt: Add missing vfio_unregister_group_dev() call [+ + +]
Author: Jason Gunthorpe <[email protected]>
Date:   Thu Sep 29 14:48:35 2022 -0300

    drm/i915/gvt: Add missing vfio_unregister_group_dev() call
    
    commit f423fa1bc9fe1978e6b9f54927411b62cb43eb04 upstream.
    
    When converting to directly create the vfio_device the mdev driver has to
    put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
    vfio_unregister_group_dev() in the remove.
    
    This was missed for gvt, add it.
    
    Cc: [email protected]
    Fixes: 978cf586ac35 ("drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev")
    Reported-by: Alex Williamson <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alex Williamson <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]> # v6.0 backport
    Signed-off-by: Alex Williamson <[email protected]> # v6.0 backport
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/psr: Send update also on invalidate [+ + +]
Author: Jouni Högander <[email protected]>
Date:   Mon Oct 24 08:46:49 2022 +0300

    drm/i915/psr: Send update also on invalidate
    
    [ Upstream commit 4ff4ebac3f1378f4ba6e11fe5ad4a4ac590bb8a4 ]
    
    Currently we are observing mouse cursor stuttering when using
    xrandr --scaling=1.2x1.2. X scaling/transformation seems to be
    doing fronbuffer rendering. When moving mouse cursor X seems to
    perform several invalidates and only one DirtyFB. I.e. it seems
    to be assuming updates are sent to panel while drawing is done.
    
    Earlier we were disabling PSR in frontbuffer invalidate call back
    (when drawing in X started). PSR was re-enabled in frontbuffer
    flush callback (dirtyfb ioctl). This was working fine with X
    scaling/transformation. Now we are just enabling continuous full
    frame (cff) in PSR invalidate callback. Enabling cff doesn't
    trigger any updates. It just configures PSR to send full frame
    when updates are sent. I.e. there are no updates on screen before
    PSR flush callback is made. X seems to be doing several updates
    in frontbuffer before doing dirtyfb ioctl.
    
    Fix this by sending single update on every invalidate callback.
    
    Cc: José Roberto de Souza <[email protected]>
    Cc: Ville Syrjälä <[email protected]>
    Cc: Mika Kahola <[email protected]>
    
    Fixes: 805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations")
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6679
    Signed-off-by: Jouni Högander <[email protected]>
    Reported-by: Brian J. Tarricone <[email protected]>
    Tested-by: Brian J. Tarricone <[email protected]>
    Reviewed-by: Mika Kahola <[email protected]>
    Reviewed-by: José Roberto de Souza <[email protected]>
    Signed-off-by: José Roberto de Souza <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit d755f89220a2b49bc90b7b520bb6edeb4adb5f01)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Wed Oct 26 13:11:29 2022 +0300

    drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs
    
    [ Upstream commit 12caf46cf4fc92b1c3884cb363ace2e12732fd2f ]
    
    drm_mode_probed_add() is unhappy about being called w/o
    mode_config.mutex. Grab it during LVDS fixed mode setup
    to silence the WARNs.
    
    Cc: [email protected]
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
    Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
    Signed-off-by: Ville Syrjälä <[email protected]linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Jani Nikula <[email protected]>
    (cherry picked from commit a3cd4f447281c56377de2ee109327400eb00668d)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915: Allow more varied alternate fixed modes for panels [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Wed Aug 31 00:24:36 2022 +0300

    drm/i915: Allow more varied alternate fixed modes for panels
    
    [ Upstream commit a5810f551d0a8c83b4817b53a446bd115e7182ce ]
    
    On some systems the panel reports alternate modes with
    different blanking periods. If the EDID reports them and VBT
    doesn't tell us otherwise then I can't really see why they
    should be rejected. So allow their use for the purposes of
    static DRRS.
    
    For seamless DRRS we still require a much more exact match
    of course. But that logic only kicks in when selecting the
    downclock mode (or in the future when determining whether
    we can do a seamless refresh rate change due to a user
    modeset).
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6374
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Jani Nikula <[email protected]>
    Stable-dep-of: 12caf46cf4fc ("drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs")
    Signed-off-by: Sasha Levin <[email protected]>

drm/i915: Do not set cache_dirty for DGFX [+ + +]
Author: Niranjana Vishwanathapura <[email protected]>
Date:   Tue Nov 1 22:14:16 2022 -0700

    drm/i915: Do not set cache_dirty for DGFX
    
    [ Upstream commit 19b168136395150a4a6e011f944eb30d3d85094b ]
    
    Currently on DG1, which does not have LLC, we hit the below
    warning while rebinding an userptr invalidated object.
    
    WARNING: CPU: 4 PID: 13008 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:34 __i915_gem_object_set_pages+0x296/0x2d0 [i915]
    ...
    RIP: 0010:__i915_gem_object_set_pages+0x296/0x2d0 [i915]
    ...
    Call Trace:
     <TASK>
     i915_gem_userptr_get_pages+0x175/0x1a0 [i915]
     ____i915_gem_object_get_pages+0x32/0xb0 [i915]
     i915_gem_object_userptr_submit_init+0x286/0x470 [i915]
     eb_lookup_vmas+0x2ff/0xcf0 [i915]
     ? __intel_wakeref_get_first+0x55/0xb0 [i915]
     i915_gem_do_execbuffer+0x785/0x21d0 [i915]
     i915_gem_execbuffer2_ioctl+0xe7/0x3d0 [i915]
    
    We shouldn't be setting the obj->cache_dirty for DGFX,
    fix it.
    
    Fixes: d70af57944a1 ("drm/i915/shmem: ensure flush during swap-in on non-LLC")
    Suggested-by: Matthew Auld <[email protected]>
    Reported-by: Niranjana Vishwanathapura <[email protected]>
    Signed-off-by: Niranjana Vishwanathapura <[email protected]>
    Acked-by: Nirmoy Das <[email protected]>
    Reviewed-by: Matthew Auld <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 0aeec60c76ca2631696b4228f3fc99fe3a80013d)
    Signed-off-by: Tvrtko Ursulin <tvrtko.ursuli[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes() [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Tue Sep 27 21:06:13 2022 +0300

    drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes()
    
    [ Upstream commit d372ec94a018c3a19dad71e2ee3478126394d9fc ]
    
    Since commit a5810f551d0a ("drm/i915: Allow more varied alternate
    fixed modes for panels") intel_panel_add_edid_alt_fixed_modes()
    no longer considers vrr vs. drrs separately. So no reason to
    pass them as separate parameters either.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Jani Nikula <[email protected]>
    (cherry picked from commit eb89e83c152b122a94e79527d63cb7c79823c37e)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Stable-dep-of: 12caf46cf4fc ("drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vc4: Fix missing platform_unregister_drivers() call in vc4_drm_register() [+ + +]
Author: Yuan Can <[email protected]>
Date:   Thu Nov 3 01:47:05 2022 +0000

    drm/vc4: Fix missing platform_unregister_drivers() call in vc4_drm_register()
    
    [ Upstream commit cf53db768a8790fdaae2fa3a81322b080285f7e5 ]
    
    A problem about modprobe vc4 failed is triggered with the following log
    given:
    
     [  420.327987] Error: Driver 'vc4_hvs' is already registered, aborting...
     [  420.333904] failed to register platform driver vc4_hvs_driver [vc4]: -16
     modprobe: ERROR: could not insert 'vc4': Device or resource busy
    
    The reason is that vc4_drm_register() returns platform_driver_register()
    directly without checking its return value, if platform_driver_register()
    fails, it returns without unregistering all the vc4 drivers, resulting the
    vc4 can never be installed later.
    A simple call graph is shown as below:
    
     vc4_drm_register()
       platform_register_drivers() # all vc4 drivers are registered
       platform_driver_register()
         driver_register()
           bus_add_driver()
             priv = kzalloc(...) # OOM happened
       # return without unregister drivers
    
    Fixing this problem by checking the return value of
    platform_driver_register() and do platform_unregister_drivers() if
    error happened.
    
    Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
    Signed-off-by: Yuan Can <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/vc4: hdmi: Fix HSM clock too low on Pi4 [+ + +]
Author: [email protected] <[email protected]>
Date:   Fri Oct 21 15:13:39 2022 +0200

    drm/vc4: hdmi: Fix HSM clock too low on Pi4
    
    [ Upstream commit 3bc6a37f59f21a8bfaf74d0975b2eb0b2d52a065 ]
    
    Commit ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at
    runtime_resume") reintroduced the call to clk_set_min_rate in an attempt
    to fix the boot without a monitor connected on the RaspberryPi3.
    
    However, that introduced a regression breaking the display output
    entirely (black screen but no vblank timeout) on the Pi4.
    
    This is due to the fact that we now have in a typical modeset at boot,
    in vc4_hdmi_encoder_pre_crtc_configure(), we have a first call to
    clk_set_min_rate() asking for the minimum rate of the HSM clock for our
    given resolution, and then a call to pm_runtime_resume_and_get(). We
    will thus execute vc4_hdmi_runtime_resume() which, since the commit
    mentioned above, will call clk_set_min_rate() a second time with the
    absolute minimum rate we want to enforce on the HSM clock.
    
    We're thus effectively erasing the minimum mandated by the mode we're
    trying to set. The fact that only the Pi4 is affected is due to the fact
    that it uses a different clock driver that tries to minimize the HSM
    clock at all time. It will thus lower the HSM clock rate to 120MHz on
    the second clk_set_min_rate() call.
    
    The Pi3 doesn't use the same driver and will not change the frequency on
    the second clk_set_min_rate() call since it's still within the new
    boundaries and it doesn't have the code to minimize the clock rate as
    needed. So even though the boundaries are still off, the clock rate is
    still the right one for our given mode, so everything works.
    
    There is a lot of moving parts, so I couldn't find any obvious
    solution:
    
      - Reverting the original is not an option, as that would break the Pi3
        again.
    
      - We can't move the clk_set_min_rate() call in _pre_crtc_configure()
        since because, on the Pi3, the HSM clock has the CLK_SET_RATE_GATE
        flag which prevents the clock rate from being changed after it's
        been enabled. Our calls to clk_set_min_rate() can change it, so they
        need to be done before clk_prepare_enable().
    
      - We can't remove the call to clk_prepare_enable() from the
        runtime_resume hook to put it into _pre_crtc_configure() either,
        since we need that clock to be enabled to access the registers, and
        we can't count on the fact that the display will be active in all
        situations (doing any CEC operation, or listing the modes while
        inactive are valid for example()).
    
      - We can't drop the call to clk_set_min_rate() in
        _pre_crtc_configure() since we would need to still enforce the
        minimum rate for a given resolution, and runtime_resume doesn't have
        access to the current mode, if there's any.
    
      - We can't copy the TMDS character rate into vc4_hdmi and reuse it
        since, because it's part of the KMS atomic state, it needs to be
        protected by a mutex. Unfortunately, some functions (CEC operations,
        mostly) can be reentrant (through the CEC framework) and still need
        a pm_runtime_get.
    
    However, we can work around this issue by leveraging the fact that the
    clk_set_min_rate() calls set boundaries for its given struct clk, and
    that each different clk_get() call will return a different instance of
    struct clk. The clock framework will then aggregate the boundaries for
    each struct clk instances linked to a given clock, plus its hardware
    boundaries, and will use that.
    
    We can thus get an extra HSM clock user for runtime_pm use only, and use
    our different clock instances depending on the context: runtime_pm will
    use its own to set the absolute minimum clock setup so that we never
    lock the CPU waiting for a register access, and the modeset part will
    set its requirement for the current resolution. And we let the CCF do
    the coordination.
    
    It's not an ideal solution, but it's fairly unintrusive and doesn't
    really change any part of the logic so it looks like a rather safe fix.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2136234
    Fixes: ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume")
    Reported-by: Peter Robinson <[email protected]>
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Tested-by: Peter Robinson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Maxime Ripard <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: net: tsnep: Fix typo on generic nvmem property [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Fri Nov 4 17:21:47 2022 +0100

    dt-bindings: net: tsnep: Fix typo on generic nvmem property
    
    [ Upstream commit ec683f02a150b9c4428f08accd387c8c216ea0e5 ]
    
    While working on the nvmem description I figured out this file had the
    "nvmem-cell-names" property name misspelled. Fix the typo, as
    "nvmem-cells-names" has never existed.
    
    Fixes: 603094b2cdb7 ("dt-bindings: net: Add tsnep Ethernet controller")
    Signed-off-by: Miquel Raynal <[email protected]>
    Reviewed-by: Gerhard Engleder <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
eth: sp7021: drop free_netdev() from spl2sw_init_netdev() [+ + +]
Author: Wei Yongjun <[email protected]>
Date:   Wed Nov 9 15:01:16 2022 +0000

    eth: sp7021: drop free_netdev() from spl2sw_init_netdev()
    
    [ Upstream commit de91b3197d15172407608b2c357aab7ac1451e2b ]
    
    It's not necessary to free netdev allocated with devm_alloc_etherdev()
    and using free_netdev() leads to double free.
    
    Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021")
    Signed-off-by: Wei Yongjun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ethernet: s2io: disable napi when start nic failed in s2io_card_up() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Nov 9 10:37:41 2022 +0800

    ethernet: s2io: disable napi when start nic failed in s2io_card_up()
    
    [ Upstream commit 0348c1ab980c1d43fb37b758d4b760990c066cb5 ]
    
    When failed to start nic or add interrupt service routine in
    s2io_card_up() for opening device, napi isn't disabled. When open
    s2io device next time, it will trigger a BUG_ON()in napi_enable().
    Compile tested only.
    
    Fixes: 5f490c968056 ("S2io: Fixed synchronization between scheduling of napi with card reset and close")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ethernet: tundra: free irq when alloc ring failed in tsi108_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Nov 9 12:40:16 2022 +0800

    ethernet: tundra: free irq when alloc ring failed in tsi108_open()
    
    [ Upstream commit acce40037041f97baad18142bb253064491ebde3 ]
    
    When alloc tx/rx ring failed in tsi108_open(), it doesn't free irq. Fix
    it.
    
    Fixes: 5e123b844a1c ("[PATCH] Add tsi108/9 On Chip Ethernet device driver support")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hamradio: fix issue of dev reference count leakage in bpq_device_event() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Thu Nov 3 17:09:05 2022 +0800

    hamradio: fix issue of dev reference count leakage in bpq_device_event()
    
    [ Upstream commit 85cbaf032d3cd9f595152625eda5d4ecb1d6d78d ]
    
    When following tests are performed, it will cause dev reference counting
    leakage.
    a)ip link add bond2 type bond mode balance-rr
    b)ip link set bond2 up
    c)ifenslave -f bond2 rose1
    d)ip link del bond2
    
    When new bond device is created, the default type of the bond device is
    ether. And the bond device is up, bpq_device_event() receives the message
    and creates a new bpq device. In this case, the reference count value of
    dev is hold once. But after "ifenslave -f bond2 rose1" command is
    executed, the type of the bond device is changed to rose. When the bond
    device is unregistered, bpq_device_event() will not put the dev reference
    count.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: hyperv: fix possible memory leak in mousevsc_probe() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Fri Oct 28 21:40:43 2022 +0800

    HID: hyperv: fix possible memory leak in mousevsc_probe()
    
    [ Upstream commit b5bcb94b0954a026bbd671741fdb00e7141f9c91 ]
    
    If hid_add_device() returns error, it should call hid_destroy_device()
    to free hid_dev which is allocated in hid_allocate_device().
    
    Fixes: 74c4fb058083 ("HID: hv_mouse: Properly add the hid device")
    Signed-off-by: Yang Yingliang <[email protected]>
    Reviewed-by: Wei Liu <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: wacom: Fix logic used for 3rd barrel switch emulation [+ + +]
Author: Jason Gerecke <[email protected]>
Date:   Thu Nov 3 10:33:04 2022 -0700

    HID: wacom: Fix logic used for 3rd barrel switch emulation
    
    commit f77810f744139572a63e5a85ab6a8c10c2d44fb1 upstream.
    
    When support was added for devices using an explicit 3rd barrel switch,
    the logic used by devices emulating this feature was broken. The 'if'
    statement / block that was introduced only handles the case where the
    button is pressed (i.e. 'barrelswitch' and 'barrelswitch2' are both set)
    but not the case where it is released (i.e. one or both being cleared).
    This results in a BTN_STYLUS3 "down" event being sent when the button
    is pressed, but no "up" event ever being sent afterwards.
    
    This patch restores the previously-used logic for determining button
    states in the emulated case so that switches are reported correctly
    again.
    
    Link: https://github.com/linuxwacom/xf86-input-wacom/issues/292
    Fixes: 6d09085b38e5 ("HID: wacom: Adding Support for new usages")
    CC: [email protected] #v5.19+
    Signed-off-by: Jason Gerecke <[email protected]>
    Tested-by: Joshua Dickens <[email protected]>
    Reviewed-by: Ping Cheng <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwspinlock: qcom: correct MMIO max register for newer SoCs [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 9 11:20:23 2022 +0200

    hwspinlock: qcom: correct MMIO max register for newer SoCs
    
    [ Upstream commit 90cb380f9ceb811059340d06ff5fd0c0e93ecbe1 ]
    
    Newer ARMv8 Qualcomm SoCs using 0x1000 register stride have maximum
    register 0x20000 (32 mutexes * 0x1000).
    
    Fixes: 7a1e6fb1c606 ("hwspinlock: qcom: Allow mmio usage in addition to syscon")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
iavf: Fix VF driver counting VLAN 0 filters [+ + +]
Author: Michal Jaron <[email protected]>
Date:   Fri Oct 14 10:45:37 2022 +0200

    iavf: Fix VF driver counting VLAN 0 filters
    
    [ Upstream commit 0e710a3ffd0caaf23b8791b041e8792f252f8e4f ]
    
    VF driver mistakenly counts VLAN 0 filters, when no PF driver
    counts them.
    Do not count VLAN 0 filters, when VLAN_V2 is engaged.
    Counting those filters in, will affect filters size by -1, when
    sending batched VLAN addition message.
    
    Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection")
    Signed-off-by: Przemyslaw Patynowski <[email protected]>
    Signed-off-by: Michal Jaron <[email protected]>
    Signed-off-by: Kamil Maziarz <[email protected]>
    Tested-by: Konrad Jankowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: Fix spurious interrupt during removal of trusted VF [+ + +]
Author: Norbert Zulinski <[email protected]>
Date:   Mon Oct 10 10:22:22 2022 -0400

    ice: Fix spurious interrupt during removal of trusted VF
    
    [ Upstream commit f23df5220d2bf8d5e639f074b76f206a736d09e1 ]
    
    Previously, during removal of trusted VF when VF is down there was
    number of spurious interrupt equal to number of queues on VF.
    
    Add check if VF already has inactive queues. If VF is disabled and
    has inactive rx queues then do not disable rx queues.
    Add check in ice_vsi_stop_tx_ring if it's VF's vsi and if VF is
    disabled.
    
    Fixes: efe41860008e ("ice: Fix memory corruption in VF driver")
    Signed-off-by: Norbert Zulinski <[email protected]>
    Signed-off-by: Mateusz Palczewski <[email protected]>
    Tested-by: Konrad Jankowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring: check for rollover of buffer ID when providing buffers [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Thu Nov 10 10:50:55 2022 -0700

    io_uring: check for rollover of buffer ID when providing buffers
    
    commit 3851d25c75ed03117268a8feb34adca5a843a126 upstream.
    
    We already check if the chosen starting offset for the buffer IDs fit
    within an unsigned short, as 65535 is the maximum value for a provided
    buffer. But if the caller asks to add N buffers at offset M, and M + N
    would exceed the size of the unsigned short, we simply add buffers with
    wrapping around the ID.
    
    This is not necessarily a bug and could in fact be a valid use case, but
    it seems confusing and inconsistent with the initial check for starting
    offset. Let's check for wrap consistently, and error the addition if we
    do need to wrap.
    
    Reported-by: Olivier Langlois <[email protected]>
    Link: https://github.com/axboe/liburing/issues/726
    Cc: [email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network [+ + +]
Author: Alexander Potapenko <[email protected]>
Date:   Fri Nov 4 11:32:16 2022 +0100

    ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network
    
    [ Upstream commit c23fb2c82267638f9d206cb96bb93e1f93ad7828 ]
    
    When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved
    remained uninitialized, resulting in a 1-byte infoleak:
    
      BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841
       __netdev_start_xmit ./include/linux/netdevice.h:4841
       netdev_start_xmit ./include/linux/netdevice.h:4857
       xmit_one net/core/dev.c:3590
       dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606
       __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256
       dev_queue_xmit ./include/linux/netdevice.h:3009
       __netlink_deliver_tap_skb net/netlink/af_netlink.c:307
       __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325
       netlink_deliver_tap net/netlink/af_netlink.c:338
       __netlink_sendskb net/netlink/af_netlink.c:1263
       netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272
       netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360
       nlmsg_unicast ./include/net/netlink.h:1061
       rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758
       ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628
       rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082
      ...
      Uninit was created at:
       slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742
       slab_alloc_node mm/slub.c:3398
       __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437
       __do_kmalloc_node mm/slab_common.c:954
       __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975
       kmalloc_reserve net/core/skbuff.c:437
       __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509
       alloc_skb ./include/linux/skbuff.h:1267
       nlmsg_new ./include/net/netlink.h:964
       ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608
       rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082
       netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540
       rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109
       netlink_unicast_kernel net/netlink/af_netlink.c:1319
       netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345
       netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921
      ...
    
    This patch ensures that the reserved field is always initialized.
    
    Reported-by: [email protected]tmail.com
    Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
    Signed-off-by: Alexander Potapenko <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: debugfs: Return retval of simple_attr_open() if it fails [+ + +]
Author: Hou Wenlong <[email protected]>
Date:   Mon Oct 17 11:06:10 2022 +0800

    KVM: debugfs: Return retval of simple_attr_open() if it fails
    
    [ Upstream commit 180418e2eb33be5c8d0b703c843e0ebc045aef80 ]
    
    Although simple_attr_open() fails only with -ENOMEM with current code
    base, it would be nicer to return retval of simple_attr_open() directly
    in kvm_debugfs_open().
    
    No functional change intended.
    
    Signed-off-by: Hou Wenlong <[email protected]>
    Message-Id: <69d64d9[email protected]antgroup.com>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: s390: pci: Fix allocation size of aift kzdev elements [+ + +]
Author: Rafael Mendonca <[email protected]>
Date:   Tue Oct 25 22:32:33 2022 -0300

    KVM: s390: pci: Fix allocation size of aift kzdev elements
    
    [ Upstream commit b6662e37772715447aeff2538444ff291e02ea31 ]
    
    The 'kzdev' field of struct 'zpci_aift' is an array of pointers to
    'kvm_zdev' structs. Allocate the proper size accordingly.
    
    Reported by Coccinelle:
      WARNING: Use correct pointer type argument for sizeof
    
    Fixes: 98b1d33dac5f ("KVM: s390: pci: do initial setup for AEN interpretation")
    Signed-off-by: Rafael Mendonca <[email protected]>
    Reviewed-by: Christian Borntraeger <[email protected]>
    Reviewed-by: Matthew Rosato <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Message-Id: <[email protected]>
    Signed-off-by: Janosch Frank <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: s390: pv: don't allow userspace to set the clock under PV [+ + +]
Author: Nico Boehr <[email protected]>
Date:   Tue Oct 11 18:07:12 2022 +0200

    KVM: s390: pv: don't allow userspace to set the clock under PV
    
    [ Upstream commit 6973091d1b50ab4042f6a2d495f59e9db3662ab8 ]
    
    When running under PV, the guest's TOD clock is under control of the
    ultravisor and the hypervisor isn't allowed to change it. Hence, don't
    allow userspace to change the guest's TOD clock by returning
    -EOPNOTSUPP.
    
    When userspace changes the guest's TOD clock, KVM updates its
    kvm.arch.epoch field and, in addition, the epoch field in all state
    descriptions of all VCPUs.
    
    But, under PV, the ultravisor will ignore the epoch field in the state
    description and simply overwrite it on next SIE exit with the actual
    guest epoch. This leads to KVM having an incorrect view of the guest's
    TOD clock: it has updated its internal kvm.arch.epoch field, but the
    ultravisor ignores the field in the state description.
    
    Whenever a guest is now waiting for a clock comparator, KVM will
    incorrectly calculate the time when the guest should wake up, possibly
    causing the guest to sleep for much longer than expected.
    
    With this change, kvm_s390_set_tod() will now take the kvm->lock to be
    able to call kvm_s390_pv_is_protected(). Since kvm_s390_set_tod_clock()
    also takes kvm->lock, use __kvm_s390_set_tod_clock() instead.
    
    The function kvm_s390_set_tod_clock is now unused, hence remove it.
    Update the documentation to indicate the TOD clock attr calls can now
    return -EOPNOTSUPP.
    
    Fixes: 0f3035047140 ("KVM: s390: protvirt: Do only reset registers that are accessible")
    Reported-by: Marc Hartmayer <[email protected]>
    Signed-off-by: Nico Boehr <[email protected]>
    Reviewed-by: Claudio Imbrenda <[email protected]>
    Reviewed-by: Janosch Frank <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Message-Id: <[email protected]>
    Signed-off-by: Janosch Frank <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: SVM: adjust register allocation for __svm_vcpu_run() [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Fri Oct 28 17:30:07 2022 -0400

    KVM: SVM: adjust register allocation for __svm_vcpu_run()
    
    commit f7ef280132f9bf6f82acf5aa5c3c837206eef501 upstream.
    
    32-bit ABI uses RAX/RCX/RDX as its argument registers, so they are in
    the way of instructions that hardcode their operands such as RDMSR/WRMSR
    or VMLOAD/VMRUN/VMSAVE.
    
    In preparation for moving vmload/vmsave to __svm_vcpu_run(), keep
    the pointer to the struct vcpu_svm in %rdi.  In particular, it is now
    possible to load svm->vmcb01.pa in %rax without clobbering the struct
    vcpu_svm pointer.
    
    No functional change intended.
    
    Cc: [email protected]
    Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: SVM: move guest vmsave/vmload back to assembly [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Mon Nov 7 05:14:27 2022 -0500

    KVM: SVM: move guest vmsave/vmload back to assembly
    
    commit e61ab42de874c5af8c5d98b327c77a374d9e7da1 upstream.
    
    It is error-prone that code after vmexit cannot access percpu data
    because GSBASE has not been restored yet.  It forces MSR_IA32_SPEC_CTRL
    save/restore to happen very late, after the predictor untraining
    sequence, and it gets in the way of return stack depth tracking
    (a retbleed mitigation that is in linux-next as of 2022-11-09).
    
    As a first step towards fixing that, move the VMCB VMSAVE/VMLOAD to
    assembly, essentially undoing commit fb0c4a4fee5a ("KVM: SVM: move
    VMLOAD/VMSAVE to C code", 2021-03-15).  The reason for that commit was
    that it made it simpler to use a different VMCB for VMLOAD/VMSAVE versus
    VMRUN; but that is not a big hassle anymore thanks to the kvm-asm-offsets
    machinery and other related cleanups.
    
    The idea on how to number the exception tables is stolen from
    a prototype patch by Peter Zijlstra.
    
    Cc: [email protected]
    Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
    Link: <https://lore.kernel.org/all/[email protected]/>
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: SVM: Only dump VMSA to klog at KERN_DEBUG level [+ + +]
Author: Peter Gonda <[email protected]>
Date:   Fri Nov 4 07:22:20 2022 -0700

    KVM: SVM: Only dump VMSA to klog at KERN_DEBUG level
    
    commit 0bd8bd2f7a789fe1dcb21ad148199d2f62d79873 upstream.
    
    Explicitly print the VMSA dump at KERN_DEBUG log level, KERN_CONT uses
    KERNEL_DEFAULT if the previous log line has a newline, i.e. if there's
    nothing to continuing, and as a result the VMSA gets dumped when it
    shouldn't.
    
    The KERN_CONT documentation says it defaults back to KERNL_DEFAULT if the
    previous log line has a newline. So switch from KERN_CONT to
    print_hex_dump_debug().
    
    Jarkko pointed this out in reference to the original patch. See:
    https://lore.kernel.org/all/[email protected]/
    print_hex_dump(KERN_DEBUG, ...) was pointed out there, but
    print_hex_dump_debug() should similar.
    
    Fixes: 6fac42f127b8 ("KVM: SVM: Dump Virtual Machine Save Area (VMSA) to klog")
    Signed-off-by: Peter Gonda <[email protected]>
    Reviewed-by: Sean Christopherson <[email protected]>
    Cc: Jarkko Sakkinen <[email protected]>
    Cc: Harald Hoyer <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Cc: [email protected]
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: SVM: replace regs argument of __svm_vcpu_run() with vcpu_svm [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Fri Sep 30 14:14:44 2022 -0400

    KVM: SVM: replace regs argument of __svm_vcpu_run() with vcpu_svm
    
    commit 16fdc1de169ee0a4e59a8c02244414ec7acd55c3 upstream.
    
    Since registers are reachable through vcpu_svm, and we will
    need to access more fields of that struct, pass it instead
    of the regs[] array.
    
    No functional change intended.
    
    Cc: [email protected]
    Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: SVM: retrieve VMCB from assembly [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Mon Nov 7 04:17:29 2022 -0500

    KVM: SVM: retrieve VMCB from assembly
    
    commit f6d58266d731fd7e63163790aad21e0dbb1d5264 upstream.
    
    Continue moving accesses to struct vcpu_svm to vmenter.S.  Reducing the
    number of arguments limits the chance of mistakes due to different
    registers used for argument passing in 32- and 64-bit ABIs; pushing the
    VMCB argument and almost immediately popping it into a different
    register looks pretty weird.
    
    32-bit ABI is not a concern for __svm_sev_es_vcpu_run() which is 64-bit
    only; however, it will soon need @svm to save/restore SPEC_CTRL so stay
    consistent with __svm_vcpu_run() and let them share the same prototype.
    
    No functional change intended.
    
    Cc: [email protected]
    Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
    Reviewed-by: Sean Christopherson <[email protected]gle.com>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86/mmu: Block all page faults during kvm_zap_gfn_range() [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Nov 11 00:18:41 2022 +0000

    KVM: x86/mmu: Block all page faults during kvm_zap_gfn_range()
    
    commit 6d3085e4d89ad7e6c7f1c6cf929d903393565861 upstream.
    
    When zapping a GFN range, pass 0 => ALL_ONES for the to-be-invalidated
    range to effectively block all page faults while the zap is in-progress.
    The invalidation helpers take a host virtual address, whereas zapping a
    GFN obviously provides a guest physical address and with the wrong unit
    of measurement (frame vs. byte).
    
    Alternatively, KVM could walk all memslots to get the associated HVAs,
    but thanks to SMM, that would require multiple lookups.  And practically
    speaking, kvm_zap_gfn_range() usage is quite rare and not a hot path,
    e.g. MTRR and CR0.CD are almost guaranteed to be done only on vCPU0
    during boot, and APICv inhibits are similarly infrequent operations.
    
    Fixes: edb298c663fc ("KVM: x86/mmu: bump mmu notifier count in kvm_zap_gfn_range")
    Reported-by: Chao Peng <[email protected]>
    Cc: [email protected]
    Cc: Maxim Levitsky <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86/pmu: Do not speculatively query Intel GP PMCs that don't exist yet [+ + +]
Author: Like Xu <[email protected]>
Date:   Mon Sep 19 17:10:06 2022 +0800

    KVM: x86/pmu: Do not speculatively query Intel GP PMCs that don't exist yet
    
    commit 8631ef59b62290c7d88e7209e35dfb47f33f4902 upstream.
    
    The SDM lists an architectural MSR IA32_CORE_CAPABILITIES (0xCF)
    that limits the theoretical maximum value of the Intel GP PMC MSRs
    allocated at 0xC1 to 14; likewise the Intel April 2022 SDM adds
    IA32_OVERCLOCKING_STATUS at 0x195 which limits the number of event
    selection MSRs to 15 (0x186-0x194).
    
    Limiting the maximum number of counters to 14 or 18 based on the currently
    allocated MSRs is clearly fragile, and it seems likely that Intel will
    even place PMCs 8-15 at a completely different range of MSR indices.
    So stop at the maximum number of GP PMCs supported today on Intel
    processors.
    
    There are some machines, like Intel P4 with non Architectural PMU, that
    may indeed have 18 counters, but those counters are in a completely
    different MSR address range and are not supported by KVM.
    
    Cc: Vitaly Kuznetsov <[email protected]>
    Cc: [email protected]
    Fixes: cf05a67b68b8 ("KVM: x86: omit "impossible" pmu MSRs from MSR list")
    Suggested-by: Jim Mattson <[email protected]>
    Signed-off-by: Like Xu <[email protected]>
    Reviewed-by: Jim Mattson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: use a separate asm-offsets.c file [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Tue Nov 8 09:44:53 2022 +0100

    KVM: x86: use a separate asm-offsets.c file
    
    commit debc5a1ec0d195ffea70d11efeffb713de9fdbc7 upstream.
    
    This already removes an ugly #include "" from asm-offsets.c, but
    especially it avoids a future error when trying to define asm-offsets
    for KVM's svm/svm.h header.
    
    This would not work for kernel/asm-offsets.c, because svm/svm.h
    includes kvm_cache_regs.h which is not in the include path when
    compiling asm-offsets.c.  The problem is not there if the .c file is
    in arch/x86/kvm.
    
    Suggested-by: Sean Christopherson <[email protected]>
    Cc: [email protected]
    Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.0.9 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Nov 16 10:04:15 2022 +0100

    Linux 6.0.9
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Zan Aziz <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Rudi Heitbaum <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
m68k: Rework BI_VIRT_RNG_SEED as BI_RNG_SEED [+ + +]
Author: Jason A. Donenfeld <[email protected]>
Date:   Tue Sep 27 15:08:35 2022 +0200

    m68k: Rework BI_VIRT_RNG_SEED as BI_RNG_SEED
    
    commit dc63a086daee92c63e392e4e7cd7ed61f3693026 upstream.
    
    This is useful on !virt platforms for kexec, so change things from
    BI_VIRT_RNG_SEED to be BI_RNG_SEED, and simply remove BI_VIRT_RNG_SEED
    because it only ever lasted one release, and nothing is broken by not
    having it. At the same time, keep a comment noting that it's been
    removed, so that ID isn't reused. In addition, we previously documented
    2-byte alignment, but 4-byte alignment is actually necessary, so update
    that comment.
    
    Suggested-by: Geert Uytterhoeven <[email protected]>
    Fixes: a1ee38ab1a75 ("m68k: virt: Use RNG seed from bootinfo block")
    Signed-off-by: Jason A. Donenfeld <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
macsec: clear encryption keys from the stack after setting up offload [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Wed Nov 2 22:33:16 2022 +0100

    macsec: clear encryption keys from the stack after setting up offload
    
    [ Upstream commit aaab73f8fba4fd38f4d2617440d541a1c334e819 ]
    
    macsec_add_rxsa and macsec_add_txsa copy the key to an on-stack
    offloading context to pass it to the drivers, but leaves it there when
    it's done. Clear it with memzero_explicit as soon as it's not needed
    anymore.
    
    Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Antoine Tenart <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

macsec: delete new rxsc when offload fails [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Wed Nov 2 22:33:13 2022 +0100

    macsec: delete new rxsc when offload fails
    
    [ Upstream commit 93a30947821c203d08865c4e17ea181c9668ce52 ]
    
    Currently we get an inconsistent state:
     - netlink returns the error to userspace
     - the RXSC is installed but not offloaded
    
    Then the device could get confused when we try to add an RXSA, because
    the RXSC isn't supposed to exist.
    
    Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Antoine Tenart <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

macsec: fix detection of RXSCs when toggling offloading [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Wed Nov 2 22:33:15 2022 +0100

    macsec: fix detection of RXSCs when toggling offloading
    
    [ Upstream commit 80df4706357a5a06bbbc70273bf2611df1ceee04 ]
    
    macsec_is_configured incorrectly uses secy->n_rx_sc to check if some
    RXSCs exist. secy->n_rx_sc only counts the number of active RXSCs, but
    there can also be inactive SCs as well, which may be stored in the
    driver (in case we're disabling offloading), or would have to be
    pushed to the device (in case we're trying to enable offloading).
    
    As long as RXSCs active on creation and never turned off, the issue is
    not visible.
    
    Fixes: dcb780fb2795 ("net: macsec: add nla support for changing the offloading selection")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Antoine Tenart <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

macsec: fix secy->n_rx_sc accounting [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Wed Nov 2 22:33:14 2022 +0100

    macsec: fix secy->n_rx_sc accounting
    
    [ Upstream commit 73a4b31c9d11f98ae3bc5286d5382930adb0e9c7 ]
    
    secy->n_rx_sc is supposed to be the number of _active_ rxsc's within a
    secy. This is then used by macsec_send_sci to help decide if we should
    add the SCI to the header or not.
    
    This logic is currently broken when we create a new RXSC and turn it
    off at creation, as create_rx_sc always sets ->active to true (and
    immediately uses that to increment n_rx_sc), and only later
    macsec_add_rxsc sets rx_sc->active.
    
    Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Antoine Tenart <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mctp: Fix an error handling path in mctp_init() [+ + +]
Author: Wei Yongjun <[email protected]>
Date:   Tue Nov 8 09:55:17 2022 +0000

    mctp: Fix an error handling path in mctp_init()
    
    [ Upstream commit d4072058af4fd8fb4658e7452289042a406a9398 ]
    
    If mctp_neigh_init() return error, the routes resources should
    be released in the error handling path. Otherwise some resources
    leak.
    
    Fixes: 4d8b9319282a ("mctp: Add neighbour implementation")
    Signed-off-by: Wei Yongjun <[email protected]>
    Acked-by: Matt Johnston <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
MIPS: jump_label: Fix compat branch range check [+ + +]
Author: Jiaxun Yang <[email protected]>
Date:   Thu Nov 3 15:10:53 2022 +0000

    MIPS: jump_label: Fix compat branch range check
    
    commit 64ac0befe75bdfaffc396c2b4a0ed5ae6920eeee upstream.
    
    Cast upper bound of branch range to long to do signed compare,
    avoid negative offset trigger this warning.
    
    Fixes: 9b6584e35f40 ("MIPS: jump_label: Use compact branches for >= r6")
    Signed-off-by: Jiaxun Yang <[email protected]>
    Cc: [email protected]
    Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/damon/dbgfs: check if rm_contexts input is for a real context [+ + +]
Author: SeongJae Park <[email protected]>
Date:   Mon Nov 7 16:50:00 2022 +0000

    mm/damon/dbgfs: check if rm_contexts input is for a real context
    
    commit 1de09a7281edecfdba19b3a07417f6d65243ab5f upstream.
    
    A user could write a name of a file under 'damon/' debugfs directory,
    which is not a user-created context, to 'rm_contexts' file.  In the case,
    'dbgfs_rm_context()' just assumes it's the valid DAMON context directory
    only if a file of the name exist.  As a result, invalid memory access
    could happen as below.  Fix the bug by checking if the given input is for
    a directory.  This check can filter out non-context inputs because
    directories under 'damon/' debugfs directory can be created via only
    'mk_contexts' file.
    
    This bug has found by syzbot[1].
    
    [1] https://lore.kernel.org/damon/[email protected]/
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 75c1c2b53c78 ("mm/damon/dbgfs: support multiple contexts")
    Signed-off-by: SeongJae Park <[email protected]>
    Reported-by: [email protected]
    Cc: <[email protected]>    [5.15.x]
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/memremap.c: map FS_DAX device memory as decrypted [+ + +]
Author: Pankaj Gupta <[email protected]>
Date:   Wed Nov 2 11:07:28 2022 -0500

    mm/memremap.c: map FS_DAX device memory as decrypted
    
    commit 867400af90f1f953ff9e10b1b87ecaf9369a7eb8 upstream.
    
    virtio_pmem use devm_memremap_pages() to map the device memory.  By
    default this memory is mapped as encrypted with SEV.  Guest reboot changes
    the current encryption key and guest no longer properly decrypts the FSDAX
    device meta data.
    
    Mark the corresponding device memory region for FSDAX devices (mapped with
    memremap_pages) as decrypted to retain the persistent memory property.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b7b3c01b19159 ("mm/memremap_pages: support multiple ranges per invocation")
    Signed-off-by: Pankaj Gupta <[email protected]>
    Cc: Dan Williams <[email protected]>
    Cc: Tom Lendacky <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/shmem: use page_mapping() to detect page cache for uffd continue [+ + +]
Author: Peter Xu <[email protected]>
Date:   Wed Nov 2 14:41:52 2022 -0400

    mm/shmem: use page_mapping() to detect page cache for uffd continue
    
    commit 93b0d9178743a68723babe8448981f658aebc58e upstream.
    
    mfill_atomic_install_pte() checks page->mapping to detect whether one page
    is used in the page cache.  However as pointed out by Matthew, the page
    can logically be a tail page rather than always the head in the case of
    uffd minor mode with UFFDIO_CONTINUE.  It means we could wrongly install
    one pte with shmem thp tail page assuming it's an anonymous page.
    
    It's not that clear even for anonymous page, since normally anonymous
    pages also have page->mapping being setup with the anon vma.  It's safe
    here only because the only such caller to mfill_atomic_install_pte() is
    always passing in a newly allocated page (mcopy_atomic_pte()), whose
    page->mapping is not yet setup.  However that's not extremely obvious
    either.
    
    For either of above, use page_mapping() instead.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 153132571f02 ("userfaultfd/shmem: support UFFDIO_CONTINUE for shmem")
    Signed-off-by: Peter Xu <[email protected]>
    Reported-by: Matthew Wilcox <[email protected]>
    Cc: Andrea Arcangeli <[email protected]>
    Cc: Hugh Dickins <[email protected]>
    Cc: Axel Rasmussen <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: hugetlb_vmemmap: include missing linux/moduleparam.h [+ + +]
Author: Vasily Gorbik <[email protected]>
Date:   Wed Nov 2 19:09:17 2022 +0100

    mm: hugetlb_vmemmap: include missing linux/moduleparam.h
    
    commit db5e8d84319bcdb51e1d3cfa42b410291d6d1cfa upstream.
    
    The kernel test robot reported build failures with a 'randconfig' on s390:
    >> mm/hugetlb_vmemmap.c:421:11: error: a function declaration without a
    prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
       core_param(hugetlb_free_vmemmap, vmemmap_optimize_enabled, bool, 0);
                 ^
    
    Link: https://lore.kernel.org/linux-mm/[email protected]/
    Link: https://lkml.kernel.org/r/[email protected]rk.hours
    Fixes: 30152245c63b ("mm: hugetlb_vmemmap: replace early_param() with core_param()")
    Signed-off-by: Vasily Gorbik <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Reviewed-by: Muchun Song <[email protected]>
    Cc: Gerald Schaefer <[email protected]>
    Cc: Mike Kravetz <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI [+ + +]
Author: Brian Norris <[email protected]>
Date:   Wed Oct 26 12:42:03 2022 -0700

    mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI
    
    commit ebb5fd38f41132e6924cb33b647337f4a5d5360c upstream.
    
    Several SDHCI drivers need to deactivate command queueing in their reset
    hook (see sdhci_cqhci_reset() / sdhci-pci-core.c, for example), and
    several more are coming.
    
    Those reset implementations have some small subtleties (e.g., ordering
    of initialization of SDHCI vs. CQHCI might leave us resetting with a
    NULL ->cqe_private), and are often identical across different host
    drivers.
    
    We also don't want to force a dependency between SDHCI and CQHCI, or
    vice versa; non-SDHCI drivers use CQHCI, and SDHCI drivers might support
    command queueing through some other means.
    
    So, implement a small helper, to avoid repeating the same mistakes in
    different drivers. Simply stick it in a header, because it's so small it
    doesn't deserve its own module right now, and inlining to each driver is
    pretty reasonable.
    
    This is marked for -stable, as it is an important prerequisite patch for
    several SDHCI controller bugfixes that follow.
    
    Cc: <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-brcmstb: Fix SDHCI_RESET_ALL for CQHCI [+ + +]
Author: Brian Norris <[email protected]>
Date:   Wed Oct 26 12:42:05 2022 -0700

    mmc: sdhci-brcmstb: Fix SDHCI_RESET_ALL for CQHCI
    
    commit 56baa208f91061ff27ec2d93fbc483f624d373b4 upstream.
    
    [[ NOTE: this is completely untested by the author, but included solely
        because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
        SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
        drivers using CQHCI might benefit from a similar change, if they
        also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
        bug on at least MSM, Arasan, and Intel hardware. ]]
    
    SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
    tracking that properly in software. When out of sync, we may trigger
    various timeouts.
    
    It's not typical to perform resets while CQE is enabled, but this may
    occur in some suspend or error recovery scenarios.
    
    Include this fix by way of the new sdhci_and_cqhci_reset() helper.
    
    I only patch the bcm7216 variant even though others potentially *could*
    provide the 'supports-cqe' property (and thus enable CQHCI), because
    d46ba2d17f90 ("mmc: sdhci-brcmstb: Add support for Command Queuing
    (CQE)") and some Broadcom folks confirm that only the 7216 variant
    actually supports it.
    
    This patch depends on (and should not compile without) the patch
    entitled "mmc: cqhci: Provide helper for resetting both SDHCI and
    CQHCI".
    
    Fixes: d46ba2d17f90 ("mmc: sdhci-brcmstb: Add support for Command Queuing (CQE)")
    Signed-off-by: Brian Norris <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-esdhc-imx: use the correct host caps for MMC_CAP_8_BIT_DATA [+ + +]
Author: Haibo Chen <[email protected]>
Date:   Tue Nov 8 15:45:03 2022 +0800

    mmc: sdhci-esdhc-imx: use the correct host caps for MMC_CAP_8_BIT_DATA
    
    commit f002f45a00ee14214d96b18b9a555fe2c56afb20 upstream.
    
    MMC_CAP_8_BIT_DATA belongs to struct mmc_host, not struct sdhci_host.
    So correct it here.
    
    Fixes: 1ed5c3b22fc7 ("mmc: sdhci-esdhc-imx: Propagate ESDHC_FLAG_HS400* only on 8bit bus")
    Signed-off-by: Haibo Chen <[email protected]>
    Cc: [email protected]
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI [+ + +]
Author: Brian Norris <[email protected]>
Date:   Wed Oct 26 12:42:04 2022 -0700

    mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
    
    commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
    
    SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
    tracking that properly in software. When out of sync, we may trigger
    various timeouts.
    
    It's not typical to perform resets while CQE is enabled, but one
    particular case I hit commonly enough: mmc_suspend() -> mmc_power_off().
    Typically we will eventually deactivate CQE (cqhci_suspend() ->
    cqhci_deactivate()), but that's not guaranteed -- in particular, if
    we perform a partial (e.g., interrupted) system suspend.
    
    The same bug was already found and fixed for two other drivers, in v5.7
    and v5.9:
    
      5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset")
      df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel
                     GLK-based controllers")
    
    The latter is especially prescient, saying "other drivers using CQHCI
    might benefit from a similar change, if they also have CQHCI reset by
    SDHCI_RESET_ALL."
    
    So like these other patches, deactivate CQHCI when resetting the
    controller. Do this via the new sdhci_and_cqhci_reset() helper.
    
    This patch depends on (and should not compile without) the patch
    entitled "mmc: cqhci: Provide helper for resetting both SDHCI and
    CQHCI".
    
    Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1")
    Cc: <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-tegra: Fix SDHCI_RESET_ALL for CQHCI [+ + +]
Author: Brian Norris <[email protected]>
Date:   Wed Oct 26 12:42:07 2022 -0700

    mmc: sdhci-tegra: Fix SDHCI_RESET_ALL for CQHCI
    
    commit 836078449464e6af3b66ae6652dae79af176f21e upstream.
    
    [[ NOTE: this is completely untested by the author, but included solely
        because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
        SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
        drivers using CQHCI might benefit from a similar change, if they
        also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
        bug on at least MSM, Arasan, and Intel hardware. ]]
    
    SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
    tracking that properly in software. When out of sync, we may trigger
    various timeouts.
    
    It's not typical to perform resets while CQE is enabled, but this may
    occur in some suspend or error recovery scenarios.
    
    Include this fix by way of the new sdhci_and_cqhci_reset() helper.
    
    This patch depends on (and should not compile without) the patch
    entitled "mmc: cqhci: Provide helper for resetting both SDHCI and
    CQHCI".
    
    Fixes: 3c4019f97978 ("mmc: tegra: HW Command Queue Support for Tegra SDMMC")
    Signed-off-by: Brian Norris <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci_am654: Fix SDHCI_RESET_ALL for CQHCI [+ + +]
Author: Brian Norris <[email protected]>
Date:   Wed Oct 26 12:42:08 2022 -0700

    mmc: sdhci_am654: Fix SDHCI_RESET_ALL for CQHCI
    
    commit 162503fd1c3a1d4e14dbe7f399c1d1bec1c8abbc upstream.
    
    [[ NOTE: this is completely untested by the author, but included solely
        because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
        SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
        drivers using CQHCI might benefit from a similar change, if they
        also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
        bug on at least MSM, Arasan, and Intel hardware. ]]
    
    SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
    tracking that properly in software. When out of sync, we may trigger
    various timeouts.
    
    It's not typical to perform resets while CQE is enabled, but this may
    occur in some suspend or error recovery scenarios.
    
    Include this fix by way of the new sdhci_and_cqhci_reset() helper.
    
    This patch depends on (and should not compile without) the patch
    entitled "mmc: cqhci: Provide helper for resetting both SDHCI and
    CQHCI".
    
    Fixes: f545702b74f9 ("mmc: sdhci_am654: Add Support for Command Queuing Engine to J721E")
    Signed-off-by: Brian Norris <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI [+ + +]
Author: Brian Norris <[email protected]>
Date:   Wed Oct 26 12:42:06 2022 -0700

    mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI
    
    commit fb1dec44c6750bb414f47b929c8c175a1a127c31 upstream.
    
    [[ NOTE: this is completely untested by the author, but included solely
        because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
        SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
        drivers using CQHCI might benefit from a similar change, if they
        also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
        bug on at least MSM, Arasan, and Intel hardware. ]]
    
    SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't
    tracking that properly in software. When out of sync, we may trigger
    various timeouts.
    
    It's not typical to perform resets while CQE is enabled, but this may
    occur in some suspend or error recovery scenarios.
    
    Include this fix by way of the new sdhci_and_cqhci_reset() helper.
    
    This patch depends on (and should not compile without) the patch
    entitled "mmc: cqhci: Provide helper for resetting both SDHCI and
    CQHCI".
    
    Fixes: bb6e358169bf ("mmc: sdhci-esdhc-imx: add CMDQ support")
    Signed-off-by: Brian Norris <[email protected]>
    Reviewed-by: Haibo Chen <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/mlx5: Allow async trigger completion execution on single CPU systems [+ + +]
Author: Roy Novich <[email protected]>
Date:   Wed Nov 2 23:55:38 2022 -0700

    net/mlx5: Allow async trigger completion execution on single CPU systems
    
    [ Upstream commit 2808b37b59288ad8f1897e3546c2296df3384b65 ]
    
    For a single CPU system, the kernel thread executing mlx5_cmd_flush()
    never releases the CPU but calls down_trylock(&cmd→sem) in a busy loop.
    On a single processor system, this leads to a deadlock as the kernel
    thread which executes mlx5_cmd_invoke() never gets scheduled. Fix this,
    by adding the cond_resched() call to the loop, allow the command
    completion kernel thread to execute.
    
    Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free")
    Signed-off-by: Alexander Schmidt <[email protected]>
    Signed-off-by: Roy Novich <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Bridge, verify LAG state when adding bond to bridge [+ + +]
Author: Vlad Buslov <[email protected]>
Date:   Wed Nov 2 23:55:37 2022 -0700

    net/mlx5: Bridge, verify LAG state when adding bond to bridge
    
    [ Upstream commit 15f8f168952f54d3c86d734dc764f20844e423ac ]
    
    Mlx5 LAG is initialized asynchronously on a workqueue which means that for
    a brief moment after setting mlx5 UL representors as lower devices of a
    bond netdevice the LAG itself is not fully initialized in the driver. When
    adding such bond device to a bridge mlx5 bridge code will not consider it
    as offload-capable, skip creating necessary bookkeeping and fail any
    further bridge offload-related commands with it (setting VLANs, offloading
    FDBs, etc.). In order to make the error explicit during bridge
    initialization stage implement the code that detects such condition during
    NETDEV_PRECHANGEUPPER event and returns an error.
    
    Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG")
    Signed-off-by: Vlad Buslov <[email protected]>
    Reviewed-by: Roi Dayan <[email protected]>
    Reviewed-by: Mark Bloch <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: E-switch, Set to legacy mode if failed to change switchdev mode [+ + +]
Author: Chris Mi <[email protected]>
Date:   Wed Nov 2 23:55:39 2022 -0700

    net/mlx5: E-switch, Set to legacy mode if failed to change switchdev mode
    
    [ Upstream commit e12de39c07a7872c1ac7250311bb60b74ff29f25 ]
    
    No need to rollback to the other mode because probably will fail
    again. Just set to legacy mode and clear fdb table created flag.
    So that fdb table will not be cleared again.
    
    Fixes: f019679ea5f2 ("net/mlx5: E-switch, Remove dependency between sriov and eswitch mode")
    Signed-off-by: Chris Mi <[email protected]>
    Reviewed-by: Roi Dayan <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: fw_reset: Don't try to load device in case PCI isn't working [+ + +]
Author: Shay Drory <[email protected]>
Date:   Wed Nov 2 23:55:40 2022 -0700

    net/mlx5: fw_reset: Don't try to load device in case PCI isn't working
    
    [ Upstream commit 7d167b4a4c810919ba1affd02fc6b7f40e7e6eeb ]
    
    In case PCI reads fail after unload, there is no use in trying to
    load the device.
    
    Fixes: 5ec697446f46 ("net/mlx5: Add support for devlink reload action fw activate")
    Signed-off-by: Shay Drory <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5e: Add missing sanity checks for max TX WQE size [+ + +]
Author: Maxim Mikityanskiy <[email protected]>
Date:   Wed Nov 2 23:55:42 2022 -0700

    net/mlx5e: Add missing sanity checks for max TX WQE size
    
    [ Upstream commit f9c955b4fe5c8626d11b8a9b93ccc0ba77358fec ]
    
    The commit cited below started using the firmware capability for the
    maximum TX WQE size. This commit adds an important check to verify that
    the driver doesn't attempt to exceed this capability, and also restores
    another check mistakenly removed in the cited commit (a WQE must not
    exceed the page size).
    
    Fixes: c27bd1718c06 ("net/mlx5e: Read max WQEBBs on the SQ from firmware")
    Signed-off-by: Maxim Mikityanskiy <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: E-Switch, Fix comparing termination table instance [+ + +]
Author: Roi Dayan <[email protected]>
Date:   Wed Nov 2 23:55:46 2022 -0700

    net/mlx5e: E-Switch, Fix comparing termination table instance
    
    [ Upstream commit f4f4096b410e8d31c3f07f39de3b17d144edd53d ]
    
    The pkt_reformat pointer being saved under flow_act and not
    dest attribute in the termination table instance.
    Fix the comparison pointers.
    
    Also fix returning success if one pkt_reformat pointer is null
    and the other is not.
    
    Fixes: 249ccc3c95bd ("net/mlx5e: Add support for offloading traffic from uplink to uplink")
    Signed-off-by: Roi Dayan <[email protected]>
    Reviewed-by: Chris Mi <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: Fix tc acts array not to be dependent on enum order [+ + +]
Author: Roi Dayan <[email protected]>
Date:   Wed Nov 2 23:55:44 2022 -0700

    net/mlx5e: Fix tc acts array not to be dependent on enum order
    
    [ Upstream commit 08912ea799cd2a43b8999457e316967fe4e2f327 ]
    
    The tc acts array should not be dependent on kernel internal
    flow action id enum. Fix the array initialization.
    
    Fixes: fad547906980 ("net/mlx5e: Add tc action infrastructure")
    Signed-off-by: Roi Dayan <[email protected]>
    Reviewed-by: Maor Dickman <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: TC, Fix wrong rejection of packet-per-second policing [+ + +]
Author: Jianbo Liu <[email protected]>
Date:   Wed Nov 2 23:55:45 2022 -0700

    net/mlx5e: TC, Fix wrong rejection of packet-per-second policing
    
    [ Upstream commit 9e06430841363a1d2932d546fdce1cc5edb3c2a0 ]
    
    In the bellow commit, we added support for PPS policing without
    removing the check which block offload of such cases.
    Fix it by removing this check.
    
    Fixes: a8d52b024d6d ("net/mlx5e: TC, Support offloading police action")
    Signed-off-by: Jianbo Liu <[email protected]>
    Reviewed-by: Maor Dickman <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]org>

 
net: atlantic: macsec: clear encryption keys from the stack [+ + +]
Author: Antoine Tenart <[email protected]>
Date:   Tue Nov 8 16:34:59 2022 +0100

    net: atlantic: macsec: clear encryption keys from the stack
    
    [ Upstream commit 879785def0f5e71d54399de0f8a5cb399db14171 ]
    
    Commit aaab73f8fba4 ("macsec: clear encryption keys from the stack after
    setting up offload") made sure to clean encryption keys from the stack
    after setting up offloading, but the atlantic driver made a copy and did
    not clear it. Fix this.
    
    [4 Fixes tags below, all part of the same series, no need to split this]
    
    Fixes: 9ff40a751a6f ("net: atlantic: MACSec ingress offload implementation")
    Fixes: b8f8a0b7b5cb ("net: atlantic: MACSec ingress offload HW bindings")
    Fixes: 27736563ce32 ("net: atlantic: MACSec egress offload implementation")
    Fixes: 9d106c6dd81b ("net: atlantic: MACSec egress offload HW bindings")
    Signed-off-by: Antoine Tenart <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: broadcom: Fix BCMGENET Kconfig [+ + +]
Author: YueHaibing <[email protected]>
Date:   Sat Nov 5 17:02:45 2022 +0800

    net: broadcom: Fix BCMGENET Kconfig
    
    [ Upstream commit 8d820bc9d12b8beebca836cceaf2bbe68216c2f8 ]
    
    While BCMGENET select BROADCOM_PHY as y, but PTP_1588_CLOCK_OPTIONAL is m,
    kconfig warning and build errors:
    
    WARNING: unmet direct dependencies detected for BROADCOM_PHY
      Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && PTP_1588_CLOCK_OPTIONAL [=m]
      Selected by [y]:
      - BCMGENET [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && HAS_IOMEM [=y] && ARCH_BCM2835 [=y]
    
    drivers/net/phy/broadcom.o: In function `bcm54xx_suspend':
    broadcom.c:(.text+0x6ac): undefined reference to `bcm_ptp_stop'
    drivers/net/phy/broadcom.o: In function `bcm54xx_phy_probe':
    broadcom.c:(.text+0x784): undefined reference to `bcm_ptp_probe'
    drivers/net/phy/broadcom.o: In function `bcm54xx_config_init':
    broadcom.c:(.text+0xd4c): undefined reference to `bcm_ptp_config_init'
    
    Fixes: 99addbe31f55 ("net: broadcom: Select BROADCOM_PHY for BCMGENET")
    Signed-off-by: YueHaibing <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: cpsw: disable napi in cpsw_ndo_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Nov 9 09:15:37 2022 +0800

    net: cpsw: disable napi in cpsw_ndo_open()
    
    [ Upstream commit 6d47b53fb3f363a74538a1dbd09954af3d8d4131 ]
    
    When failed to create xdp rxqs or fill rx channels in cpsw_ndo_open() for
    opening device, napi isn't disabled. When open cpsw device next time, it
    will report a invalid opcode issue. Compiled tested only.
    
    Fixes: d354eb85d618 ("drivers: net: cpsw: dual_emac: simplify napi usage")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: cxgb3_main: disable napi when bind qsets failed in cxgb_up() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Nov 9 10:14:51 2022 +0800

    net: cxgb3_main: disable napi when bind qsets failed in cxgb_up()
    
    [ Upstream commit d75aed1428da787cbe42bc073d76f1354f364d92 ]
    
    When failed to bind qsets in cxgb_up() for opening device, napi isn't
    disabled. When open cxgb3 device next time, it will trigger a BUG_ON()
    in napi_enable(). Compile tested only.
    
    Fixes: 48c4b6dbb7e2 ("cxgb3 - fix port up/down error path")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: mtk-star-emac: disable napi when connect and start PHY failed in mtk_star_enable() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Mon Nov 7 09:21:59 2022 +0800

    net: ethernet: mtk-star-emac: disable napi when connect and start PHY failed in mtk_star_enable()
    
    [ Upstream commit b0c09c7f08c2467b2089bdf4adb2fbbc2464f4a8 ]
    
    When failed to connect to and start PHY in mtk_star_enable() for opening
    device, napi isn't disabled. When open mtk star device next time, it will
    reports a invalid opcode issue. Fix it. Only be compiled, not be tested.
    
    Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload [+ + +]
Author: Roger Quadros <[email protected]>
Date:   Wed Nov 2 12:31:44 2022 +0200

    net: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload
    
    commit 1a0c016a4831ea29be09bbc8162d4a2a0690b4b8 upstream.
    
    Move am65_cpsw_nuss_phylink_cleanup() call to after
    am65_cpsw_nuss_cleanup_ndev() so phylink is still valid
    to prevent the below Segmentation fault on module remove when
    first slave link is up.
    
    [   31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4
    [   31.684627] Mem abort info:
    [   31.687446]   ESR = 0x0000000096000004
    [   31.704614]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   31.720663]   SET = 0, FnV = 0
    [   31.723729]   EA = 0, S1PTW = 0
    [   31.740617]   FSC = 0x04: level 0 translation fault
    [   31.756624] Data abort info:
    [   31.759508]   ISV = 0, ISS = 0x00000004
    [   31.776705]   CM = 0, WnR = 0
    [   31.779695] [00040008000005f4] address between user and kernel address ranges
    [   31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    [   31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6
    [   31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160
    [   31.837547] Hardware name: Texas Instruments AM625 (DT)
    [   31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   31.849709] pc : phy_stop+0x18/0xf8
    [   31.853202] lr : phylink_stop+0x38/0xf8
    [   31.857031] sp : ffff80000a0839f0
    [   31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000
    [   31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98
    [   31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90
    [   31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000
    [   31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106
    [   31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000
    [   31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0
    [   31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0
    [   31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920
    [   31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200
    [   31.931603] Call trace:
    [   31.934042]  phy_stop+0x18/0xf8
    [   31.937177]  phylink_stop+0x38/0xf8
    [   31.940657]  am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss]
    [   31.947452]  __dev_close_many+0xa4/0x140
    [   31.951371]  dev_close_many+0x84/0x128
    [   31.955115]  unregister_netdevice_many+0x130/0x6d0
    [   31.959897]  unregister_netdevice_queue+0x94/0xd8
    [   31.964591]  unregister_netdev+0x24/0x38
    [   31.968504]  am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss]
    [   31.975637]  am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]
    
    Cc: <[email protected]> # v5.18+
    Fixes: e8609e69470f ("net: ethernet: ti: am65-cpsw: Convert to PHYLINK")
    Signed-off-by: Roger Quadros <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: fman: Unregister ethernet device on removal [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Thu Nov 3 14:28:30 2022 -0400

    net: fman: Unregister ethernet device on removal
    
    [ Upstream commit b7cbc6740bd6ad5d43345a2504f7e4beff0d709f ]
    
    When the mac device gets removed, it leaves behind the ethernet device.
    This will result in a segfault next time the ethernet device accesses
    mac_dev. Remove the ethernet device when we get removed to prevent
    this. This is not completely reversible, since some resources aren't
    cleaned up properly, but that can be addressed later.
    
    Fixes: 3933961682a3 ("fsl/fman: Add FMan MAC driver")
    Signed-off-by: Sean Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: gso: fix panic on frag_list with mixed head alloc types [+ + +]
Author: Jiri Benc <[email protected]>
Date:   Wed Nov 2 17:53:25 2022 +0100

    net: gso: fix panic on frag_list with mixed head alloc types
    
    [ Upstream commit 9e4b7a99a03aefd37ba7bb1f022c8efab5019165 ]
    
    Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when
    splitting gso_size mangled skb having linear-headed frag_list"), it is
    allowed to change gso_size of a GRO packet. However, that commit assumes
    that "checking the first list_skb member suffices; i.e if either of the
    list_skb members have non head_frag head, then the first one has too".
    
    It turns out this assumption does not hold. We've seen BUG_ON being hit
    in skb_segment when skbs on the frag_list had differing head_frag with
    the vmxnet3 driver. This happens because __netdev_alloc_skb and
    __napi_alloc_skb can return a skb that is page backed or kmalloced
    depending on the requested size. As the result, the last small skb in
    the GRO packet can be kmalloced.
    
    There are three different locations where this can be fixed:
    
    (1) We could check head_frag in GRO and not allow GROing skbs with
        different head_frag. However, that would lead to performance
        regression on normal forward paths with unmodified gso_size, where
        !head_frag in the last packet is not a problem.
    
    (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating
        that NETIF_F_SG is undesirable. That would need to eat a bit in
        sk_buff. Furthermore, that flag can be unset when all skbs on the
        frag_list are page backed. To retain good performance,
        bpf_skb_net_grow/shrink would have to walk the frag_list.
    
    (3) Walk the frag_list in skb_segment when determining whether
        NETIF_F_SG should be cleared. This of course slows things down.
    
    This patch implements (3). To limit the performance impact in
    skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set
    that have gso_size changed. Normal paths thus will not hit it.
    
    We could check only the last skb but since we need to walk the whole
    list anyway, let's stay on the safe side.
    
    Fixes: 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list")
    Signed-off-by: Jiri Benc <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]dhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: lapbether: fix issue of dev reference count leakage in lapbeth_device_event() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Thu Nov 3 17:05:37 2022 +0800

    net: lapbether: fix issue of dev reference count leakage in lapbeth_device_event()
    
    [ Upstream commit 531705a765493655472c993627106e19f7e5a6d2 ]
    
    When following tests are performed, it will cause dev reference counting
    leakage.
    a)ip link add bond2 type bond mode balance-rr
    b)ip link set bond2 up
    c)ifenslave -f bond2 rose1
    d)ip link del bond2
    
    When new bond device is created, the default type of the bond device is
    ether. And the bond device is up, lapbeth_device_event() receives the
    message and creates a new lapbeth device. In this case, the reference
    count value of dev is hold once. But after "ifenslave -f bond2 rose1"
    command is executed, the type of the bond device is changed to rose. When
    the bond device is unregistered, lapbeth_device_event() will not put the
    dev reference count.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: lapbether: fix issue of invalid opcode in lapbeth_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Mon Nov 7 09:14:45 2022 +0800

    net: lapbether: fix issue of invalid opcode in lapbeth_open()
    
    [ Upstream commit 3faf7e14ec0c3462c2d747fa6793b8645d1391df ]
    
    If lapb_register() failed when lapb device goes to up for the first time,
    the NAPI is not disabled. As a result, the invalid opcode issue is
    reported when the lapb device goes to up for the second time.
    
    The stack info is as follows:
    [ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442!
    [ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    [ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0
    [ 1958.332310][T11356] Call Trace:
    [ 1958.332817][T11356]  <TASK>
    [ 1958.336135][T11356]  lapbeth_open+0x18/0x90
    [ 1958.337446][T11356]  __dev_open+0x258/0x490
    [ 1958.341672][T11356]  __dev_change_flags+0x4d4/0x6a0
    [ 1958.345325][T11356]  dev_change_flags+0x93/0x160
    [ 1958.346027][T11356]  devinet_ioctl+0x1276/0x1bf0
    [ 1958.346738][T11356]  inet_ioctl+0x1c8/0x2d0
    [ 1958.349638][T11356]  sock_ioctl+0x5d1/0x750
    [ 1958.356059][T11356]  __x64_sys_ioctl+0x3ec/0x1790
    [ 1958.365594][T11356]  do_syscall_64+0x35/0x80
    [ 1958.366239][T11356]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [ 1958.377381][T11356]  </TASK>
    
    Fixes: 514e1150da9c ("net: x25: Queue received packets in the drivers instead of per-CPU queues")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: macvlan: fix memory leaks of macvlan_common_newlink [+ + +]
Author: Chuang Wang <[email protected]>
Date:   Wed Nov 9 17:07:34 2022 +0800

    net: macvlan: fix memory leaks of macvlan_common_newlink
    
    [ Upstream commit 23569b5652ee8e8e55a12f7835f59af6f3cefc30 ]
    
    kmemleak reports memory leaks in macvlan_common_newlink, as follows:
    
     ip link add link eth0 name .. type macvlan mode source macaddr add
     <MAC-ADDR>
    
    kmemleak reports:
    
    unreferenced object 0xffff8880109bb140 (size 64):
      comm "ip", pid 284, jiffies 4294986150 (age 430.108s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff  ..........Z.....
        80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b  ..............kk
      backtrace:
        [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300
        [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0
        [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170
        [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0
        [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20
        [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50
        [<ffffffff81d98278>] rtnl_newlink+0x48/0x70
        ...
    
    In the scenario where the macvlan mode is configured as 'source',
    macvlan_changelink_sources() will be execured to reconfigure list of
    remote source mac addresses, at the same time, if register_netdevice()
    return an error, the resource generated by macvlan_changelink_sources()
    is not cleaned up.
    
    Using this patch, in the case of an error, it will execute
    macvlan_flush_sources() to ensure that the resource is cleaned up.
    
    Fixes: aa5fd0fb7748 ("driver: macvlan: Destroy new macvlan port if macvlan_common_newlink failed.")
    Signed-off-by: Chuang Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Tue Nov 8 10:56:07 2022 +0800

    net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()
    
    [ Upstream commit 519b58bbfa825f042fcf80261cc18e1e35f85ffd ]
    
    When prestera_sdma_switch_init() failed, the memory pointed to by
    sw->rxtx isn't released. Fix it. Only be compiled, not be tested.
    
    Fixes: 501ef3066c89 ("net: marvell: prestera: Add driver for Prestera family ASIC devices")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Reviewed-by: Vadym Kochan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mv643xx_eth: disable napi when init rxq or txq failed in mv643xx_eth_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Nov 9 10:54:32 2022 +0800

    net: mv643xx_eth: disable napi when init rxq or txq failed in mv643xx_eth_open()
    
    [ Upstream commit f111606b63ff2282428ffbac0447c871eb957b6c ]
    
    When failed to init rxq or txq in mv643xx_eth_open() for opening device,
    napi isn't disabled. When open mv643xx_eth device next time, it will
    trigger a BUG_ON() in napi_enable(). Compile tested only.
    
    Fixes: 2257e05c1705 ("mv643xx_eth: get rid of receive-side locking")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: nixge: disable napi when enable interrupts failed in nixge_open() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Mon Nov 7 18:14:43 2022 +0800

    net: nixge: disable napi when enable interrupts failed in nixge_open()
    
    [ Upstream commit b06334919c7a068d54ba5b219c05e919d89943f7 ]
    
    When failed to enable interrupts in nixge_open() for opening device,
    napi isn't disabled. When open nixge device next time, it will reports
    a invalid opcode issue. Fix it. Only be compiled, not be tested.
    
    Fixes: 492caffa8a1a ("net: ethernet: nixge: Add support for National Instruments XGE netdev")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <ku[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: mscc: macsec: clear encryption keys when freeing a flow [+ + +]
Author: Antoine Tenart <[email protected]>
Date:   Tue Nov 8 16:34:58 2022 +0100

    net: phy: mscc: macsec: clear encryption keys when freeing a flow
    
    [ Upstream commit 1b16b3fdf675cca15a537572bac50cc5354368fc ]
    
    Commit aaab73f8fba4 ("macsec: clear encryption keys from the stack after
    setting up offload") made sure to clean encryption keys from the stack
    after setting up offloading, but the MSCC PHY driver made a copy, kept
    it in the flow data and did not clear it when freeing a flow. Fix this.
    
    Fixes: 28c5107aa904 ("net: phy: mscc: macsec support")
    Signed-off-by: Antoine Tenart <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare_enable() [+ + +]
Author: Rasmus Villemoes <[email protected]>
Date:   Fri Nov 4 09:30:04 2022 +0100

    net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare_enable()
    
    [ Upstream commit ed4314f7729714d788698ade4f9905ee5378ebc0 ]
    
    There are two problems with meson8b_devm_clk_prepare_enable(),
    introduced in commit a54dc4a49045 ("net: stmmac: dwmac-meson8b:
    Make the clock enabling code re-usable"):
    
    - It doesn't pass the clk argument, but instead always the
      rgmii_tx_clk of the device.
    
    - It silently ignores the return value of devm_add_action_or_reset().
    
    The former didn't become an actual bug until another user showed up in
    the next commit 9308c47640d5 ("net: stmmac: dwmac-meson8b: add support
    for the RX delay configuration"). The latter means the callers could
    end up with the clock not actually prepared/enabled.
    
    Fixes: a54dc4a49045 ("net: stmmac: dwmac-meson8b: Make the clock enabling code re-usable")
    Signed-off-by: Rasmus Villemoes <[email protected]>
    Reviewed-by: Martin Blumenstingl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: tun: call napi_schedule_prep() to ensure we own a napi [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Nov 7 18:00:11 2022 +0000

    net: tun: call napi_schedule_prep() to ensure we own a napi
    
    [ Upstream commit 07d120aa33cc9d9115753d159f64d20c94458781 ]
    
    A recent patch exposed another issue in napi_get_frags()
    caught by syzbot [1]
    
    Before feeding packets to GRO, and calling napi_complete()
    we must first grab NAPI_STATE_SCHED.
    
    [1]
    WARNING: CPU: 0 PID: 3612 at net/core/dev.c:6076 napi_complete_done+0x45b/0x880 net/core/dev.c:6076
    Modules linked in:
    CPU: 0 PID: 3612 Comm: syz-executor408 Not tainted 6.1.0-rc3-syzkaller-00175-g1118b2049d77 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:napi_complete_done+0x45b/0x880 net/core/dev.c:6076
    Code: c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 24 04 00 00 41 89 5d 1c e9 73 fc ff ff e8 b5 53 22 fa <0f> 0b e9 82 fe ff ff e8 a9 53 22 fa 48 8b 5c 24 08 31 ff 48 89 de
    RSP: 0018:ffffc90003c4f920 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000000030 RCX: 0000000000000000
    RDX: ffff8880251c0000 RSI: ffffffff875a58db RDI: 0000000000000007
    RBP: 0000000000000001 R08: 0000000000000007 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: ffff888072d02628
    R13: ffff888072d02618 R14: ffff888072d02634 R15: 0000000000000000
    FS: 0000555555f13300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055c44d3892b8 CR3: 00000000172d2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    napi_complete include/linux/netdevice.h:510 [inline]
    tun_get_user+0x206d/0x3a60 drivers/net/tun.c:1980
    tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2027
    call_write_iter include/linux/fs.h:2191 [inline]
    do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735
    do_iter_write+0x182/0x700 fs/read_write.c:861
    vfs_writev+0x1aa/0x630 fs/read_write.c:934
    do_writev+0x133/0x2f0 fs/read_write.c:977
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7f37021a3c19
    
    Fixes: 1118b2049d77 ("net: tun: Fix memory leaks of napi_get_frags")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Wang Yufen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: tun: Fix memory leaks of napi_get_frags [+ + +]
Author: Wang Yufen <[email protected]>
Date:   Wed Nov 2 17:41:19 2022 +0800

    net: tun: Fix memory leaks of napi_get_frags
    
    [ Upstream commit 1118b2049d77ca0b505775fc1a8d1909cf19a7ec ]
    
    kmemleak reports after running test_progs:
    
    unreferenced object 0xffff8881b1672dc0 (size 232):
      comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s)
      hex dump (first 32 bytes):
        e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff  .........,g.....
        00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00  [email protected]
      backtrace:
        [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150
        [<0000000041c7fc09>] __napi_build_skb+0x15/0x50
        [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540
        [<000000003ecfa30e>] napi_get_frags+0x59/0x140
        [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]
        [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]
        [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320
        [<000000008f338ea2>] do_iter_write+0x135/0x630
        [<000000008a3377a4>] vfs_writev+0x12e/0x440
        [<00000000a6b5639a>] do_writev+0x104/0x280
        [<00000000ccf065d8>] do_syscall_64+0x3b/0x90
        [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    The issue occurs in the following scenarios:
    tun_get_user()
      napi_gro_frags()
        napi_frags_finish()
          case GRO_NORMAL:
            gro_normal_one()
              list_add_tail(&skb->list, &napi->rx_list);
              <-- While napi->rx_count < READ_ONCE(gro_normal_batch),
              <-- gro_normal_list() is not called, napi->rx_list is not empty
      <-- not ask to complete the gro work, will cause memory leaks in
      <-- following tun_napi_del()
    ...
    tun_napi_del()
      netif_napi_del()
        __netif_napi_del()
        <-- &napi->rx_list is not empty, which caused memory leaks
    
    To fix, add napi_complete() after napi_gro_frags().
    
    Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
    Signed-off-by: Wang Yufen <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: wwan: iosm: fix invalid mux header type [+ + +]
Author: M Chetan Kumar <[email protected]>
Date:   Mon Nov 7 13:05:13 2022 +0530

    net: wwan: iosm: fix invalid mux header type
    
    [ Upstream commit 02d2d2ea4a3bc2391f6ac31f6854da83e8a63829 ]
    
    Data stall seen during peak DL throughput test & packets are
    dropped by mux layer due to invalid header type in datagram.
    
    During initlization Mux aggregration protocol is set to default
    UL/DL size and TD count of Mux lite protocol. This configuration
    mismatch between device and driver is resulting in data stall/packet
    drops.
    
    Override the UL/DL size and TD count for Mux aggregation protocol.
    
    Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support")
    Signed-off-by: M Chetan Kumar <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg [+ + +]
Author: M Chetan Kumar <[email protected]>
Date:   Mon Nov 7 13:04:49 2022 +0530

    net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg
    
    [ Upstream commit d38a648d2d6cc7bee11c6f533ff9426a00c2a74c ]
    
    ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to
    obtain the wwan power state configuration from BIOS but is
    not freeing the acpi_object. The acpi_evaluate_dsm() returned
    acpi_object to be freed.
    
    Free the acpi_object after use.
    
    Fixes: 7e98d785ae61 ("net: iosm: entry point")
    Signed-off-by: M Chetan Kumar <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: wwan: iosm: fix memory leak in ipc_wwan_dellink [+ + +]
Author: HW He <[email protected]>
Date:   Thu Nov 3 18:40:00 2022 +0800

    net: wwan: iosm: fix memory leak in ipc_wwan_dellink
    
    [ Upstream commit f25caaca424703d5a0607310f0452f978f1f78d9 ]
    
    IOSM driver registers network device without setting the
    needs_free_netdev flag, and does NOT call free_netdev() when
    unregisters network device, which causes a memory leak.
    
    This patch sets needs_free_netdev to true when registers
    network device, which makes netdev subsystem call free_netdev()
    automatically after unregister_netdevice().
    
    Fixes: 2a54f2c77934 ("net: iosm: net driver")
    Signed-off-by: HW He <[email protected]>
    Reviewed-by: Loic Poulain <[email protected]>
    Signed-off-by: Zhaoping Shu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: wwan: mhi: fix memory leak in mhi_mbim_dellink [+ + +]
Author: HW He <[email protected]>
Date:   Thu Nov 3 18:54:19 2022 +0800

    net: wwan: mhi: fix memory leak in mhi_mbim_dellink
    
    [ Upstream commit 668205b9c9f94d5ed6ab00cce9a46a654c2b5d16 ]
    
    MHI driver registers network device without setting the
    needs_free_netdev flag, and does NOT call free_netdev() when
    unregisters network device, which causes a memory leak.
    
    This patch sets needs_free_netdev to true when registers
    network device, which makes netdev subsystem call free_netdev()
    automatically after unregister_netdevice().
    
    Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver")
    Signed-off-by: HW He <[email protected]>
    Signed-off-by: Zhaoping Shu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: Cleanup nft_net->module_list from nf_tables_exit_net() [+ + +]
Author: Shigeru Yoshida <[email protected]>
Date:   Thu Nov 3 22:08:49 2022 +0900

    netfilter: Cleanup nft_net->module_list from nf_tables_exit_net()
    
    [ Upstream commit 03c1f1ef1584c981935fab2fa0c45d3e43e2c235 ]
    
    syzbot reported a warning like below [1]:
    
    WARNING: CPU: 3 PID: 9 at net/netfilter/nf_tables_api.c:10096 nf_tables_exit_net+0x71c/0x840
    Modules linked in:
    CPU: 2 PID: 9 Comm: kworker/u8:0 Tainted: G        W          6.1.0-rc3-00072-g8e5423e991e8 #47
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
    Workqueue: netns cleanup_net
    RIP: 0010:nf_tables_exit_net+0x71c/0x840
    ...
    Call Trace:
     <TASK>
     ? __nft_release_table+0xfc0/0xfc0
     ops_exit_list+0xb5/0x180
     cleanup_net+0x506/0xb10
     ? unregister_pernet_device+0x80/0x80
     process_one_work+0xa38/0x1730
     ? pwq_dec_nr_in_flight+0x2b0/0x2b0
     ? rwlock_bug.part.0+0x90/0x90
     ? _raw_spin_lock_irq+0x46/0x50
     worker_thread+0x67e/0x10e0
     ? process_one_work+0x1730/0x1730
     kthread+0x2e5/0x3a0
     ? kthread_complete_and_exit+0x40/0x40
     ret_from_fork+0x1f/0x30
     </TASK>
    
    In nf_tables_exit_net(), there is a case where nft_net->commit_list is
    empty but nft_net->module_list is not empty.  Such a case occurs with
    the following scenario:
    
    1. nfnetlink_rcv_batch() is called
    2. nf_tables_newset() returns -EAGAIN and NFNL_BATCH_FAILURE bit is
       set to status
    3. nf_tables_abort() is called with NFNL_ABORT_AUTOLOAD
       (nft_net->commit_list is released, but nft_net->module_list is not
       because of NFNL_ABORT_AUTOLOAD flag)
    4. Jump to replay label
    5. netlink_skb_clone() fails and returns from the function (this is
       caused by fault injection in the reproducer of syzbot)
    
    This patch fixes this issue by calling __nf_tables_abort() when
    nft_net->module_list is not empty in nf_tables_exit_net().
    
    Fixes: eb014de4fd41 ("netfilter: nf_tables: autoload modules from the abort path")
    Link: https://syzkaller.appspot.com/bug?id=802aba2422de4218ad0c01b46c9525cc9d4e4aa3 [1]
    Reported-by: [email protected]
    Signed-off-by: Shigeru Yoshida <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nfnetlink: fix potential dead lock in nfnetlink_rcv_msg() [+ + +]
Author: Ziyang Xuan <[email protected]>
Date:   Thu Nov 3 09:12:02 2022 +0800

    netfilter: nfnetlink: fix potential dead lock in nfnetlink_rcv_msg()
    
    [ Upstream commit 03832a32bf8ff0a8305d94ddd3979835a807248f ]
    
    When type is NFNL_CB_MUTEX and -EAGAIN error occur in nfnetlink_rcv_msg(),
    it does not execute nfnl_unlock(). That would trigger potential dead lock.
    
    Fixes: 50f2db9e368f ("netfilter: nfnetlink: consolidate callback types")
    Signed-off-by: Ziyang Xuan <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: fix deadlock in nilfs_count_free_blocks() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Sat Oct 29 13:49:12 2022 +0900

    nilfs2: fix deadlock in nilfs_count_free_blocks()
    
    commit 8ac932a4921a96ca52f61935dbba64ea87bbd5dc upstream.
    
    A semaphore deadlock can occur if nilfs_get_block() detects metadata
    corruption while locating data blocks and a superblock writeback occurs at
    the same time:
    
    task 1                               task 2
    ------                               ------
    * A file operation *
    nilfs_truncate()
      nilfs_get_block()
        down_read(rwsem A) <--
        nilfs_bmap_lookup_contig()
          ...                            generic_shutdown_super()
                                           nilfs_put_super()
                                             * Prepare to write superblock *
                                             down_write(rwsem B) <--
                                             nilfs_cleanup_super()
          * Detect b-tree corruption *         nilfs_set_log_cursor()
          nilfs_bmap_convert_error()             nilfs_count_free_blocks()
            __nilfs_error()                        down_read(rwsem A) <--
              nilfs_set_error()
                down_write(rwsem B) <--
    
                               *** DEADLOCK ***
    
    Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem)
    and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata
    corruption, __nilfs_error() is called from nilfs_bmap_convert_error()
    inside the lock section.
    
    Since __nilfs_error() calls nilfs_set_error() unless the filesystem is
    read-only and nilfs_set_error() attempts to writelock rwsem B (=
    nilfs->ns_sem) to write back superblock exclusively, hierarchical lock
    acquisition occurs in the order rwsem A -> rwsem B.
    
    Now, if another task starts updating the superblock, it may writelock
    rwsem B during the lock sequence above, and can deadlock trying to
    readlock rwsem A in nilfs_count_free_blocks().
    
    However, there is actually no need to take rwsem A in
    nilfs_count_free_blocks() because it, within the lock section, only reads
    a single integer data on a shared struct with
    nilfs_sufile_get_ncleansegs().  This has been the case after commit
    aa474a220180 ("nilfs2: add local variable to cache the number of clean
    segments"), that is, even before this bug was introduced.
    
    So, this resolves the deadlock problem by just not taking the semaphore in
    nilfs_count_free_blocks().
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: e828949e5b42 ("nilfs2: call nilfs_error inside bmap routines")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]r.kernel.org>    [2.6.38+
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix use-after-free bug of ns_writer on remount [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Fri Nov 4 23:29:59 2022 +0900

    nilfs2: fix use-after-free bug of ns_writer on remount
    
    commit 8cccf05fe857a18ee26e20d11a8455a73ffd4efd upstream.
    
    If a nilfs2 filesystem is downgraded to read-only due to metadata
    corruption on disk and is remounted read/write, or if emergency read-only
    remount is performed, detaching a log writer and synchronizing the
    filesystem can be done at the same time.
    
    In these cases, use-after-free of the log writer (hereinafter
    nilfs->ns_writer) can happen as shown in the scenario below:
    
     Task1                               Task2
     --------------------------------    ------------------------------
     nilfs_construct_segment
       nilfs_segctor_sync
         init_wait
         init_waitqueue_entry
         add_wait_queue
         schedule
                                         nilfs_remount (R/W remount case)
                                           nilfs_attach_log_writer
                                             nilfs_detach_log_writer
                                               nilfs_segctor_destroy
                                                 kfree
         finish_wait
           _raw_spin_lock_irqsave
             __raw_spin_lock_irqsave
               do_raw_spin_lock
                 debug_spin_lock_before  <-- use-after-free
    
    While Task1 is sleeping, nilfs->ns_writer is freed by Task2.  After Task1
    waked up, Task1 accesses nilfs->ns_writer which is already freed.  This
    scenario diagram is based on the Shigeru Yoshida's post [1].
    
    This patch fixes the issue by not detaching nilfs->ns_writer on remount so
    that this UAF race doesn't happen.  Along with this change, this patch
    also inserts a few necessary read-only checks with superblock instance
    where only the ns_writer pointer was used to check if the filesystem is
    read-only.
    
    Link: https://syzkaller.appspot.com/bug?id=79a4c002e960419ca173d55e863bd09e8112df8b
    Link: https://lkml.kernel.org/r/[email protected] [1]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Reported-by: Shigeru Yoshida <[email protected]>
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
octeontx2-pf: Fix SQE threshold checking [+ + +]
Author: Ratheesh Kannoth <[email protected]>
Date:   Mon Nov 7 09:05:05 2022 +0530

    octeontx2-pf: Fix SQE threshold checking
    
    [ Upstream commit f0dfc4c88ef39be0ba736aa0ce6119263fc19aeb ]
    
    Current way of checking available SQE count which is based on
    HW updated SQB count could result in driver submitting an SQE
    even before CQE for the previously transmitted SQE at the same
    index is processed in NAPI resulting losing SKB pointers,
    hence a leak. Fix this by checking a consumer index which
    is updated once CQE is processed.
    
    Fixes: 3ca6c4c882a7 ("octeontx2-pf: Add packet transmission support")
    Signed-off-by: Ratheesh Kannoth <[email protected]>
    Reviewed-by: Sunil Kovvuri Goutham <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT] [+ + +]
Author: Ratheesh Kannoth <[email protected]>
Date:   Wed Nov 2 08:41:13 2022 +0530

    octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]
    
    [ Upstream commit 51afe9026d0c63263abe9840e629f118d7405b36 ]
    
    In scenarios where multiple errors have occurred
    for a SQ before SW starts handling error interrupt,
    SQ_CTX[OP_INT] may get overwritten leading to
    NIX_LF_SQ_OP_INT returning incorrect value.
    To workaround this read LMT, MNQ and SQ individual
    error status registers to determine the cause of error.
    
    Fixes: 4ff7d1488a84 ("octeontx2-pf: Error handling support")
    Signed-off-by: Ratheesh Kannoth <[email protected]>
    Reviewed-by: Sunil Kovvuri Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: hv: Fix the definition of vector in hv_compose_msi_msg() [+ + +]
Author: Dexuan Cui <[email protected]>
Date:   Thu Oct 27 13:52:56 2022 -0700

    PCI: hv: Fix the definition of vector in hv_compose_msi_msg()
    
    [ Upstream commit e70af8d040d2b7904dca93d942ba23fb722e21b1 ]
    
    The local variable 'vector' must be u32 rather than u8: see the
    struct hv_msi_desc3.
    
    'vector_count' should be u16 rather than u8: see struct hv_msi_desc,
    hv_msi_desc2 and hv_msi_desc3.
    
    Fixes: a2bad844a67b ("PCI: hv: Fix interrupt mapping for multi-MSI")
    Signed-off-by: Dexuan Cui <[email protected]>
    Cc: Jeffrey Hugo <[email protected]>
    Cc: Carl Vanderlip <[email protected]>
    Reviewed-by: Jeffrey Hugo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf stat: Fix crash with --per-node --metric-only in CSV mode [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Mon Nov 7 13:33:06 2022 -0800

    perf stat: Fix crash with --per-node --metric-only in CSV mode
    
    [ Upstream commit 84d1b2013272947ad9b13025df89226d8fa31cc5 ]
    
    The following command will get segfault due to missing aggr_header_csv
    for AGGR_NODE:
    
      $ sudo perf stat -a --per-node -x, --metric-only true
    
    Committer testing:
    
    Before this patch:
    
      # perf stat -a --per-node -x, --metric-only true
      Segmentation fault (core dumped)
      #
    
    After:
    
      # gdb perf
      -bash: gdb: command not found
      # perf stat -a --per-node -x, --metric-only true
      node,Ghz,frontend cycles idle,backend cycles idle,insn per cycle,branch-misses of all branches,
      N0,32,0.335,2.10,0.65,0.69,0.03,1.92,
      #
    
    Fixes: 86895b480a2f10c7 ("perf stat: Add --per-node agregation support")
    Signed-off-by: Namhyung Kim <[email protected]rg>
    Cc: Adrian Hunter <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Xing Zhengjun <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf stat: Fix printing os->prefix in CSV metrics output [+ + +]
Author: Athira Rajeev <[email protected]>
Date:   Tue Oct 18 14:26:04 2022 +0530

    perf stat: Fix printing os->prefix in CSV metrics output
    
    [ Upstream commit ad353b710c7493df3d4fc2d3a51819126bed2e81 ]
    
    'perf stat' with CSV output option prints an extra empty string as first
    field in metrics output line.  Sample output below:
    
            # ./perf stat -x, --per-socket -a -C 1 ls
            S0,1,1.78,msec,cpu-clock,1785146,100.00,0.973,CPUs utilized
            S0,1,26,,context-switches,1781750,100.00,0.015,M/sec
            S0,1,1,,cpu-migrations,1780526,100.00,0.561,K/sec
            S0,1,1,,page-faults,1779060,100.00,0.561,K/sec
            S0,1,875807,,cycles,1769826,100.00,0.491,GHz
            S0,1,85281,,stalled-cycles-frontend,1767512,100.00,9.74,frontend cycles idle
            S0,1,576839,,stalled-cycles-backend,1766260,100.00,65.86,backend cycles idle
            S0,1,288430,,instructions,1762246,100.00,0.33,insn per cycle
    ====>   ,S0,1,,,,,,,2.00,stalled cycles per insn
    
    The above command line uses field separator as "," via "-x," option and
    per-socket option displays socket value as first field. But here the
    last line for "stalled cycles per insn" has "," in the beginning.
    
    Sample output using interval mode:
    
            # ./perf stat -I 1000 -x, --per-socket -a -C 1 ls
            0.001813453,S0,1,1.87,msec,cpu-clock,1872052,100.00,0.002,CPUs utilized
            0.001813453,S0,1,2,,context-switches,1868028,100.00,1.070,K/sec
            ------
            0.001813453,S0,1,85379,,instructions,1856754,100.00,0.32,insn per cycle
    ====>   0.001813453,,S0,1,,,,,,,1.34,stalled cycles per insn
    
    Above result also has an extra CSV separator after
    the timestamp. Patch addresses extra field separator
    in the beginning of the metric output line.
    
    The counter stats are displayed by function
    "perf_stat__print_shadow_stats" in code
    "util/stat-shadow.c". While printing the stats info
    for "stalled cycles per insn", function "new_line_csv"
    is used as new_line callback.
    
    The new_line_csv function has check for "os->prefix"
    and if prefix is not null, it will be printed along
    with cvs separator.
    Snippet from "new_line_csv":
            if (os->prefix)
                   fprintf(os->fh, "%s%s", os->prefix, config->csv_sep);
    
    Here os->prefix gets printed followed by ","
    which is the cvs separator. The os->prefix is
    used in interval mode option ( -I ), to print
    time stamp on every new line. But prefix is
    already set to contain CSV separator when used
    in interval mode for CSV option.
    
    Reference: Function "static void print_interval"
    Snippet:
            sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, config->csv_sep);
    
    Also if prefix is not assigned (if not used with
    -I option), it gets set to empty string.
    Reference: function printout() in util/stat-display.c
    Snippet:
            .prefix = prefix ? prefix : "",
    
    Since prefix already set to contain cvs_sep in interval
    option, patch removes printing config->csv_sep in
    new_line_csv function to avoid printing extra field.
    
    After the patch:
    
            # ./perf stat -x, --per-socket -a -C 1 ls
            S0,1,2.04,msec,cpu-clock,2045202,100.00,1.013,CPUs utilized
            S0,1,2,,context-switches,2041444,100.00,979.289,/sec
            S0,1,0,,cpu-migrations,2040820,100.00,0.000,/sec
            S0,1,2,,page-faults,2040288,100.00,979.289,/sec
            S0,1,254589,,cycles,2036066,100.00,0.125,GHz
            S0,1,82481,,stalled-cycles-frontend,2032420,100.00,32.40,frontend cycles idle
            S0,1,113170,,stalled-cycles-backend,2031722,100.00,44.45,backend cycles idle
            S0,1,88766,,instructions,2030942,100.00,0.35,insn per cycle
            S0,1,,,,,,,1.27,stalled cycles per insn
    
    Fixes: 92a61f6412d3a09d ("perf stat: Implement CSV metrics output")
    Reported-by: Disha Goel <[email protected]>
    Reviewed-By: Kajol Jain <[email protected]>
    Signed-off-by: Athira Jajeev <[email protected]>
    Tested-by: Disha Goel <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: [email protected]
    Cc: Madhavan Srinivasan <[email protected]>
    Cc: Michael Ellerman <[email protected]>
    Cc: Nageswara R Sastry <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf test: Fix skipping branch stack sampling test [+ + +]
Author: James Clark <[email protected]>
Date:   Fri Oct 28 13:19:13 2022 +0100

    perf test: Fix skipping branch stack sampling test
    
    [ Upstream commit 20ebc4a649b82e6ad892684c76ea1e8dd786d336 ]
    
    Commit f4a2aade6809c657 ("perf tests powerpc: Fix branch stack sampling
    test to include sanity check for branch filter") added a skip if certain
    branch options aren't available.
    
    But the change added both -b (--branch-any) and --branch-filter options
    at the same time, which will always result in a failure on any platform
    because the arguments can't be used together.
    
    Fix this by removing -b (--branch-any) and leaving --branch-filter which
    already specifies 'any'. Also add warning messages to the test and perf
    tool.
    
    Output on x86 before this fix:
    
       $ sudo ./perf test branch
       108: Check branch stack sampling         : Skip
    
    After:
    
       $ sudo ./perf test branch
       108: Check branch stack sampling         : Ok
    
    Fixes: f4a2aade6809c657 ("perf tests powerpc: Fix branch stack sampling test to include sanity check for branch filter")
    Signed-off-by: James Clark <[email protected]>
    Tested-by: Athira Jajeev <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: [email protected]
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kajol Jain <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf tools: Add the include/perf/ directory to .gitignore [+ + +]
Author: Donglin Peng <[email protected]>
Date:   Thu Nov 3 02:27:04 2022 -0700

    perf tools: Add the include/perf/ directory to .gitignore
    
    [ Upstream commit 94d957ae513fc420d0a5a9bac815eb49ffebb56f ]
    
    Commit 3af1dfdd51e06697 ("perf build: Move perf_dlfilters.h in the
    source tree") moved perf_dlfilters.h to the include/perf/ directory
    while include/perf is ignored because it has 'perf' in the name.  Newly
    created files in the include/perf/ directory will be ignored.
    
    Testing:
    
    Before:
    
      $ touch tools/perf/include/perf/junk
      $ git status | grep junk
      $ git check-ignore -v tools/perf/include/perf/junk
      tools/perf/.gitignore:6:perf    tools/perf/include/perf/junk
    
    After:
    
      $ git status | grep junk
      tools/perf/include/perf/junk
      $ git check-ignore -v tools/perf/include/perf/junk
    
    Add !include/perf/ to perf's .gitignore file.
    
    Fixes: 3af1dfdd51e06697 ("perf build: Move perf_dlfilters.h in the source tree")
    Signed-off-by: Donglin Peng <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
phy: qcom-qmp-combo: fix NULL-deref on runtime resume [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Wed Oct 26 18:21:16 2022 +0200

    phy: qcom-qmp-combo: fix NULL-deref on runtime resume
    
    commit 04948e757148f870a31f4887ea2239403f516c3c upstream.
    
    Commit fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate
    PCS_USB region") started treating the PCS_USB registers as potentially
    separate from the PCS registers but used the wrong base when no PCS_USB
    offset has been provided.
    
    Fix the PCS_USB base used at runtime resume to prevent dereferencing a
    NULL pointer on platforms that do not provide a PCS_USB offset (e.g.
    SC7180).
    
    Fixes: fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate PCS_USB region")
    Cc: [email protected]      # 5.20
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

phy: ralink: mt7621-pci: add sentinel to quirks table [+ + +]
Author: John Thomson <[email protected]>
Date:   Sat Nov 5 06:52:41 2022 +1000

    phy: ralink: mt7621-pci: add sentinel to quirks table
    
    [ Upstream commit 819b885cd886c193782891c4f51bbcab3de119a4 ]
    
    With mt7621 soc_dev_attr fixed to register the soc as a device,
    kernel will experience an oops in soc_device_match_attr
    
    This quirk test was introduced in the staging driver in
    commit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for 'E2'
    revision using 'soc_device_attribute'"). The staging driver was removed,
    and later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver
    for MT7621 PCIe PHY") for kernel 5.11
    
    Link: https://lore.kernel.org/lkml/[email protected]
    Fixes: d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY")
    Signed-off-by: John Thomson <[email protected]>
    Acked-by: Sergio Paracuellos <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

phy: stm32: fix an error code in probe [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Oct 14 12:25:06 2022 +0300

    phy: stm32: fix an error code in probe
    
    [ Upstream commit ca1c73628f5bd0c1ef6e46073cc3be2450605b06 ]
    
    If "index > usbphyc->nphys" is true then this returns success but it
    should return -EINVAL.
    
    Fixes: 94c358da3a05 ("phy: stm32: add support for STM32 USB PHY Controller (USBPHYC)")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Amelie Delaunay <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: hp_wmi: Fix rfkill causing soft blocked wifi [+ + +]
Author: Jorge Lopez <[email protected]>
Date:   Fri Oct 28 10:55:27 2022 -0500

    platform/x86: hp_wmi: Fix rfkill causing soft blocked wifi
    
    commit 1598bfa8e1faa932de42e1ee7628a1c4c4263f0a upstream.
    
    After upgrading BIOS to U82 01.02.01 Rev.A, the console is flooded
    strange char "^@" which printed out every second and makes login
    nearly impossible. Also the below messages were shown both in console
    and journal/dmesg every second:
    
    usb 1-3: Device not responding to setup address.
    usb 1-3: device not accepting address 4, error -71
    usb 1-3: device descriptor read/all, error -71
    usb usb1-port3: unable to enumerate USB device
    
    Wifi is soft blocked by checking rfkill. When unblocked manually,
    after few seconds it would be soft blocked again. So I was suspecting
    something triggered rfkill to soft block wifi.  At the end it was
    fixed by removing hp_wmi module.
    
    The root cause is the way hp-wmi driver handles command 1B on
    post-2009 BIOS.  In pre-2009 BIOS, command 1Bh return 0x4 to indicate
    that BIOS no longer controls the power for the wireless devices.
    
    Signed-off-by: Jorge Lopez <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216468
    Reviewed-by: Mario Limonciello <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

platform/x86: p2sb: Don't fail if unknown CPU is found [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Fri Nov 4 17:49:16 2022 +0200

    platform/x86: p2sb: Don't fail if unknown CPU is found
    
    [ Upstream commit 53eb64c88f17b14b324fbdfd417f56c5d3fa6fee ]
    
    We have accessing P2SB from a very few places for quite known hardware.
    
    When a new SoC appears in intel-family.h it's not obvious that it needs
    to be added to p2sb.c as well. Instead, provide default BDF and refactor
    p2sb_get_devfn() to always succeed. If in the future we would need to
    exclude something, we may add a list of unsupported IDs.
    
    Without this change the iTCO on Intel Comet Lake SoCs became unavailable:
    
      i801_smbus 0000:00:1f.4: failed to create iTCO device
    
    Fixes: 5c7b9167ddf8 ("i2c: i801: convert to use common P2SB accessor")
    Reported-and-tested-by: Jarkko Nikula <[email protected]>
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
riscv: fix reserved memory setup [+ + +]
Author: Conor Dooley <[email protected]>
Date:   Mon Nov 7 15:15:25 2022 +0000

    riscv: fix reserved memory setup
    
    [ Upstream commit 50e63dd8ed92045eb70a72d7ec725488320fb68b ]
    
    Currently, RISC-V sets up reserved memory using the "early" copy of the
    device tree. As a result, when trying to get a reserved memory region
    using of_reserved_mem_lookup(), the pointer to reserved memory regions
    is using the early, pre-virtual-memory address which causes a kernel
    panic when trying to use the buffer's name:
    
     Unable to handle kernel paging request at virtual address 00000000401c31ac
     Oops [#1]
     Modules linked in:
     CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1
     Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
     epc : string+0x4a/0xea
      ra : vsnprintf+0x1e4/0x336
     epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0
      gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000
      t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20
      s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000
      a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff
      a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff
      s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008
      s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00
      s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002
      s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617
      t5 : ffffffff812f3618 t6 : ffffffff81203d08
     status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d
     [<ffffffff80338936>] vsnprintf+0x1e4/0x336
     [<ffffffff80055ae2>] vprintk_store+0xf6/0x344
     [<ffffffff80055d86>] vprintk_emit+0x56/0x192
     [<ffffffff80055ed8>] vprintk_default+0x16/0x1e
     [<ffffffff800563d2>] vprintk+0x72/0x80
     [<ffffffff806813b2>] _printk+0x36/0x50
     [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24
     [<ffffffff808057ec>] paging_init+0x528/0x5bc
     [<ffffffff808031ae>] setup_arch+0xd0/0x592
     [<ffffffff8080070e>] start_kernel+0x82/0x73c
    
    early_init_fdt_scan_reserved_mem() takes no arguments as it operates on
    initial_boot_params, which is populated by early_init_dt_verify(). On
    RISC-V, early_init_dt_verify() is called twice. Once, directly, in
    setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,
    very early in the boot process, by parse_dtb() when it calls
    early_init_dt_scan_nodes().
    
    This first call uses dtb_early_va to set initial_boot_params, which is
    not usable later in the boot process when
    early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the
    corresponding call to early_init_dt_scan_nodes() uses fixmap addresses
    and doesn't suffer the same fate.
    
    Move early_init_fdt_scan_reserved_mem() further along the boot sequence,
    after the direct call to early_init_dt_verify() in setup_arch() so that
    the names use the correct virtual memory addresses. The above supposed
    that CONFIG_BUILTIN_DTB was not set, but should work equally in the case
    where it is - unflatted_and_copy_device_tree() also updates
    initial_boot_params.
    
    Reported-by: Valentina Fernandez <[email protected]>
    Reported-by: Evgenii Shatokhin <[email protected]>
    Link: https://lore.kernel.org/linux-riscv/[email protected]/
    Fixes: 922b0375fc93 ("riscv: Fix memblock reservation for device tree blob")
    Signed-off-by: Conor Dooley <[email protected]>
    Tested-by: Evgenii Shatokhin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: process: fix kernel info leakage [+ + +]
Author: Jisheng Zhang <[email protected]>
Date:   Sat Oct 29 19:34:50 2022 +0800

    riscv: process: fix kernel info leakage
    
    [ Upstream commit 6510c78490c490a6636e48b61eeaa6fb65981f4b ]
    
    thread_struct's s[12] may contain random kernel memory content, which
    may be finally leaked to userspace. This is a security hole. Fix it
    by clearing the s[12] array in thread_struct when fork.
    
    As for kthread case, it's better to clear the s[12] array as well.
    
    Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
    Signed-off-by: Jisheng Zhang <[email protected]>
    Tested-by: Guo Ren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Guo Ren <[email protected]>
    Link: https://lore.kernel.org/r/CAJF2gTSdVyAaM12T%[email protected]/
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: vdso: fix build with llvm [+ + +]
Author: Jisheng Zhang <[email protected]>
Date:   Tue Nov 1 02:29:43 2022 +0800

    riscv: vdso: fix build with llvm
    
    [ Upstream commit 50f4dd657a0fcf90aa8da8dc2794a8100ff4c37c ]
    
    Even after commit 89fd4a1df829 ("riscv: jump_label: mark arguments as
    const to satisfy asm constraints"), building with CC_OPTIMIZE_FOR_SIZE
    + LLVM=1 can reproduce below build error:
    
      CC      arch/riscv/kernel/vdso/vgettimeofday.o
    In file included from <built-in>:4:
    In file included from lib/vdso/gettimeofday.c:5:
    In file included from include/vdso/datapage.h:17:
    In file included from include/vdso/processor.h:10:
    In file included from arch/riscv/include/asm/vdso/processor.h:7:
    In file included from include/linux/jump_label.h:112:
    arch/riscv/include/asm/jump_label.h:42:3: error:
    invalid operand for inline asm constraint 'i'
                    "       .option push                            \n\t"
                    ^
    1 error generated.
    
    I think the problem is when "-Os" is passed as CFLAGS, it's removed by
    "CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os" which is
    introduced in commit e05d57dcb8c7 ("riscv: Fixup __vdso_gettimeofday
    broke dynamic ftrace"), thus no optimization at all for vgettimeofday.c
    arm64 does remove "-Os" as well, but it forces "-O2" after removing
    "-Os".
    
    I compared the generated vgettimeofday.o with "-O2" and "-Os",
    I think no big performance difference. So let's tell the kbuild not
    to remove "-Os" rather than follow arm64 style.
    
    vdso related performance can be improved a lot when building kernel with
    CC_OPTIMIZE_FOR_SIZE after this commit, ("-Os" VS no optimization)
    
    Fixes: e05d57dcb8c7 ("riscv: Fixup __vdso_gettimeofday broke dynamic ftrace")
    Signed-off-by: Jisheng Zhang <[email protected]>
    Tested-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soundwire: qcom: check for outanding writes before doing a read [+ + +]
Author: Srinivas Kandagatla <[email protected]>
Date:   Wed Oct 26 12:02:06 2022 +0100

    soundwire: qcom: check for outanding writes before doing a read
    
    [ Upstream commit 49a467310dc4fae591a3547860ee04d8730780f4 ]
    
    Reading will increase the fifo count, so check for outstanding cmd wrt.
    write fifo depth to avoid overflow as read will also increase
    write fifo cnt.
    
    Fixes: a661308c34de ("soundwire: qcom: wait for fifo space to be available before read/write")
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soundwire: qcom: reinit broadcast completion [+ + +]
Author: Srinivas Kandagatla <[email protected]>
Date:   Wed Oct 26 12:02:05 2022 +0100

    soundwire: qcom: reinit broadcast completion
    
    [ Upstream commit f936fa7a954b262cb3908bbc8f01ba19dfaf9fbf ]
    
    For some reason we never reinit the broadcast completion, there is a
    danger that broadcast commands could be treated as completed by driver
    from previous complete status.
    Fix this by reinitializing the completion before sending a broadcast command.
    
    Fixes: ddea6cf7b619 ("soundwire: qcom: update register read/write routine")
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: intel: Use correct mask for flash and protected regions [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 25 09:28:00 2022 +0300

    spi: intel: Use correct mask for flash and protected regions
    
    commit 92a66cbf6b30eda5719fbdfb24cd15fb341bba32 upstream.
    
    The flash and protected region mask is actually 0x7fff (30:16 and 14:0)
    and not 0x3fff so fix this accordingly. While there use GENMASK() instead.
    
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: mediatek: Fix package division error [+ + +]
Author: zhichao.liu <[email protected]>
Date:   Fri Oct 21 17:16:53 2022 +0800

    spi: mediatek: Fix package division error
    
    [ Upstream commit cf82d0ecb84e8ef9958721193f901609b408655b ]
    
    Commit 7e963fb2a33ce ("spi: mediatek: add ipm design support
    for MT7986") makes a mistake on package dividing operation
    (one change is missing), need to fix it.
    
    Background:
    Ipm design is expanding the HW capability of dma (adjust package
    length from 1KB to 64KB), and using "dev_comp->ipm_support" flag
    to indicate it.
    
    Issue description:
    Ipm support patch (said above) is missing to handle remainder at
    package dividing operation.
    One case, a transmission length is 65KB, is will divide to 1K
    (package length) * 65(package loop) in non-ipm desgin case, and
    will divide to 64K(package length) * 1(package loop) + 1K(remainder)
    in ipm design case. And the 1K remainder will be lost with the
    current SW flow, and the transmission will be failure.
    So, it should be fixed.
    
    Solution:
    Add "ipm_design" flag in function "mtk_spi_get_mult_delta()" to
    indicate HW capability, and modify the parameters corespondingly.
    
    fixes: 7e963fb2a33ce ("spi: mediatek: add ipm design support for MT7986")
    Signed-off-by: zhichao.liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
stmmac: dwmac-loongson: fix missing of_node_put() while module exiting [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Tue Nov 8 19:46:47 2022 +0800

    stmmac: dwmac-loongson: fix missing of_node_put() while module exiting
    
    [ Upstream commit 7f94d0498f9c763f37172c08059ae91804c3075a ]
    
    The node returned by of_get_child_by_name() with refcount decremented,
    of_node_put() needs be called when finish using it. So add it in the
    error path in loongson_dwmac_probe() and in loongson_dwmac_remove().
    
    Fixes: 2ae34111fe4e ("stmmac: dwmac-loongson: fix invalid mdio_node")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

stmmac: dwmac-loongson: fix missing pci_disable_device() in loongson_dwmac_probe() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Tue Nov 8 19:46:46 2022 +0800

    stmmac: dwmac-loongson: fix missing pci_disable_device() in loongson_dwmac_probe()
    
    [ Upstream commit fe5b3ce8b4377e543960220f539b989a927afd8a ]
    
    Add missing pci_disable_device() in the error path in loongson_dwmac_probe().
    
    Fixes: 30bba69d7db4 ("stmmac: pci: Add dwmac support for Loongson")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

stmmac: dwmac-loongson: fix missing pci_disable_msi() while module exiting [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Tue Nov 8 19:46:45 2022 +0800

    stmmac: dwmac-loongson: fix missing pci_disable_msi() while module exiting
    
    [ Upstream commit f2d45fdf9a0ed2c94c01c422a0d0add8ffd42099 ]
    
    pci_enable_msi() has been called in loongson_dwmac_probe(),
    so pci_disable_msi() needs be called in remove path and error
    path of probe().
    
    Fixes: 30bba69d7db4 ("stmmac: pci: Add dwmac support for Loongson")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

stmmac: intel: Update PCH PTP clock rate from 200MHz to 204.8MHz [+ + +]
Author: Tan, Tee Min <[email protected]>
Date:   Mon Nov 7 21:08:11 2022 -0500

    stmmac: intel: Update PCH PTP clock rate from 200MHz to 204.8MHz
    
    [ Upstream commit dcea1a8107c04b9521dee1dd37971757a22db162 ]
    
    Current Intel platform has an output of ~976ms interval
    when probed on 1 Pulse-per-Second(PPS) hardware pin.
    
    The correct PTP clock frequency for PCH GbE should be 204.8MHz
    instead of 200MHz. PSE GbE PTP clock rate remains at 200MHz.
    
    Fixes: 58da0cfa6cf1 ("net: stmmac: create dwmac-intel.c to contain all Intel platform")
    Signed-off-by: Ling Pei Lee <[email protected]>
    Signed-off-by: Tan, Tee Min <[email protected]>
    Signed-off-by: Voon Weifeng <[email protected]>
    Signed-off-by: Gan Yi Fang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: prohibit TCP_REPAIR_OPTIONS if data was already sent [+ + +]
Author: Lu Wei <[email protected]>
Date:   Fri Nov 4 10:27:23 2022 +0800

    tcp: prohibit TCP_REPAIR_OPTIONS if data was already sent
    
    [ Upstream commit 0c175da7b0378445f5ef53904247cfbfb87e0b78 ]
    
    If setsockopt with option name of TCP_REPAIR_OPTIONS and opt_code
    of TCPOPT_SACK_PERM is called to enable sack after data is sent
    and dupacks are received , it will trigger a warning in function
    tcp_verify_left_out() as follows:
    
    ============================================
    WARNING: CPU: 8 PID: 0 at net/ipv4/tcp_input.c:2132
    tcp_timeout_mark_lost+0x154/0x160
    tcp_enter_loss+0x2b/0x290
    tcp_retransmit_timer+0x50b/0x640
    tcp_write_timer_handler+0x1c8/0x340
    tcp_write_timer+0xe5/0x140
    call_timer_fn+0x3a/0x1b0
    __run_timers.part.0+0x1bf/0x2d0
    run_timer_softirq+0x43/0xb0
    __do_softirq+0xfd/0x373
    __irq_exit_rcu+0xf6/0x140
    
    The warning is caused in the following steps:
    1. a socket named socketA is created
    2. socketA enters repair mode without build a connection
    3. socketA calls connect() and its state is changed to TCP_ESTABLISHED
       directly
    4. socketA leaves repair mode
    5. socketA calls sendmsg() to send data, packets_out and sack_outs(dup
       ack receives) increase
    6. socketA enters repair mode again
    7. socketA calls setsockopt with TCPOPT_SACK_PERM to enable sack
    8. retransmit timer expires, it calls tcp_timeout_mark_lost(), lost_out
       increases
    9. sack_outs + lost_out > packets_out triggers since lost_out and
       sack_outs increase repeatly
    
    In function tcp_timeout_mark_lost(), tp->sacked_out will be cleared if
    Step7 not happen and the warning will not be triggered. As suggested by
    Denis and Eric, TCP_REPAIR_OPTIONS should be prohibited if data was
    already sent.
    
    socket-tcp tests in CRIU has been tested as follows:
    $ sudo ./test/zdtm.py run -t zdtm/static/socket-tcp*  --keep-going \
           --ignore-taint
    
    socket-tcp* represent all socket-tcp tests in test/zdtm/static/.
    
    Fixes: b139ba4e90dc ("tcp: Repair connection-time negotiated parameters")
    Signed-off-by: Lu Wei <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thunderbolt: Add DP OUT resource when DP tunnel is discovered [+ + +]
Author: Sanjay R Mehta <[email protected]>
Date:   Thu Aug 4 05:48:38 2022 -0500

    thunderbolt: Add DP OUT resource when DP tunnel is discovered
    
    commit b60e31bf18a7064032dbcb73dcb5b58f8a00a110 upstream.
    
    If the boot firmware implements a connection manager of its own it may
    create a DisplayPort tunnel and will be handed off to Linux connection
    manager, but the DP OUT resource is not saved in the dp_resource list.
    
    This patch adds tunnelled DP OUT port to the dp_resource list once the
    DP tunnel is discovered.
    
    Signed-off-by: Sanjay R Mehta <[email protected]>
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Tested-by: Renjith Pananchikkal <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Cc: "Limonciello, Mario" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header [+ + +]
Author: Xin Long <[email protected]>
Date:   Fri Nov 4 16:48:53 2022 -0400

    tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header
    
    [ Upstream commit 1c075b192fe41030457cd4a5f7dea730412bca40 ]
    
    This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value
    in tipc_nl_compat_name_table_dump") where it should have type casted
    sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative
    value.
    
    syzbot reported a call trace because of it:
    
      BUG: KMSAN: uninit-value in ...
       tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934
       __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238
       tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321
       tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324
       genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
       genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
       netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
       genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
       netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
       netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
       netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
       sock_sendmsg_nosec net/socket.c:714 [inline]
       sock_sendmsg net/socket.c:734 [inline]
    
    Reported-by: [email protected]
    Fixes: 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump")
    Signed-off-by: Xin Long <[email protected]>
    Link: https://lore.kernel.org/r/ccd[email protected]gmail.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
udf: Fix a slab-out-of-bounds write bug in udf_find_entry() [+ + +]
Author: ZhangPeng <[email protected]>
Date:   Wed Nov 9 01:35:42 2022 +0000

    udf: Fix a slab-out-of-bounds write bug in udf_find_entry()
    
    commit c8af247de385ce49afabc3bf1cf4fd455c94bfe8 upstream.
    
    Syzbot reported a slab-out-of-bounds Write bug:
    
    loop0: detected capacity change from 0 to 2048
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0
    fs/udf/namei.c:253
    Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
    
    CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted
    6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
    Hardware name: Google Compute Engine/Google Compute Engine, BIOS
    Google 10/11/2022
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
     print_address_description+0x74/0x340 mm/kasan/report.c:284
     print_report+0x107/0x1f0 mm/kasan/report.c:395
     kasan_report+0xcd/0x100 mm/kasan/report.c:495
     kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189
     memcpy+0x3c/0x60 mm/kasan/shadow.c:66
     udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253
     udf_lookup+0xef/0x340 fs/udf/namei.c:309
     lookup_open fs/namei.c:3391 [inline]
     open_last_lookups fs/namei.c:3481 [inline]
     path_openat+0x10e6/0x2df0 fs/namei.c:3710
     do_filp_open+0x264/0x4f0 fs/namei.c:3740
     do_sys_openat2+0x124/0x4e0 fs/open.c:1310
     do_sys_open fs/open.c:1326 [inline]
     __do_sys_creat fs/open.c:1402 [inline]
     __se_sys_creat fs/open.c:1396 [inline]
     __x64_sys_creat+0x11f/0x160 fs/open.c:1396
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7ffab0d164d9
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89
    f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
    f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9
    RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180
    RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000
    R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    
    Allocated by task 3610:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
     ____kasan_kmalloc mm/kasan/common.c:371 [inline]
     __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380
     kmalloc include/linux/slab.h:576 [inline]
     udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243
     udf_lookup+0xef/0x340 fs/udf/namei.c:309
     lookup_open fs/namei.c:3391 [inline]
     open_last_lookups fs/namei.c:3481 [inline]
     path_openat+0x10e6/0x2df0 fs/namei.c:3710
     do_filp_open+0x264/0x4f0 fs/namei.c:3740
     do_sys_openat2+0x124/0x4e0 fs/open.c:1310
     do_sys_open fs/open.c:1326 [inline]
     __do_sys_creat fs/open.c:1402 [inline]
     __se_sys_creat fs/open.c:1396 [inline]
     __x64_sys_creat+0x11f/0x160 fs/open.c:1396
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    The buggy address belongs to the object at ffff8880123ff800
     which belongs to the cache kmalloc-256 of size 256
    The buggy address is located 150 bytes inside of
     256-byte region [ffff8880123ff800, ffff8880123ff900)
    
    The buggy address belongs to the physical page:
    page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000
    index:0x0 pfn:0x123fe
    head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0
    flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
    raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40
    raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),
    pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0
     create_dummy_stack mm/page_owner.c:67 [inline]
     register_early_stack+0x77/0xd0 mm/page_owner.c:83
     init_page_owner+0x3a/0x731 mm/page_owner.c:93
     kernel_init_freeable+0x41c/0x5d5 init/main.c:1629
     kernel_init+0x19/0x2b0 init/main.c:1519
    page_owner free stack trace missing
    
    Memory state around the buggy address:
     ffff8880123ff780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff8880123ff800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff8880123ff880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06
                                                                    ^
     ffff8880123ff900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff8880123ff980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    ==================================================================
    
    Fix this by changing the memory size allocated for copy_name from
    UDF_NAME_LEN(254) to UDF_NAME_LEN_CS0(255), because the total length
    (lfi) of subsequent memcpy can be up to 255.
    
    CC: [email protected]
    Reported-by: [email protected]
    Fixes: 066b9cded00b ("udf: Use separate buffer for copying split names")
    Signed-off-by: ZhangPeng <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vmlinux.lds.h: Fix placement of '.data..decrypted' section [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Tue Nov 8 10:49:34 2022 -0700

    vmlinux.lds.h: Fix placement of '.data..decrypted' section
    
    commit 000f8870a47bdc36730357883b6aef42bced91ee upstream.
    
    Commit d4c639990036 ("vmlinux.lds.h: Avoid orphan section with !SMP")
    fixed an orphan section warning by adding the '.data..decrypted' section
    to the linker script under the PERCPU_DECRYPTED_SECTION define but that
    placement introduced a panic with !SMP, as the percpu sections are not
    instantiated with that configuration so attempting to access variables
    defined with DEFINE_PER_CPU_DECRYPTED() will result in a page fault.
    
    Move the '.data..decrypted' section to the DATA_MAIN define so that the
    variables in it are properly instantiated at boot time with
    CONFIG_SMP=n.
    
    Cc: [email protected]
    Fixes: d4c639990036 ("vmlinux.lds.h: Avoid orphan section with !SMP")
    Link: https://lore.kernel.org/[email protected]/
    Debugged-by: Ard Biesheuvel <[email protected]>
    Reported-by: Zhao Wenhui <[email protected]>
    Tested-by: xiafukun <[email protected]>
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update() [+ + +]
Author: Wen Gong <[email protected]>
Date:   Wed Nov 2 13:48:03 2022 +0200

    wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
    
    commit f45cb6b29cd36514e13f7519770873d8c0457008 upstream.
    
    (cherry picked from commit d99884ad9e3673a12879bc2830f6e5a66cccbd78 in ath-next
    as users are seeing this bug more now, also cc stable)
    
    Running this test in a loop it is easy to reproduce an rtnl deadlock:
    
    iw reg set FI
    ifconfig wlan0 down
    
    What happens is that thread A (workqueue) tries to update the regulatory:
    
        try to acquire the rtnl_lock of ar->regd_update_work
    
        rtnl_lock+0x17/0x20
        ath11k_regd_update+0x15a/0x260 [ath11k]
        ath11k_regd_update_work+0x15/0x20 [ath11k]
        process_one_work+0x228/0x670
        worker_thread+0x4d/0x440
        kthread+0x16d/0x1b0
        ret_from_fork+0x22/0x30
    
    And thread B (ifconfig) tries to stop the interface:
    
        try to cancel_work_sync(&ar->regd_update_work) in ath11k_mac_op_stop().
        ifconfig  3109 [003]  2414.232506: probe:
    
        ath11k_mac_op_stop: (ffffffffc14187a0)
        drv_stop+0x30 ([mac80211])
        ieee80211_do_stop+0x5d2 ([mac80211])
        ieee80211_stop+0x3e ([mac80211])
        __dev_close_many+0x9e ([kernel.kallsyms])
        __dev_change_flags+0xbe ([kernel.kallsyms])
        dev_change_flags+0x23 ([kernel.kallsyms])
        devinet_ioctl+0x5e3 ([kernel.kallsyms])
        inet_ioctl+0x197 ([kernel.kallsyms])
        sock_do_ioctl+0x4d ([kernel.kallsyms])
        sock_ioctl+0x264 ([kernel.kallsyms])
        __x64_sys_ioctl+0x92 ([kernel.kallsyms])
        do_syscall_64+0x3a ([kernel.kallsyms])
        entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms])
        __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
    
    The sequence of deadlock is:
    
    1. Thread B calls rtnl_lock().
    
    2. Thread A starts to run and calls rtnl_lock() from within
       ath11k_regd_update_work(), then enters wait state because the lock is owned by
       thread B.
    
    3. Thread B continues to run and tries to call
       cancel_work_sync(&ar->regd_update_work), but thread A is in
       ath11k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync()
       forever waits for ath11k_regd_update_work() to finish and we have a deadlock.
    
    Fix this by switching from using regulatory_set_wiphy_regd_sync() to
    regulatory_set_wiphy_regd(). Now cfg80211 will schedule another workqueue which
    handles the locking on it's own. So the ath11k workqueue can simply exit without
    taking any locks, avoiding the deadlock.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
    
    Cc: <[email protected]>
    Signed-off-by: Wen Gong <[email protected]>
    [kvalo: improve commit log]
    Signed-off-by: Kalle Valo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: cfg80211: fix memory leak in query_regdb_file() [+ + +]
Author: Arend van Spriel <[email protected]>
Date:   Thu Oct 20 13:40:40 2022 +0200

    wifi: cfg80211: fix memory leak in query_regdb_file()
    
    [ Upstream commit 57b962e627ec0ae53d4d16d7bd1033e27e67677a ]
    
    In the function query_regdb_file() the alpha2 parameter is duplicated
    using kmemdup() and subsequently freed in regdb_fw_cb(). However,
    request_firmware_nowait() can fail without calling regdb_fw_cb() and
    thus leak memory.
    
    Fixes: 007f6c5e6eb4 ("cfg80211: support loading regulatory database as firmware file")
    Signed-off-by: Arend van Spriel <[email protected]roadcom.com>
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: silence a sparse RCU warning [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Thu Oct 13 19:41:51 2022 +0200

    wifi: cfg80211: silence a sparse RCU warning
    
    [ Upstream commit 03c0ad4b06c3566de624b4f4b78ac1a5d1e4c8e7 ]
    
    All we're going to do with this pointer is assign it to
    another __rcu pointer, but sparse can't see that, so
    use rcu_access_pointer() to silence the warning here.
    
    Fixes: c90b93b5b782 ("wifi: cfg80211: update hidden BSSes to avoid WARN_ON")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Wed Oct 26 14:39:59 2022 +0800

    wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit()
    
    [ Upstream commit 780854186946e0de2be192ee7fa5125666533b3a ]
    
    When device is running and the interface status is changed, the gpf issue
    is triggered. The problem triggering process is as follows:
    Thread A:                           Thread B
    ieee80211_runtime_change_iftype()   process_one_work()
        ...                                 ...
        ieee80211_do_stop()                 ...
        ...                                 ...
            sdata->bss = NULL               ...
            ...                             ieee80211_subif_start_xmit()
                                                ieee80211_multicast_to_unicast
                                        //!sdata->bss->multicast_to_unicast
                                          cause gpf issue
    
    When the interface status is changed, the sending queue continues to send
    packets. After the bss is set to NULL, the bss is accessed. As a result,
    this causes a general-protection-fault issue.
    
    The following is the stack information:
    general protection fault, probably for non-canonical address
    0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f]
    Workqueue: mld mld_ifc_work
    RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310
    Call Trace:
    <TASK>
    dev_hard_start_xmit+0x1be/0x990
    __dev_queue_xmit+0x2c9a/0x3b60
    ip6_finish_output2+0xf92/0x1520
    ip6_finish_output+0x6af/0x11e0
    ip6_output+0x1ed/0x540
    mld_sendpack+0xa09/0xe70
    mld_ifc_work+0x71c/0xdb0
    process_one_work+0x9bf/0x1710
    worker_thread+0x665/0x1080
    kthread+0x2e4/0x3a0
    ret_from_fork+0x1f/0x30
    </TASK>
    
    Fixes: f856373e2f31 ("wifi: mac80211: do not wake queues on a vif that is being stopped")
    Reported-by: [email protected]
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: Set TWT Information Frame Disabled bit as 1 [+ + +]
Author: Howard Hsu <[email protected]>
Date:   Thu Oct 27 09:56:53 2022 +0800

    wifi: mac80211: Set TWT Information Frame Disabled bit as 1
    
    [ Upstream commit 30ac96f7cc973bb850c718c9bbe1fdcedfbe826b ]
    
    The TWT Information Frame Disabled bit of control field of TWT Setup
    frame shall be set to 1 since handling TWT Information frame is not
    supported by current mac80211 implementation.
    
    Fixes: f5a4c24e689f ("mac80211: introduce individual TWT support in AP mode")
    Signed-off-by: Howard Hsu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/cpu: Restore AMD's DE_CFG MSR after resume [+ + +]
Author: Borislav Petkov <[email protected]>
Date:   Mon Nov 14 12:44:01 2022 +0100

    x86/cpu: Restore AMD's DE_CFG MSR after resume
    
    commit 2632daebafd04746b4b96c2f26a6021bc38f6209 upstream.
    
    DE_CFG contains the LFENCE serializing bit, restore it on resume too.
    This is relevant to older families due to the way how they do S3.
    
    Unify and correct naming while at it.
    
    Fixes: e4d0e84e4907 ("x86/cpu/AMD: Make LFENCE a serializing instruction")
    Reported-by: Andrew Cooper <[email protected]>
    Reported-by: Pawan Gupta <[email protected]>
    Signed-off-by: Borislav Petkov <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>