óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 6.1.62

 
ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk detection [+ + +]
Author: Mark Hasemeyer <[email protected]>
Date:   Wed Oct 18 17:59:31 2023 -0600

    ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk detection
    
    commit 7c05b44e1a50d9cbfc4f731dddc436a24ddc129a upstream.
    
    Some Jasperlake Chromebooks overwrite the system vendor DMI value to the
    name of the OEM that manufactured the device. This breaks Chromebook
    quirk detection as it expects the system vendor to be "Google".
    
    Add another quirk detection entry that looks for "Google" in the BIOS
    version.
    
    Cc: [email protected]
    Signed-off-by: Mark Hasemeyer <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[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 flag to enable native DSD for McIntosh devices [+ + +]
Author: Max McCarthy <[email protected]>
Date:   Tue Oct 24 12:30:19 2023 +0000

    ALSA: usb-audio: add quirk flag to enable native DSD for McIntosh devices
    
    commit 99248c8902f505ec064cf2b0f74629016f2f4c82 upstream.
    
    McIntosh devices supporting native DSD require the feature to be
    explicitly exposed. Add a flag that fixes an issue where DSD audio was
    defaulting to DSD over PCM instead of delivering raw DSD data.
    
    Signed-off-by: Max McCarthy <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/BL0PR13MB4433226005162D186A8DFF4AD6DFA@BL0PR13MB4433.namprd13.prod.outlook.com
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ASoC: codecs: tas2780: Fix log of failed reset via I2C. [+ + +]
Author: Roy Chateau <[email protected]>
Date:   Fri Oct 13 13:02:39 2023 +0200

    ASoC: codecs: tas2780: Fix log of failed reset via I2C.
    
    [ Upstream commit 4e9a429ae80657bdc502d3f5078e2073656ec5fd ]
    
    Correctly log failures of reset via I2C.
    
    Signed-off-by: Roy Chateau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt5650: fix the wrong result of key button [+ + +]
Author: Shuming Fan <[email protected]>
Date:   Fri Oct 13 17:45:25 2023 +0800

    ASoC: rt5650: fix the wrong result of key button
    
    [ Upstream commit f88dfbf333b3661faff996bb03af2024d907b76a ]
    
    The RT5650 should enable a power setting for button detection to avoid the wrong result.
    
    Signed-off-by: Shuming Fan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: simple-card: fixup asoc_simple_probe() error handling [+ + +]
Author: Kuninori Morimoto <[email protected]>
Date:   Tue Sep 19 05:34:18 2023 +0000

    ASoC: simple-card: fixup asoc_simple_probe() error handling
    
    [ Upstream commit 41bae58df411f9accf01ea660730649b2fab1dab ]
    
    asoc_simple_probe() is used for both "DT probe" (A) and "platform probe"
    (B). It uses "goto err" when error case, but it is not needed for
    "platform probe" case (B). Thus it is using "return" directly there.
    
            static int asoc_simple_probe(...)
            {
     ^              if (...) {
     |                      ...
    (A)                     if (ret < 0)
     |                              goto err;
     v              } else {
     ^                      ...
     |                      if (ret < 0)
    (B)                             return -Exxx;
     v              }
    
                    ...
     ^              if (ret < 0)
    (C)                     goto err;
     v              ...
    
            err:
    (D)             simple_util_clean_reference(card);
    
                    return ret;
            }
    
    Both case are using (C) part, and it calls (D) when err case.
    But (D) will do nothing for (B) case.
    Because of these behavior, current code itself is not wrong,
    but is confusable, and more, static analyzing tool will warning on
    (B) part (should use goto err).
    
    To avoid static analyzing tool warning, this patch uses "goto err"
    on (B) part.
    
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
ASoC: SOF: sof-pci-dev: Fix community key quirk detection [+ + +]
Author: Mark Hasemeyer <[email protected]>
Date:   Fri Oct 20 14:59:53 2023 -0600

    ASoC: SOF: sof-pci-dev: Fix community key quirk detection
    
    commit 7dd692217b861a8292ff8ac2c9d4458538fd6b96 upstream.
    
    Some Chromebooks do not populate the product family DMI value resulting
    in firmware load failures.
    
    Add another quirk detection entry that looks for "Google" in the BIOS
    version. Theoretically, PRODUCT_FAMILY could be replaced with
    BIOS_VERSION, but it is left as a quirk to be conservative.
    
    Cc: [email protected]
    Signed-off-by: Mark Hasemeyer <[email protected]>
    Acked-by: Curtis Malainey <[email protected]>
    Link: https://lore.kernel.org/r/20231020145953.v1.1.Iaf5702dc3f8af0fd2f81a22ba2da1a5e15b3604c@changeid
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: tlv320adc3xxx: BUG: Correct micbias setting [+ + +]
Author: Antoine Gennart <[email protected]>
Date:   Fri Sep 29 15:01:17 2023 +0200

    ASoC: tlv320adc3xxx: BUG: Correct micbias setting
    
    [ Upstream commit e930bea4124b8a4a47ba4092d99da30099b9242d ]
    
    The micbias setting for tlv320adc can also have the value '3' which
    means that the micbias ouput pin is connected to the input pin AVDD.
    
    Signed-off-by: Antoine Gennart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ceph_wait_on_conflict_unlink(): grab reference before dropping ->d_lock [+ + +]
Author: Al Viro <[email protected]>
Date:   Thu Sep 14 21:55:29 2023 -0400

    ceph_wait_on_conflict_unlink(): grab reference before dropping ->d_lock
    
    [ Upstream commit dc32464a5fe4946fe1a4d8f8e29961dc411933c5 ]
    
    Use of dget() after we'd dropped ->d_lock is too late - dentry might
    be gone by that point.
    
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: tmc-etr: Disable warnings for allocation failures [+ + +]
Author: Suzuki K Poulose <[email protected]>
Date:   Thu Aug 17 17:19:51 2023 +0100

    coresight: tmc-etr: Disable warnings for allocation failures
    
    [ Upstream commit e5028011885a85032aa3c1b7e3e493bcdacb4a0a ]
    
    Running the following command on Juno triggers the warning:
    
     $ perf record -e cs_etm// -m ,128M ...
    
     ------------[ cut here ]------------
     WARNING: CPU: 1 PID: 412 at mm/page_alloc.c:4453 __alloc_pages+0x334/0x1420
     CPU: 1 PID: 412 Comm: perf Not tainted 6.5.0-rc3+ #181
     Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb  1 2019
     pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : __alloc_pages+0x334/0x1420
     lr : dma_common_alloc_pages+0x108/0x138
     sp : ffffffc087fb7440
     x29: ffffffc087fb7440 x28: 0000000000000000 x27: ffffffc07e48fba0
     x26: 0000000000000001 x25: 000000000000000f x24: ffffffc081f24880
     x23: 0000000000000cc0 x22: ffffff88012b6f08 x21: 0000000008000000
     x20: ffffff8801433000 x19: 0000000000000000 x18: 0000000000000000
     x17: ffffffc080316e5c x16: ffffffc07e46406c x15: ffffffc0803af580
     x14: ffffffc08036b460 x13: ffffffc080025cbc x12: ffffffb8108c3fc4
     x11: 1ffffff8108c3fc3 x10: 1ffffff810ff6eac x9 : 00000000f204f204
     x8 : 000000000000f204 x7 : 00000000f2f2f2f2 x6 : 00000000f3f3f3f3
     x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000000
     x2 : 0000000000000cc0 x1 : 0000000000000000 x0 : ffffffc085333000
     Call trace:
      __alloc_pages+0x334/0x1420
      dma_common_alloc_pages+0x108/0x138
      __dma_alloc_pages+0xf4/0x108
      dma_alloc_pages+0x18/0x30
      tmc_etr_alloc_flat_buf+0xa0/0x190 [coresight_tmc]
      tmc_alloc_etr_buf.constprop.0+0x124/0x298 [coresight_tmc]
      alloc_etr_buf.constprop.0.isra.0+0x88/0xc8 [coresight_tmc]
      tmc_alloc_etr_buffer+0x164/0x2f0 [coresight_tmc]
      etm_setup_aux+0x32c/0x520 [coresight]
      rb_alloc_aux+0x29c/0x3f8
      perf_mmap+0x59c/0xce0
      mmap_region+0x340/0x10e0
      do_mmap+0x48c/0x580
      vm_mmap_pgoff+0x160/0x248
      ksys_mmap_pgoff+0x1e8/0x278
      __arm64_sys_mmap+0x8c/0xb8
    
    With the flat mode, we only attempt to allocate large memory if there is an IOMMU
    connected to the ETR. If the allocation fails, we always have a fallback path
    and return an error if nothing else worked. So, suppress the warning for flat
    mode allocations.
    
    Cc: Mike Leach <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Anshuman Khandual <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Reviewed-by: James Clark <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: ste_dma40: Fix PM disable depth imbalance in d40_probe [+ + +]
Author: Zhang Shurong <[email protected]>
Date:   Thu Oct 5 22:28:35 2023 +0800

    dmaengine: ste_dma40: Fix PM disable depth imbalance in d40_probe
    
    [ Upstream commit 0618c077a8c20e8c81e367988f70f7e32bb5a717 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context.
    We fix it by calling pm_runtime_disable when error returns.
    
    Signed-off-by: Zhang Shurong <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: Reserve fences for VM update [+ + +]
Author: Felix Kuehling <[email protected]>
Date:   Mon Jul 17 15:28:52 2023 -0400

    drm/amdgpu: Reserve fences for VM update
    
    [ Upstream commit 316baf09d355aec1179981b6dfe28eba50c5ee5b ]
    
    In amdgpu_dma_buf_move_notify reserve fences for the page table updates
    in amdgpu_vm_clear_freed and amdgpu_vm_handle_moved. This fixes a BUG_ON
    in dma_resv_add_fence when using SDMA for page table updates.
    
    Signed-off-by: Felix Kuehling <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Unset context priority is now invalid [+ + +]
Author: Luben Tuikov <[email protected]>
Date:   Mon Oct 16 22:24:39 2023 -0400

    drm/amdgpu: Unset context priority is now invalid
    
    [ Upstream commit eab0261967aeab528db4d0a51806df8209aec179 ]
    
    A context priority value of AMD_CTX_PRIORITY_UNSET is now invalid--instead of
    carrying it around and passing it to the Direct Rendering Manager--and it
    becomes AMD_CTX_PRIORITY_NORMAL in amdgpu_ctx_ioctl(), the gateway to context
    creation.
    
    Cc: Alex Deucher <[email protected]>
    Cc: Christian König <[email protected]>
    Signed-off-by: Luben Tuikov <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/ttm: Reorder sys manager cleanup step [+ + +]
Author: Karolina Stolarek <[email protected]>
Date:   Mon Oct 16 14:15:25 2023 +0200

    drm/ttm: Reorder sys manager cleanup step
    
    [ Upstream commit 3b401e30c249849d803de6c332dad2a595a58658 ]
    
    With the current cleanup flow, we could trigger a NULL pointer
    dereference if there is a delayed destruction of a BO with a
    system resource that gets executed on drain_workqueue() call,
    as we attempt to free a resource using an already released
    resource manager.
    
    Remove the device from the device list and drain its workqueue
    before releasing the system domain manager in ttm_device_fini().
    
    Signed-off-by: Karolina Stolarek <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Christian König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
efi: fix memory leak in krealloc failure handling [+ + +]
Author: Kuan-Wei Chiu <[email protected]>
Date:   Sun Sep 24 22:26:33 2023 +0800

    efi: fix memory leak in krealloc failure handling
    
    [ Upstream commit 0d3ad1917996839a5042d18f04e41915cfa1b74a ]
    
    In the previous code, there was a memory leak issue where the
    previously allocated memory was not freed upon a failed krealloc
    operation. This patch addresses the problem by releasing the old memory
    before setting the pointer to NULL in case of a krealloc failure. This
    ensures that memory is properly managed and avoids potential memory
    leaks.
    
    Signed-off-by: Kuan-Wei Chiu <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: atyfb: only use ioremap_uc() on i386 and ia64 [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Sep 21 19:04:21 2023 +0800

    fbdev: atyfb: only use ioremap_uc() on i386 and ia64
    
    [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ]
    
    ioremap_uc() is only meaningful on old x86-32 systems with the PAT
    extension, and on ia64 with its slightly unconventional ioremap()
    behavior, everywhere else this is the same as ioremap() anyway.
    
    Change the only driver that still references ioremap_uc() to only do so
    on x86-32/ia64 in order to allow removing that interface at some
    point in the future for the other architectures.
    
    On some architectures, ioremap_uc() just returns NULL, changing
    the driver to call ioremap() means that they now have a chance
    of working correctly.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Baoquan He <[email protected]>
    Reviewed-by: Luis Chamberlain <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Christophe Leroy <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: omapfb: fix some error codes [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Oct 16 14:19:52 2023 +0300

    fbdev: omapfb: fix some error codes
    
    [ Upstream commit dc608db793731426938baa2f0e75a4a3cce5f5cf ]
    
    Return negative -ENXIO instead of positive ENXIO.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: uvesafb: Call cn_del_callback() at the end of uvesafb_exit() [+ + +]
Author: Jorge Maidana <[email protected]>
Date:   Fri Oct 6 17:43:47 2023 -0300

    fbdev: uvesafb: Call cn_del_callback() at the end of uvesafb_exit()
    
    [ Upstream commit 1022e7e2f40574c74ed32c3811b03d26b0b81daf ]
    
    Delete the v86d netlink only after all the VBE tasks have been
    completed.
    
    Fixes initial state restore on module unload:
    uvesafb: VBE state restore call failed (eax=0x4f04, err=-19)
    
    Signed-off-by: Jorge Maidana <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/ntfs3: Add ckeck in ni_update_parent() [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jun 30 15:52:19 2023 +0400

    fs/ntfs3: Add ckeck in ni_update_parent()
    
    [ Upstream commit 87d1888aa40f25773fa0b948bcb2545f97e2cb15 ]
    
    Check simple case when parent inode equals current inode.
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Avoid possible memory leak [+ + +]
Author: Su Hui <[email protected]>
Date:   Mon Sep 25 12:48:07 2023 +0800

    fs/ntfs3: Avoid possible memory leak
    
    [ Upstream commit e4494770a5cad3c9d1d2a65ed15d07656c0d9b82 ]
    
    smatch warn:
    fs/ntfs3/fslog.c:2172 last_log_lsn() warn: possible memory leak of 'page_bufs'
    Jump to label 'out' to free 'page_bufs' and is more consistent with
    other code.
    
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Fix directory element type detection [+ + +]
Author: Gabriel Marcano <[email protected]>
Date:   Tue Sep 12 21:50:32 2023 -0700

    fs/ntfs3: Fix directory element type detection
    
    [ Upstream commit 85a4780dc96ed9dd643bbadf236552b3320fae26 ]
    
    Calling stat() from userspace correctly identified junctions in an NTFS
    partition as symlinks, but using readdir() and iterating through the
    directory containing the same junction did not identify the junction
    as a symlink.
    
    When emitting directory contents, check FILE_ATTRIBUTE_REPARSE_POINT
    attribute to detect junctions and report them as links.
    
    Signed-off-by: Gabriel Marcano <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Fix NULL pointer dereference on error in attr_allocate_frame() [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Tue Sep 26 11:28:11 2023 +0300

    fs/ntfs3: Fix NULL pointer dereference on error in attr_allocate_frame()
    
    [ Upstream commit 9c689c8dc86f8ca99bf91c05f24c8bab38fe7d5f ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Fix possible NULL-ptr-deref in ni_readpage_cmpr() [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Tue Sep 26 11:19:08 2023 +0300

    fs/ntfs3: Fix possible NULL-ptr-deref in ni_readpage_cmpr()
    
    [ Upstream commit 32e9212256b88f35466642f9c939bb40cfb2c2de ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Use kvmalloc instead of kmalloc(... __GFP_NOWARN) [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jun 30 16:12:58 2023 +0400

    fs/ntfs3: Use kvmalloc instead of kmalloc(... __GFP_NOWARN)
    
    [ Upstream commit fc471e39e38fea6677017cbdd6d928088a59fc67 ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Write immediately updated ntfs state [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jun 30 15:57:19 2023 +0400

    fs/ntfs3: Write immediately updated ntfs state
    
    [ Upstream commit 06ccfb00645990a9fcc14249e6d1c25921ecb836 ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET [+ + +]
Author: Luben Tuikov <[email protected]>
Date:   Mon Oct 16 22:48:56 2023 -0400

    gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET
    
    [ Upstream commit fa8391ad68c16716e2c06ada397e99ceed2fb647 ]
    
    Eliminate DRM_SCHED_PRIORITY_UNSET, value of -2, whose only user was
    amdgpu. Furthermore, eliminate an index bug, in that when amdgpu boots, it
    calls drm_sched_entity_init() with DRM_SCHED_PRIORITY_UNSET, which uses it to
    index sched->sched_rq[].
    
    Cc: Alex Deucher <[email protected]>
    Cc: Christian König <[email protected]>
    Signed-off-by: Luben Tuikov <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: synaptics-rmi4 - handle reset delay when using SMBus trsnsport [+ + +]
Author: Dmitry Torokhov <[email protected]>
Date:   Fri Oct 13 17:29:57 2023 -0700

    Input: synaptics-rmi4 - handle reset delay when using SMBus trsnsport
    
    [ Upstream commit 5030b2fe6aab37fe42d14f31842ea38be7c55c57 ]
    
    Touch controllers need some time after receiving reset command for the
    firmware to finish re-initializing and be ready to respond to commands
    from the host. The driver already had handling for the post-reset delay
    for I2C and SPI transports, this change adds the handling to
    SMBus-connected devices.
    
    SMBus devices are peculiar because they implement legacy PS/2
    compatibility mode, so reset is actually issued by psmouse driver on the
    associated serio port, after which the control is passed to the RMI4
    driver with SMBus companion device.
    
    Note that originally the delay was added to psmouse driver in
    92e24e0e57f7 ("Input: psmouse - add delay when deactivating for SMBus
    mode"), but that resulted in an unwanted delay in "fast" reconnect
    handler for the serio port, so it was decided to revert the patch and
    have the delay being handled in the RMI4 driver, similar to the other
    transports.
    
    Tested-by: Jeffery Miller <[email protected]>
    Link: https://lore.kernel.org/r/ZR1yUFJ8a9Zt606N@penguin
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring: kiocb_done() should *not* trust ->ki_pos if ->{read,write}_iter() failed [+ + +]
Author: Al Viro <[email protected]>
Date:   Mon Aug 28 18:47:31 2023 -0400

    io_uring: kiocb_done() should *not* trust ->ki_pos if ->{read,write}_iter() failed
    
    [ Upstream commit 1939316bf988f3e49a07d9c4dd6f660bf4daa53d ]
    
    ->ki_pos value is unreliable in such cases.  For an obvious example,
    consider O_DSYNC write - we feed the data to page cache and start IO,
    then we make sure it's completed.  Update of ->ki_pos is dealt with
    by the first part; failure in the second ends up with negative value
    returned _and_ ->ki_pos left advanced as if sync had been successful.
    In the same situation write(2) does not advance the file position
    at all.
    
    Reviewed-by: Christian Brauner <[email protected]>
    Reviewed-by: Jens Axboe <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/riscv-intc: Mark all INTC nodes as initialized [+ + +]
Author: Anup Patel <[email protected]>
Date:   Tue Oct 3 10:13:51 2023 +0530

    irqchip/riscv-intc: Mark all INTC nodes as initialized
    
    [ Upstream commit e13cd66bd821be417c498a34928652db4ac6b436 ]
    
    The RISC-V INTC local interrupts are per-HART (or per-CPU) so we
    create INTC IRQ domain only for the INTC node belonging to the boot
    HART. This means only the boot HART INTC node will be marked as
    initialized and other INTC nodes won't be marked which results
    downstream interrupt controllers (such as PLIC, IMSIC and APLIC
    direct-mode) not being probed due to missing device suppliers.
    
    To address this issue, we mark all INTC node for which we don't
    create IRQ domain as initialized.
    
    Reported-by: Dmitry Dunaev <[email protected]>
    Signed-off-by: Anup Patel <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/stm32-exti: add missing DT IRQ flag translation [+ + +]
Author: Ben Wolsieffer <[email protected]>
Date:   Tue Oct 3 12:20:03 2023 -0400

    irqchip/stm32-exti: add missing DT IRQ flag translation
    
    [ Upstream commit 8554cba1d6dbd3c74e0549e28ddbaccbb1d6b30a ]
    
    The STM32F4/7 EXTI driver was missing the xlate callback, so IRQ trigger
    flags specified in the device tree were being ignored. This was
    preventing the RTC alarm interrupt from working, because it must be set
    to trigger on the rising edge to function correctly.
    
    Signed-off-by: Ben Wolsieffer <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.1.62 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Nov 8 14:11:05 2023 +0100

    Linux 6.1.62
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Conor Dooley <[email protected]>
    Tested-by: Ricardo B. Marliere <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
LoongArch: Export symbol invalid_pud_table for modules building [+ + +]
Author: Huacai Chen <[email protected]>
Date:   Wed Oct 18 08:42:52 2023 +0800

    LoongArch: Export symbol invalid_pud_table for modules building
    
    [ Upstream commit 449c2756c2323c9e32b2a2fa9c8b59ce91b5819d ]
    
    Export symbol invalid_pud_table for modules building (such as the KVM
    module) if 4-level page tables enabled. Otherwise we get:
    
    ERROR: modpost: "invalid_pud_table" [arch/loongarch/kvm/kvm.ko] undefined!
    
    Reported-by: Randy Dunlap <[email protected]>
    Acked-by: Randy Dunlap <[email protected]>
    Tested-by: Randy Dunlap <[email protected]>
    Signed-off-by: Tianrui Zhao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

LoongArch: Replace kmap_atomic() with kmap_local_page() in copy_user_highpage() [+ + +]
Author: Huacai Chen <[email protected]>
Date:   Wed Oct 18 08:42:52 2023 +0800

    LoongArch: Replace kmap_atomic() with kmap_local_page() in copy_user_highpage()
    
    [ Upstream commit 477a0ebec101359f49d92796e3b609857d564b52 ]
    
    Replace kmap_atomic()/kunmap_atomic() calls with kmap_local_page()/
    kunmap_local() in copy_user_highpage() which can be invoked from both
    preemptible and atomic context [1].
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Suggested-by: Deepak R Varma <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support [+ + +]
Author: Siddharth Vadapalli <[email protected]>
Date:   Fri Oct 20 17:32:48 2023 +0530

    misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support
    
    commit 8293703a492ae97c86af27c75b76e6239ec86483 upstream.
    
    Add DEVICE_ID for J721S2 and enable support for endpoints configured
    with this DEVICE_ID in the pci_endpoint_test driver.
    
    Signed-off-by: Siddharth Vadapalli <[email protected]>
    Cc: stable <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/mempolicy: fix set_mempolicy_home_node() previous VMA pointer [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Thu Sep 28 13:24:32 2023 -0400

    mm/mempolicy: fix set_mempolicy_home_node() previous VMA pointer
    
    commit 51f625377561e5b167da2db5aafb7ee268f691c5 upstream.
    
    The two users of mbind_range() are expecting that mbind_range() will
    update the pointer to the previous VMA, or return an error.  However,
    set_mempolicy_home_node() does not call mbind_range() if there is no VMA
    policy.  The fix is to update the pointer to the previous VMA prior to
    continuing iterating the VMAs when there is no policy.
    
    Users may experience a WARN_ON() during VMA policy updates when updating
    a range of VMAs on the home node.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/linux-mm/CALcu4rbT+fMVNaO_F2izaCT+e7jzcAciFkOvk21HGJsmLcUuwQ@mail.gmail.com/
    Fixes: f4e9e0e69468 ("mm/mempolicy: fix use-after-free of VMA iterator")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Reported-by: Yikebaer Aizezi <[email protected]>
    Closes: https://lore.kernel.org/linux-mm/CALcu4rbT+fMVNaO_F2izaCT+e7jzcAciFkOvk21HGJsmLcUuwQ@mail.gmail.com/
    Reviewed-by: Lorenzo Stoakes <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Liam R. Howlett <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmap: fix error paths with dup_anon_vma() [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Fri Sep 29 14:30:40 2023 -0400

    mmap: fix error paths with dup_anon_vma()
    
    commit 824135c46b00df7fb369ec7f1f8607427bbebeb0 upstream.
    
    When the calling function fails after the dup_anon_vma(), the
    duplication of the anon_vma is not being undone.  Add the necessary
    unlink_anon_vma() call to the error paths that are missing them.
    
    This issue showed up during inspection of the error path in vma_merge()
    for an unrelated vma iterator issue.
    
    Users may experience increased memory usage, which may be problematic as
    the failure would likely be caused by a low memory situation.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: d4af56c5c7c6 ("mm: start tracking VMAs with maple tree")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Reviewed-by: Lorenzo Stoakes <[email protected]>
    Acked-by: Vlastimil Babka <[email protected]>
    Cc: Jann Horn <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Suren Baghdasaryan <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Liam R. Howlett <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net: chelsio: cxgb4: add an error code check in t4_load_phy_fw [+ + +]
Author: Su Hui <[email protected]>
Date:   Fri Oct 20 17:27:59 2023 +0800

    net: chelsio: cxgb4: add an error code check in t4_load_phy_fw
    
    [ Upstream commit 9f771493da935299c6393ad3563b581255d01a37 ]
    
    t4_set_params_timeout() can return -EINVAL if failed, add check
    for this.
    
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: sched: cls_u32: Fix allocation size in u32_init() [+ + +]
Author: Gustavo A. R. Silva <[email protected]>
Date:   Wed Oct 4 15:19:37 2023 +0200

    net: sched: cls_u32: Fix allocation size in u32_init()
    
    [ Upstream commit c4d49196ceec80e30e8d981410d73331b49b7850 ]
    
    commit d61491a51f7e ("net/sched: cls_u32: Replace one-element array
    with flexible-array member") incorrecly replaced an instance of
    `sizeof(*tp_c)` with `struct_size(tp_c, hlist->ht, 1)`. This results
    in a an over-allocation of 8 bytes.
    
    This change is wrong because `hlist` in `struct tc_u_common` is a
    pointer:
    
    net/sched/cls_u32.c:
    struct tc_u_common {
            struct tc_u_hnode __rcu *hlist;
            void                    *ptr;
            int                     refcnt;
            struct idr              handle_idr;
            struct hlist_node       hnode;
            long                    knodes;
    };
    
    So, the use of `struct_size()` makes no sense: we don't need to allocate
    any extra space for a flexible-array member. `sizeof(*tp_c)` is just fine.
    
    So, `struct_size(tp_c, hlist->ht, 1)` translates to:
    
    sizeof(*tp_c) + sizeof(tp_c->hlist->ht) ==
    sizeof(struct tc_u_common) + sizeof(struct tc_u_knode *) ==
                                                    144 + 8  == 0x98 (byes)
                                                         ^^^
                                                          |
                                                    unnecessary extra
                                                    allocation size
    
    $ pahole -C tc_u_common net/sched/cls_u32.o
    struct tc_u_common {
            struct tc_u_hnode *        hlist;                /*     0     8 */
            void *                     ptr;                  /*     8     8 */
            int                        refcnt;               /*    16     4 */
    
            /* XXX 4 bytes hole, try to pack */
    
            struct idr                 handle_idr;           /*    24    96 */
            /* --- cacheline 1 boundary (64 bytes) was 56 bytes ago --- */
            struct hlist_node          hnode;                /*   120    16 */
            /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */
            long int                   knodes;               /*   136     8 */
    
            /* size: 144, cachelines: 3, members: 6 */
            /* sum members: 140, holes: 1, sum holes: 4 */
            /* last cacheline: 16 bytes */
    };
    
    And with `sizeof(*tp_c)`, we have:
    
            sizeof(*tp_c) == sizeof(struct tc_u_common) == 144 == 0x90 (bytes)
    
    which is the correct and original allocation size.
    
    Fix this issue by replacing `struct_size(tp_c, hlist->ht, 1)` with
    `sizeof(*tp_c)`, and avoid allocating 8 too many bytes.
    
    The following difference in binary output is expected and reflects the
    desired change:
    
    | net/sched/cls_u32.o
    | @@ -6148,7 +6148,7 @@
    | include/linux/slab.h:599
    |     2cf5:      mov    0x0(%rip),%rdi        # 2cfc <u32_init+0xfc>
    |                        2cf8: R_X86_64_PC32     kmalloc_caches+0xc
    |-    2cfc:      mov    $0x98,%edx
    |+    2cfc:      mov    $0x90,%edx
    
    Reported-by: Alejandro Colomar <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Gustavo A. R. Silva <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nf_tables: audit log object reset once per table [+ + +]
Author: Phil Sutter <[email protected]>
Date:   Wed Oct 11 17:06:59 2023 +0200

    netfilter: nf_tables: audit log object reset once per table
    
    [ Upstream commit 1baf0152f7707c6c7e4ea815dcc1f431c0e603f9 ]
    
    When resetting multiple objects at once (via dump request), emit a log
    message per table (or filled skb) and resurrect the 'entries' parameter
    to contain the number of objects being logged for.
    
    To test the skb exhaustion path, perform some bulk counter and quota
    adds in the kselftest.
    
    Signed-off-by: Phil Sutter <[email protected]>
    Reviewed-by: Richard Guy Briggs <[email protected]>
    Acked-by: Paul Moore <[email protected]> (Audit)
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nfnetlink_log: silence bogus compiler warning [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Thu Oct 5 10:53:08 2023 +0200

    netfilter: nfnetlink_log: silence bogus compiler warning
    
    [ Upstream commit 2e1d175410972285333193837a4250a74cd472e6 ]
    
    net/netfilter/nfnetlink_log.c:800:18: warning: variable 'ctinfo' is uninitialized
    
    The warning is bogus, the variable is only used if ct is non-NULL and
    always initialised in that case.  Init to 0 too to silence this.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD device [+ + +]
Author: Vicki Pfau <[email protected]>
Date:   Wed Sep 27 13:22:12 2023 -0700

    PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD device
    
    commit 7e6f3b6d2c352b5fde37ce3fed83bdf6172eebd4 upstream.
    
    The AMD VanGogh SoC contains a DesignWare USB3 Dual-Role Device that can be
    operated as either a USB Host or a USB Device, similar to on the AMD Nolan
    platform.
    
    be6646bfbaec ("PCI: Prevent xHCI driver from claiming AMD Nolan USB3 DRD
    device") added a quirk to let the dwc3 driver claim the Nolan device since
    it provides more specific support.
    
    Extend that quirk to include the VanGogh SoC USB3 device.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vicki Pfau <[email protected]>
    [bhelgaas: include be6646bfbaec reference, add stable tag]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected]      # v3.19+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf evlist: Avoid frequency mode for the dummy event [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Fri Sep 15 20:56:40 2023 -0700

    perf evlist: Avoid frequency mode for the dummy event
    
    [ Upstream commit f9cdeb58a9cf46c09b56f5f661ea8da24b6458c3 ]
    
    Dummy events are created with an attribute where the period and freq
    are zero. evsel__config will then see the uninitialized values and
    initialize them in evsel__default_freq_period. As fequency mode is
    used by default the dummy event would be set to use frequency
    mode. However, this has no effect on the dummy event but does cause
    unnecessary timers/interrupts. Avoid this overhead by setting the
    period to 1 for dummy events.
    
    evlist__add_aux_dummy calls evlist__add_dummy then sets freq=0 and
    period=1. This isn't necessary after this change and so the setting is
    removed.
    
    From Stephane:
    
    The dummy event is not counting anything. It is used to collect mmap
    records and avoid a race condition during the synthesize mmap phase of
    perf record. As such, it should not cause any overhead during active
    profiling. Yet, it did. Because of a bug the dummy event was
    programmed as a sampling event in frequency mode. Events in that mode
    incur more kernel overheads because on timer tick, the kernel has to
    look at the number of samples for each event and potentially adjust
    the sampling period to achieve the desired frequency. The dummy event
    was therefore adding a frequency event to task and ctx contexts we may
    otherwise not have any, e.g.,
    
      perf record -a -e cpu/event=0x3c,period=10000000/.
    
    On each timer tick the perf_adjust_freq_unthr_context() is invoked and
    if ctx->nr_freq is non-zero, then the kernel will loop over ALL the
    events of the context looking for frequency mode ones. In doing, so it
    locks the context, and enable/disable the PMU of each hw event. If all
    the events of the context are in period mode, the kernel will have to
    traverse the list for nothing incurring overhead. The overhead is
    multiplied by a very large factor when this happens in a guest kernel.
    There is no need for the dummy event to be in frequency mode, it does
    not count anything and therefore should not cause extra overhead for
    no reason.
    
    Fixes: 5bae0250237f ("perf evlist: Introduce perf_evlist__new_dummy constructor")
    Reported-by: Stephane Eranian <[email protected]>
    Signed-off-by: Ian Rogers <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: Yang Jihong <[email protected]>
    Cc: Kan Liang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/mellanox: mlxbf-tmfifo: Fix a warning message [+ + +]
Author: Liming Sun <[email protected]>
Date:   Thu Oct 12 19:02:35 2023 -0400

    platform/mellanox: mlxbf-tmfifo: Fix a warning message
    
    [ Upstream commit 99c09c985e5973c8f0ad976ebae069548dd86f12 ]
    
    This commit fixes the smatch static checker warning in function
    mlxbf_tmfifo_rxtx_word() which complains data not initialized at
    line 634 when IS_VRING_DROP() is TRUE.
    
    Signed-off-by: Liming Sun <[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]>

 
power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaint [+ + +]
Author: Kai-Heng Feng <[email protected]>
Date:   Wed Sep 13 11:32:33 2023 +0800

    power: supply: core: Use blocking_notifier_call_chain to avoid RCU complaint
    
    [ Upstream commit bbaa6ffa5b6c9609d3b3c431c389b407eea5441f ]
    
    AMD PMF driver can cause the following warning:
    [  196.159546] ------------[ cut here ]------------
    [  196.159556] Voluntary context switch within RCU read-side critical section!
    [  196.159571] WARNING: CPU: 0 PID: 9 at kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x43d/0x560
    [  196.159604] Modules linked in: nvme_fabrics ccm rfcomm snd_hda_scodec_cs35l41_spi cmac algif_hash algif_skcipher af_alg bnep joydev btusb btrtl uvcvideo btintel btbcm videobuf2_vmalloc intel_rapl_msr btmtk videobuf2_memops uvc videobuf2_v4l2 intel_rapl_common binfmt_misc hid_sensor_als snd_sof_amd_vangogh hid_sensor_trigger bluetooth industrialio_triggered_buffer videodev snd_sof_amd_rembrandt hid_sensor_iio_common amdgpu ecdh_generic kfifo_buf videobuf2_common hp_wmi kvm_amd sparse_keymap snd_sof_amd_renoir wmi_bmof industrialio ecc mc nls_iso8859_1 kvm snd_sof_amd_acp irqbypass snd_sof_xtensa_dsp crct10dif_pclmul crc32_pclmul mt7921e snd_sof_pci snd_ctl_led polyval_clmulni mt7921_common polyval_generic snd_sof ghash_clmulni_intel mt792x_lib mt76_connac_lib sha512_ssse3 snd_sof_utils aesni_intel snd_hda_codec_realtek crypto_simd mt76 snd_hda_codec_generic cryptd snd_soc_core snd_hda_codec_hdmi rapl ledtrig_audio input_leds snd_compress i2c_algo_bit drm_ttm_helper mac80211 snd_pci_ps hid_multitouch ttm drm_exec
    [  196.159970]  drm_suballoc_helper snd_rpl_pci_acp6x amdxcp drm_buddy snd_hda_intel snd_acp_pci snd_hda_scodec_cs35l41_i2c serio_raw gpu_sched snd_hda_scodec_cs35l41 snd_acp_legacy_common snd_intel_dspcfg snd_hda_cs_dsp_ctls snd_hda_codec libarc4 drm_display_helper snd_pci_acp6x cs_dsp snd_hwdep snd_soc_cs35l41_lib video k10temp snd_pci_acp5x thunderbolt snd_hda_core drm_kms_helper cfg80211 snd_seq snd_rn_pci_acp3x snd_pcm snd_acp_config cec snd_soc_acpi snd_seq_device rc_core ccp snd_pci_acp3x snd_timer snd soundcore wmi amd_pmf platform_profile amd_pmc mac_hid serial_multi_instantiate wireless_hotkey hid_sensor_hub sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log cdc_ether usbnet r8152 mii hid_generic nvme i2c_hid_acpi i2c_hid nvme_core i2c_piix4 xhci_pci amd_sfh drm xhci_pci_renesas nvme_common hid
    [  196.160382] CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.6.0-rc1 #4
    [  196.160397] Hardware name: HP HP EliteBook 845 14 inch G10 Notebook PC/8B6E, BIOS V82 Ver. 01.02.00 08/24/2023
    [  196.160405] Workqueue: events power_supply_changed_work
    [  196.160426] RIP: 0010:rcu_note_context_switch+0x43d/0x560
    [  196.160440] Code: 00 48 89 be 40 08 00 00 48 89 86 48 08 00 00 48 89 10 e9 63 fe ff ff 48 c7 c7 10 e7 b0 9e c6 05 e8 d8 20 02 01 e8 13 0f f3 ff <0f> 0b e9 27 fc ff ff a9 ff ff ff 7f 0f 84 cf fc ff ff 65 48 8b 3c
    [  196.160450] RSP: 0018:ffffc900001878f0 EFLAGS: 00010046
    [  196.160462] RAX: 0000000000000000 RBX: ffff88885e834040 RCX: 0000000000000000
    [  196.160470] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    [  196.160476] RBP: ffffc90000187910 R08: 0000000000000000 R09: 0000000000000000
    [  196.160482] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    [  196.160488] R13: 0000000000000000 R14: ffff888100990000 R15: ffff888100990000
    [  196.160495] FS:  0000000000000000(0000) GS:ffff88885e800000(0000) knlGS:0000000000000000
    [  196.160504] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  196.160512] CR2: 000055cb053c8246 CR3: 000000013443a000 CR4: 0000000000750ef0
    [  196.160520] PKRU: 55555554
    [  196.160526] Call Trace:
    [  196.160532]  <TASK>
    [  196.160548]  ? show_regs+0x72/0x90
    [  196.160570]  ? rcu_note_context_switch+0x43d/0x560
    [  196.160580]  ? __warn+0x8d/0x160
    [  196.160600]  ? rcu_note_context_switch+0x43d/0x560
    [  196.160613]  ? report_bug+0x1bb/0x1d0
    [  196.160637]  ? handle_bug+0x46/0x90
    [  196.160658]  ? exc_invalid_op+0x19/0x80
    [  196.160675]  ? asm_exc_invalid_op+0x1b/0x20
    [  196.160709]  ? rcu_note_context_switch+0x43d/0x560
    [  196.160727]  __schedule+0xb9/0x15f0
    [  196.160746]  ? srso_alias_return_thunk+0x5/0x7f
    [  196.160765]  ? srso_alias_return_thunk+0x5/0x7f
    [  196.160778]  ? acpi_ns_search_one_scope+0xbe/0x270
    [  196.160806]  schedule+0x68/0x110
    [  196.160820]  schedule_timeout+0x151/0x160
    [  196.160829]  ? srso_alias_return_thunk+0x5/0x7f
    [  196.160842]  ? srso_alias_return_thunk+0x5/0x7f
    [  196.160855]  ? acpi_ns_lookup+0x3c5/0xa90
    [  196.160878]  __down_common+0xff/0x220
    [  196.160905]  __down_timeout+0x16/0x30
    [  196.160920]  down_timeout+0x64/0x70
    [  196.160938]  acpi_os_wait_semaphore+0x85/0x200
    [  196.160959]  acpi_ut_acquire_mutex+0x9e/0x280
    [  196.160979]  acpi_ex_enter_interpreter+0x2d/0xb0
    [  196.160992]  acpi_ns_evaluate+0x2f0/0x5f0
    [  196.161005]  acpi_evaluate_object+0x172/0x490
    [  196.161018]  ? acpi_os_signal_semaphore+0x8a/0xd0
    [  196.161038]  acpi_evaluate_integer+0x52/0xe0
    [  196.161055]  ? kfree+0x79/0x120
    [  196.161071]  ? srso_alias_return_thunk+0x5/0x7f
    [  196.161089]  acpi_ac_get_state.part.0+0x27/0x80
    [  196.161110]  get_ac_property+0x5c/0x70
    [  196.161127]  ? __pfx___power_supply_is_system_supplied+0x10/0x10
    [  196.161146]  __power_supply_is_system_supplied+0x44/0xb0
    [  196.161166]  class_for_each_device+0x124/0x160
    [  196.161184]  ? acpi_ac_get_state.part.0+0x27/0x80
    [  196.161203]  ? srso_alias_return_thunk+0x5/0x7f
    [  196.161223]  power_supply_is_system_supplied+0x3c/0x70
    [  196.161243]  amd_pmf_get_power_source+0xe/0x20 [amd_pmf]
    [  196.161276]  amd_pmf_power_slider_update_event+0x49/0x90 [amd_pmf]
    [  196.161310]  amd_pmf_pwr_src_notify_call+0xe7/0x100 [amd_pmf]
    [  196.161340]  notifier_call_chain+0x5f/0xe0
    [  196.161362]  atomic_notifier_call_chain+0x33/0x60
    [  196.161378]  power_supply_changed_work+0x84/0x110
    [  196.161394]  process_one_work+0x178/0x360
    [  196.161412]  ? __pfx_worker_thread+0x10/0x10
    [  196.161424]  worker_thread+0x307/0x430
    [  196.161440]  ? __pfx_worker_thread+0x10/0x10
    [  196.161451]  kthread+0xf4/0x130
    [  196.161467]  ? __pfx_kthread+0x10/0x10
    [  196.161486]  ret_from_fork+0x43/0x70
    [  196.161502]  ? __pfx_kthread+0x10/0x10
    [  196.161518]  ret_from_fork_asm+0x1b/0x30
    [  196.161558]  </TASK>
    [  196.161562] ---[ end trace 0000000000000000 ]---
    
    Since there's no guarantee that all the callbacks can work in atomic
    context, switch to use blocking_notifier_call_chain to relax the
    constraint.
    
    Signed-off-by: Kai-Heng Feng <[email protected]>
    Reported-by: Allen Zhong <[email protected]>
    Fixes: 4c71ae414474 ("platform/x86/amd/pmf: Add support SPS PMF feature")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217571
    Reviewed-by: Mario Limonciello <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/85xx: Fix math emulation exception [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Mon Sep 25 17:55:51 2023 +0200

    powerpc/85xx: Fix math emulation exception
    
    [ Upstream commit 8e8a12ecbc86700b5e1a3596ce2b3c43dafad336 ]
    
    Booting mpc85xx_defconfig kernel on QEMU leads to:
    
    Bad trap at PC: fe9bab0, SR: 2d000, vector=800
    awk[82]: unhandled trap (5) at 0 nip fe9bab0 lr fe9e01c code 5 in libc-2.27.so[fe5a000+17a000]
    awk[82]: code: 3aa00000 3a800010 4bffe03c 9421fff0 7ca62b78 38a00000 93c10008 83c10008
    awk[82]: code: 38210010 4bffdec8 9421ffc0 7c0802a6 <fc00048e> d8010008 4815190d 93810030
    Trace/breakpoint trap
    WARNING: no useful console
    
    This is because allthough CONFIG_MATH_EMULATION is selected,
    Exception 800 calls unknown_exception().
    
    Call emulation_assist_interrupt() instead.
    
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/066caa6d9480365da9b8ed83692d7101e10ac5f8.1695657339.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/mm: Fix boot crash with FLATMEM [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Mon Oct 23 22:25:00 2023 +1100

    powerpc/mm: Fix boot crash with FLATMEM
    
    [ Upstream commit daa9ada2093ed23d52b4c1fe6e13cf78f55cc85f ]
    
    Erhard reported that his G5 was crashing with v6.6-rc kernels:
    
      mpic: Setting up HT PICs workarounds for U3/U4
      BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe
      Faulting instruction address: 0xc00000000005dc40
      Oops: Kernel access of bad area, sig: 11 [#1]
      BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G                T  6.6.0-rc3-PMacGS #1
      Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac
      NIP:  c00000000005dc40 LR: c000000000066660 CTR: c000000000007730
      REGS: c0000000022bf510 TRAP: 0380   Tainted: G                T (6.6.0-rc3-PMacGS)
      MSR:  9000000000001032 <SF,HV,ME,IR,DR,RI>  CR: 44004242  XER: 00000000
      IRQMASK: 3
      GPR00: 0000000000000000 c0000000022bf7b0 c0000000010c0b00 00000000000001ac
      GPR04: 0000000003c80000 0000000000000300 c0000000f20001ae 0000000000000300
      GPR08: 0000000000000006 feffbb62ffec65ff 0000000000000001 0000000000000000
      GPR12: 9000000000001032 c000000002362000 c000000000f76b80 000000000349ecd8
      GPR16: 0000000002367ba8 0000000002367f08 0000000000000006 0000000000000000
      GPR20: 00000000000001ac c000000000f6f920 c0000000022cd985 000000000000000c
      GPR24: 0000000000000300 00000003b0a3691d c0003e008030000e 0000000000000000
      GPR28: c00000000000000c c0000000f20001ee feffbb62ffec65fe 00000000000001ac
      NIP hash_page_do_lazy_icache+0x50/0x100
      LR  __hash_page_4K+0x420/0x590
      Call Trace:
        hash_page_mm+0x364/0x6f0
        do_hash_fault+0x114/0x2b0
        data_access_common_virt+0x198/0x1f0
      --- interrupt: 300 at mpic_init+0x4bc/0x10c4
      NIP:  c000000002020a5c LR: c000000002020a04 CTR: 0000000000000000
      REGS: c0000000022bf9f0 TRAP: 0300   Tainted: G                T (6.6.0-rc3-PMacGS)
      MSR:  9000000000001032 <SF,HV,ME,IR,DR,RI>  CR: 24004248  XER: 00000000
      DAR: c0003e008030000e DSISR: 40000000 IRQMASK: 1
      ...
      NIP mpic_init+0x4bc/0x10c4
      LR  mpic_init+0x464/0x10c4
      --- interrupt: 300
        pmac_setup_one_mpic+0x258/0x2dc
        pmac_pic_init+0x28c/0x3d8
        init_IRQ+0x90/0x140
        start_kernel+0x57c/0x78c
        start_here_common+0x1c/0x20
    
    A bisect pointed to the breakage beginning with commit 9fee28baa601 ("powerpc:
    implement the new page table range API").
    
    Analysis of the oops pointed to a struct page with a corrupted
    compound_head being loaded via page_folio() -> _compound_head() in
    hash_page_do_lazy_icache().
    
    The access by the mpic code is to an MMIO address, so the expectation
    is that the struct page for that address would be initialised by
    init_unavailable_range(), as pointed out by Aneesh.
    
    Instrumentation showed that was not the case, which eventually lead to
    the realisation that pfn_valid() was returning false for that address,
    causing the struct page to not be initialised.
    
    Because the system is using FLATMEM, the version of pfn_valid() in
    memory_model.h is used:
    
    static inline int pfn_valid(unsigned long pfn)
    {
            ...
            return pfn >= pfn_offset && (pfn - pfn_offset) < max_mapnr;
    }
    
    Which relies on max_mapnr being initialised. Early in boot max_mapnr is
    zero meaning no PFNs are valid.
    
    max_mapnr is initialised in mem_init() called via:
    
      start_kernel()
        mm_core_init()  # init/main.c:928
          mem_init()
    
    But that is too late for the usage in init_unavailable_range() called via:
    
      start_kernel()
        setup_arch()    # init/main.c:893
          paging_init()
            free_area_init()
              init_unavailable_range()
    
    Although max_mapnr is currently set in mem_init(), the value is actually
    already available much earlier, as soon as mem_topology_setup() has
    completed, which is also before paging_init() is called. So move the
    initialisation there, which causes paging_init() to correctly initialise
    the struct page and fixes the bug.
    
    This bug seems to have been lurking for years, but went unnoticed
    because the pre-folio code was inspecting the uninitialised page->flags
    but not dereferencing it.
    
    Thanks to Erhard and Aneesh for help debugging.
    
    Reported-by: Erhard Furtner <[email protected]>
    Closes: https://lore.kernel.org/all/20230929132750.3cd98452@yea/
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:57 2023 -0700

    r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en()
    
    [ Upstream commit bc65cc42af737a5a35f83842408ef2c6c79ba025 ]
    
    If the adapter is unplugged while we're looping in r8153b_ups_en() /
    r8153c_ups_en() we could end up looping for 10 seconds (20 ms * 500
    loops). Add code similar to what's done in other places in the driver
    to check for unplug and bail.
    
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Grant Grundler <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8152: Check for unplug in rtl_phy_patch_request() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:56 2023 -0700

    r8152: Check for unplug in rtl_phy_patch_request()
    
    [ Upstream commit dc90ba37a8c37042407fa6970b9830890cfe6047 ]
    
    If the adapter is unplugged while we're looping in
    rtl_phy_patch_request() we could end up looping for 10 seconds (2 ms *
    5000 loops). Add code similar to what's done in other places in the
    driver to check for unplug and bail.
    
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Grant Grundler <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: mpt3sas: Fix in error path [+ + +]
Author: Tomas Henzl <[email protected]>
Date:   Sun Oct 15 13:45:29 2023 +0200

    scsi: mpt3sas: Fix in error path
    
    [ Upstream commit e40c04ade0e2f3916b78211d747317843b11ce10 ]
    
    The driver should be deregistered as misc driver after PCI registration
    failure.
    
    Signed-off-by: Tomas Henzl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: npcm-fiu: Fix UMA reads when dummy.nbytes == 0 [+ + +]
Author: William A. Kennington III <[email protected]>
Date:   Fri Sep 22 11:28:12 2023 -0700

    spi: npcm-fiu: Fix UMA reads when dummy.nbytes == 0
    
    [ Upstream commit 2ec8b010979036c2fe79a64adb6ecc0bd11e91d1 ]
    
    We don't want to use the value of ilog2(0) as dummy.buswidth is 0 when
    dummy.nbytes is 0. Since we have no dummy bytes, we don't need to
    configure the dummy byte bits per clock register value anyway.
    
    Signed-off-by: "William A. Kennington III" <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: 8250: Add Brainboxes Oxford Semiconductor-based quirks [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:17 2023 +0100

    tty: 8250: Add Brainboxes Oxford Semiconductor-based quirks
    
    commit e4876dacaca46a1b09f9b417480924ab12019a5b upstream.
    
    Some of the later revisions of the Brainboxes PX cards are based
    on the Oxford Semiconductor chipset. Due to the chip's unique setup
    these cards need to be initialised.
    Previously these were tested against a reference card with the same broken
    baudrate on another PC, cancelling out the effect. With this patch they
    work and can transfer/receive find against an FTDI-based device.
    
    Add all of the cards which require this setup to the quirks table.
    Thanks to Maciej W. Rozycki for clarification on this chip.
    
    Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899D222A4AB2A4E8C57108FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for additional Brainboxes PX cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:15 2023 +0100

    tty: 8250: Add support for additional Brainboxes PX cards
    
    commit 9604884e592cd04ead024c9737c67a77f175cab9 upstream.
    
    Add support for some more of the Brainboxes PX (PCIe) range
    of serial cards, namely
    PX-275/PX-279, PX-475 (serial port, not LPT), PX-820,
    PX-803/PX-857 (additional ID).
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB78996BEC353FB346FC35444BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for additional Brainboxes UC cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:09 2023 +0100

    tty: 8250: Add support for additional Brainboxes UC cards
    
    commit c563db486db7d245c0e2f319443417ae8e692f7f upstream.
    
    Add device IDs for some more Brainboxes UC cards, namely
    UC-235/UC-246, UC-253/UC-734, UC-302, UC-313, UC-346, UC-357,
    UC-607 and UC-836.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB789969998A6C3FAFCD95C85DC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for Brainboxes UP cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:10 2023 +0100

    tty: 8250: Add support for Brainboxes UP cards
    
    commit 2c6fec1e1532f15350be7e14ba6b88a39d289fe4 upstream.
    
    Add support for the Brainboxes UP (powered PCI) range of
    cards, namely UP-189, UP-200, UP-869 and UP-880.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899B5B59FF3D8587E88C117C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for Intashield IS-100 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:11 2023 +0100

    tty: 8250: Add support for Intashield IS-100
    
    commit 4d994e3cf1b541ff32dfb03fbbc60eea68f9645b upstream.
    
    Add support for the Intashield IS-100 1 port serial card.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899A0E0CDAA505AF5A874CDC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for Intashield IX cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:16 2023 +0100

    tty: 8250: Add support for Intashield IX cards
    
    commit 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 upstream.
    
    Add support for the IX-100, IX-200 and IX-400 serial cards.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899614E5837E82A03272A4BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Fix port count of PX-257 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:12 2023 +0100

    tty: 8250: Fix port count of PX-257
    
    commit d0ff5b24c2f112f29dea4c38b3bac9597b1be9ba upstream.
    
    The port count of the PX-257 Rev3 is actually 2, not 4.
    
    Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899C804D9F04E727B5A0E8FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Fix up PX-803/PX-857 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:13 2023 +0100

    tty: 8250: Fix up PX-803/PX-857
    
    commit ee61337b934c99c2611e0a945d592019b2e00c82 upstream.
    
    The PX-803/PX-857 are variants of each other, add a note.
    Additionally fix up the port counts for the card (2, not 1).
    
    Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB789978C8ED872FB4B014E132C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Remove UC-257 and UC-431 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:08 2023 +0100

    tty: 8250: Remove UC-257 and UC-431
    
    commit 33092fb3af51deb80849e90a17bada44bbcde6b3 upstream.
    
    The UC-257 is a serial + LPT card, so remove it from this driver.
    A patch has been submitted to add it to parport_serial instead.
    
    Additionaly, the UC-431 does not use this card ID, only the UC-420
    does. The 431 is a 3-port card and there is no generic 3-port configuration
    available, so remove reference to it from this driver.
    
    Fixes: 152d1afa834c ("tty: Add support for Brainboxes UC cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB78995ADF7394C74AD4CF3357C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: n_gsm: fix race condition in status line change on dead connections [+ + +]
Author: Daniel Starke <[email protected]>
Date:   Thu Oct 26 07:58:43 2023 +0200

    tty: n_gsm: fix race condition in status line change on dead connections
    
    commit 3a75b205de43365f80a33b98ec9289785da56243 upstream.
    
    gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all
    timers, removing the virtual tty devices and clearing the data queues.
    This procedure, however, may cause subsequent changes of the virtual modem
    status lines of a DLCI. More data is being added the outgoing data queue
    and the deleted kick timer is restarted to handle this. At this point many
    resources have already been removed by the cleanup procedure. Thus, a
    kernel panic occurs.
    
    Fix this by proving in gsm_modem_update() that the cleanup procedure has
    not been started and the mux is still alive.
    
    Note that writing to a virtual tty is already protected by checks against
    the DLCI specific connection state.
    
    Fixes: c568f7086c6e ("tty: n_gsm: fix missing timer to handle stalled links")
    Cc: stable <[email protected]>
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: raw-gadget: properly handle interrupted requests [+ + +]
Author: Andrey Konovalov <[email protected]>
Date:   Thu Oct 26 22:01:12 2023 +0200

    usb: raw-gadget: properly handle interrupted requests
    
    commit e8033bde451eddfb9b1bbd6e2d848c1b5c277222 upstream.
    
    Currently, if a USB request that was queued by Raw Gadget is interrupted
    (via a signal), wait_for_completion_interruptible returns -ERESTARTSYS.
    Raw Gadget then attempts to propagate this value to userspace as a return
    value from its ioctls. However, when -ERESTARTSYS is returned by a syscall
    handler, the kernel internally restarts the syscall.
    
    This doesn't allow userspace applications to interrupt requests queued by
    Raw Gadget (which is required when the emulated device is asked to switch
    altsettings). It also violates the implied interface of Raw Gadget that a
    single ioctl must only queue a single USB request.
    
    Instead, make Raw Gadget do what GadgetFS does: check whether the request
    was interrupted (dequeued with status == -ECONNRESET) and report -EINTR to
    userspace.
    
    Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
    Cc: stable <[email protected]>
    Signed-off-by: Andrey Konovalov <[email protected]>
    Link: https://lore.kernel.org/r/0db45b1d7cc466e3d4d1ab353f61d63c977fbbc5.1698350424.git.andreyknvl@gmail.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility [+ + +]
Author: LihaSika <[email protected]>
Date:   Fri Oct 27 20:28:04 2023 +0300

    usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility
    
    commit 0e3139e6543b241b3e65956a55c712333bef48ac upstream.
    
    Change lower bcdDevice value for "Super Top USB 2.0  SATA BRIDGE" to match
    1.50. I have such an older device with bcdDevice=1.50 and it will not work
    otherwise.
    
    Cc: [email protected]
    Signed-off-by: Liha Sikanen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm() [+ + +]
Author: Jimmy Hu <[email protected]>
Date:   Fri Oct 20 01:21:32 2023 +0000

    usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()
    
    commit 4987daf86c152ff882d51572d154ad12e4ff3a4b upstream.
    
    It is possible that typec_register_partner() returns ERR_PTR on failure.
    When port->partner is an error, a NULL pointer dereference may occur as
    shown below.
    
    [91222.095236][  T319] typec port0: failed to register partner (-17)
    ...
    [91225.061491][  T319] Unable to handle kernel NULL pointer dereference
    at virtual address 000000000000039f
    [91225.274642][  T319] pc : tcpm_pd_data_request+0x310/0x13fc
    [91225.274646][  T319] lr : tcpm_pd_data_request+0x298/0x13fc
    [91225.308067][  T319] Call trace:
    [91225.308070][  T319]  tcpm_pd_data_request+0x310/0x13fc
    [91225.308073][  T319]  tcpm_pd_rx_handler+0x100/0x9e8
    [91225.355900][  T319]  kthread_worker_fn+0x178/0x58c
    [91225.355902][  T319]  kthread+0x150/0x200
    [91225.355905][  T319]  ret_from_fork+0x10/0x30
    
    Add a check for port->partner to avoid dereferencing a NULL pointer.
    
    Fixes: 5e1d4c49fbc8 ("usb: typec: tcpm: Determine common SVDM Version")
    Cc: [email protected]
    Signed-off-by: Jimmy Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86: KVM: SVM: always update the x2avic msr interception [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Thu Sep 28 20:33:51 2023 +0300

    x86: KVM: SVM: always update the x2avic msr interception
    
    commit b65235f6e102354ccafda601eaa1c5bef5284d21 upstream.
    
    The following problem exists since x2avic was enabled in the KVM:
    
    svm_set_x2apic_msr_interception is called to enable the interception of
    the x2apic msrs.
    
    In particular it is called at the moment the guest resets its apic.
    
    Assuming that the guest's apic was in x2apic mode, the reset will bring
    it back to the xapic mode.
    
    The svm_set_x2apic_msr_interception however has an erroneous check for
    '!apic_x2apic_mode()' which prevents it from doing anything in this case.
    
    As a result of this, all x2apic msrs are left unintercepted, and that
    exposes the bare metal x2apic (if enabled) to the guest.
    Oops.
    
    Remove the erroneous '!apic_x2apic_mode()' check to fix that.
    
    This fixes CVE-2023-5090
    
    Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode")
    Cc: [email protected]
    Signed-off-by: Maxim Levitsky <[email protected]>
    Reviewed-by: Suravee Suthikulpanit <[email protected]>
    Tested-by: Suravee Suthikulpanit <[email protected]>
    Reviewed-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: SeongJae Park <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>