Linux 5.15.25

 
ACPI: PM: Revert "Only mark EC GPE for wakeup on Intel systems" [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Jan 28 14:35:03 2022 -0600

    ACPI: PM: Revert "Only mark EC GPE for wakeup on Intel systems"
    
    [ Upstream commit d6ebb17ccc7b37872a32bc25b4a21f1e5af8c7e3 ]
    
    Testing on various upcoming OEM systems shows commit 7b167c4cb48e ("ACPI:
    PM: Only mark EC GPE for wakeup on Intel systems") was short
    sighted and the symptoms were indicative of other problems. Some OEMs
    do have the dedicated GPIOs for the power button but also rely upon
    an interrupt to the EC SCI to let the lid work.
    
    The original commit showed spurious activity on Lenovo systems:
         * On both Lenovo T14 and P14s the keyboard wakeup doesn't work, and
           sometimes the power button event doesn't work.
    
    This was confirmed on my end at that time.
    
    However further development in the kernel showed that the issue was
    actually the IRQ for the GPIO controller was also shared with the EC SCI.
    This was actually fixed by commit 2d54067fcd23 ("pinctrl: amd: Fix
    wakeups when IRQ is shared with SCI").
    
    The original commit also showed problems with AC adapter:
         * On HP 635 G7 detaching or attaching AC during suspend will cause
           the system not to wakeup
         * On Asus vivobook to prevent detaching AC causing resume problems
         * On Lenovo 14ARE05 to prevent detaching AC causing resume problems
         * On HP ENVY x360  to prevent detaching AC causing resume problems
    
    Detaching AC adapter causing problems appears to have been a problem
    because the EC SCI went off to notify the OS of the power adapter change
    but the SCI was ignored and there was no other way to wake up this system
    since GPIO controller wasn't properly enabled.  The wakeups were fixed by
    enabling the GPIO controller in commit acd47b9f28e5 ("pinctrl: amd: Handle
    wake-up interrupt").
    
    I've confirmed on a variety of OEM notebooks with the following test
    
     1) echo 1 | sudo tee /sys/power/pm_debug_messages
     2) sudo systemctl suspend
     3) unplug AC adapter, make sure system is still asleep
     4) wake system from lid (which is provided by ACPI SCI on some of them)
     5) dmesg
        a) see the EC GPE dispatched, timekeeping for X seconds (matching ~time
           until AC adapter plug out)
        b) see timekeeping for Y seconds until woke (matching ~time from AC
           adapter until lid event)
     6) Look at /sys/kernel/debug/amd_pmc/s0ix_stats
        "Time (in us) in S0i3" = X + Y - firmware processing time
    
    Signed-off-by: Mario Limonciello <[email protected]>
    Tested-by: Kai-Heng Feng <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: hda/realtek: Add quirk for Legion Y9000X 2019 [+ + +]
Author: Yu Huang <[email protected]>
Date:   Sun Feb 13 00:08:33 2022 +0800

    ALSA: hda/realtek: Add quirk for Legion Y9000X 2019
    
    commit c07f2c7b45413a9e50ba78630fda04ecfa17b4f2 upstream.
    
    Legion Y9000X 2019 has the same speaker with Y9000X 2020,
    but with a different quirk address. Add one quirk entry
    to make the speaker work on Y9000X 2019 too.
    
    Signed-off-by: Yu Huang <[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: Fix deadlock by COEF mutex [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Mon Feb 14 14:04:10 2022 +0100

    ALSA: hda/realtek: Fix deadlock by COEF mutex
    
    commit 2a845837e3d0ddaed493b4c5c4643d7f0542804d upstream.
    
    The recently introduced coef_mutex for Realtek codec seems causing a
    deadlock when the relevant code is invoked from the power-off state;
    then the HD-audio core tries to power-up internally, and this kicks
    off the codec runtime PM code that tries to take the same coef_mutex.
    
    In order to avoid the deadlock, do the temporary power up/down around
    the coef_mutex acquisition and release.  This assures that the
    power-up sequence runs before the mutex, hence no re-entrance will
    happen.
    
    Fixes: b837a9f5ab3b ("ALSA: hda: realtek: Fix race at concurrent COEF updates")
    Reported-and-tested-by: Julian Wollrath <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/20220214132838.4db10fca@schienar
    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 missing codec probe on Shenker Dock 15 [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Mon Feb 14 11:00:20 2022 +0100

    ALSA: hda: Fix missing codec probe on Shenker Dock 15
    
    commit dd8e5b161d7fb9cefa1f1d6e35a39b9e1563c8d3 upstream.
    
    By some unknown reason, BIOS on Shenker Dock 15 doesn't set up the
    codec mask properly for the onboard audio.  Let's set the forced codec
    mask to enable the codec discovery.
    
    Reported-by: [email protected]
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22
    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 regression on forced probe mask option [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Mon Feb 14 11:00:19 2022 +0100

    ALSA: hda: Fix regression on forced probe mask option
    
    commit 6317f7449348a897483a2b4841f7a9190745c81b upstream.
    
    The forced probe mask via probe_mask 0x100 bit doesn't work any longer
    as expected since the bus init code was moved and it's clearing the
    codec_mask value that was set beforehand.  This patch fixes the
    long-time regression by moving the check_probe_mask() call.
    
    Fixes: a41d122449be ("ALSA: hda - Embed bus into controller object")
    Reported-by: [email protected]
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22
    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: revert to IMPLICIT_FB_FIXED_DEV for M-Audio FastTrack Ultra [+ + +]
Author: Matteo Martelli <[email protected]>
Date:   Fri Feb 11 23:49:13 2022 +0100

    ALSA: usb-audio: revert to IMPLICIT_FB_FIXED_DEV for M-Audio FastTrack Ultra
    
    commit 19d20c7a29bf2e46ff1ab8e8c4fcd2da8a4f38e2 upstream.
    
    Commit 83b7dcbc51c930fc2079ab6c6fc9d719768321f1 introduced a generic
    implicit feedback parser, which fails to execute for M-Audio FastTrack
    Ultra sound cards. The issue is with the ENDPOINT_SYNCTYPE check in
    add_generic_implicit_fb() where the SYNCTYPE is ADAPTIVE instead of ASYNC.
    The reason is that the sync type of the FastTrack output endpoints are
    set to adaptive in the quirks table since commit
    65f04443c96dbda11b8fff21d6390e082846aa3c.
    
    Fixes: 83b7dcbc51c9 ("ALSA: usb-audio: Add generic implicit fb parsing")
    Signed-off-by: Matteo Martelli <[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]>

 
arm64: Correct wrong label in macro __init_el2_gicv3 [+ + +]
Author: Joakim Tjernlund <[email protected]>
Date:   Mon Feb 14 18:56:43 2022 +0100

    arm64: Correct wrong label in macro __init_el2_gicv3
    
    commit 4f6de676d94ee8ddfc2e7e7cd935fc7cb2feff3a upstream.
    
    In commit:
    
      114945d84a30a5fe ("arm64: Fix labels in el2_setup macros")
    
    We renamed a label from '1' to '.Lskip_gicv3_\@', but failed to update
    a branch to it, which now targets a later label also called '1'.
    
    The branch is taken rarely, when GICv3 is present but SRE is disabled
    at EL3, causing a boot-time crash.
    
    Update the caller to the new label name.
    
    Fixes: 114945d84a30 ("arm64: Fix labels in el2_setup macros")
    Cc: <[email protected]> # 5.12.x
    Signed-off-by: Joakim Tjernlund <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Mark Rutland <[email protected]>
    Reviewed-by: Marc Zyngier <[email protected]>
    Signed-off-by: Catalin Marinas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: meson-g12: add ATF BL32 reserved-memory region [+ + +]
Author: Christian Hewitt <[email protected]>
Date:   Wed Jan 26 04:49:53 2022 +0000

    arm64: dts: meson-g12: add ATF BL32 reserved-memory region
    
    [ Upstream commit 08982a1b3aa2611c9c711d24825c9002d28536f4 ]
    
    Add an additional reserved memory region for the BL32 trusted firmware
    present in many devices that boot from Amlogic vendor u-boot.
    
    Signed-off-by: Christian Hewitt <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: meson-g12: drop BL32 region from SEI510/SEI610 [+ + +]
Author: Christian Hewitt <[email protected]>
Date:   Wed Jan 26 04:49:54 2022 +0000

    arm64: dts: meson-g12: drop BL32 region from SEI510/SEI610
    
    [ Upstream commit f26573e2bc9dfd551a0d5c6971f18cc546543312 ]
    
    The BL32/TEE reserved-memory region is now inherited from the common
    family dtsi (meson-g12-common) so we can drop it from board files.
    
    Signed-off-by: Christian Hewitt <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: meson-gx: add ATF BL32 reserved-memory region [+ + +]
Author: Christian Hewitt <[email protected]>
Date:   Wed Jan 26 04:49:52 2022 +0000

    arm64: dts: meson-gx: add ATF BL32 reserved-memory region
    
    [ Upstream commit 76577c9137456febb05b0e17d244113196a98968 ]
    
    Add an additional reserved memory region for the BL32 trusted firmware
    present in many devices that boot from Amlogic vendor u-boot.
    
    Suggested-by: Mateusz Krzak <[email protected]>
    Signed-off-by: Christian Hewitt <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: OMAP2+: adjust the location of put_device() call in omapdss_init_of [+ + +]
Author: Ye Guojin <[email protected]>
Date:   Tue Nov 16 06:27:26 2021 +0000

    ARM: OMAP2+: adjust the location of put_device() call in omapdss_init_of
    
    [ Upstream commit 34596ba380b03d181e24efd50e2f21045bde3696 ]
    
    This was found by coccicheck:
    ./arch/arm/mach-omap2/display.c, 272, 1-7, ERROR missing put_device;
    call of_find_device_by_node on line 258, but without a corresponding
    object release within this function.
    
    Move the put_device() call before the if judgment.
    
    Reported-by: Zeal Robot <[email protected]>
    Signed-off-by: Ye Guojin <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: OMAP2+: hwmod: Add of_node_put() before break [+ + +]
Author: Wan Jiabing <[email protected]>
Date:   Thu Oct 14 04:57:19 2021 -0400

    ARM: OMAP2+: hwmod: Add of_node_put() before break
    
    [ Upstream commit 80c469a0a03763f814715f3d12b6f3964c7423e8 ]
    
    Fix following coccicheck warning:
    ./arch/arm/mach-omap2/omap_hwmod.c:753:1-23: WARNING: Function
    for_each_matching_node should have of_node_put() before break
    
    Early exits from for_each_matching_node should decrement the
    node reference counter.
    
    Signed-off-by: Wan Jiabing <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw() [+ + +]
Author: Mark Brown <[email protected]>
Date:   Tue Feb 1 15:56:26 2022 +0000

    ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw()
    
    commit 564778d7b1ea465f9487eedeece7527a033549c5 upstream.
    
    When writing out a stereo control we discard the change notification from
    the first channel, meaning that events are only generated based on changes
    to the second channel. Ensure that we report a change if either channel
    has changed.
    
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [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]>

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_range() [+ + +]
Author: Mark Brown <[email protected]>
Date:   Tue Feb 1 15:56:28 2022 +0000

    ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_range()
    
    commit 650204ded3703b5817bd4b6a77fa47d333c4f902 upstream.
    
    When writing out a stereo control we discard the change notification from
    the first channel, meaning that events are only generated based on changes
    to the second channel. Ensure that we report a change if either channel
    has changed.
    
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [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]>

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx() [+ + +]
Author: Mark Brown <[email protected]>
Date:   Tue Feb 1 15:56:27 2022 +0000

    ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()
    
    commit 7f3d90a3519680dfa23e750f80bfdefc0f5eda4a upstream.
    
    When writing out a stereo control we discard the change notification from
    the first channel, meaning that events are only generated based on changes
    to the second channel. Ensure that we report a change if either channel
    has changed.
    
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [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]>

ASoC: ops: Fix stereo change notifications in snd_soc_put_xr_sx() [+ + +]
Author: Mark Brown <[email protected]>
Date:   Tue Feb 1 15:56:29 2022 +0000

    ASoC: ops: Fix stereo change notifications in snd_soc_put_xr_sx()
    
    commit 2b7c46369f09c358164d31d17e5695185403185e upstream.
    
    When writing out a stereo control we discard the change notification from
    the first channel, meaning that events are only generated based on changes
    to the second channel. Ensure that we report a change if either channel
    has changed.
    
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [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]>

ASoC: qcom: Actually clear DMA interrupt register for HDMI [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Wed Feb 9 15:25:20 2022 -0800

    ASoC: qcom: Actually clear DMA interrupt register for HDMI
    
    commit c8d251f51ee61df06ee0e419348d8c9160bbfb86 upstream.
    
    In commit da0363f7bfd3 ("ASoC: qcom: Fix for DMA interrupt clear reg
    overwriting") we changed regmap_write() to regmap_update_bits() so that
    we can avoid overwriting bits that we didn't intend to modify.
    Unfortunately this change breaks the case where a register is writable
    but not readable, which is exactly how the HDMI irq clear register is
    designed (grep around LPASS_HDMITX_APP_IRQCLEAR_REG to see how it's
    write only). That's because regmap_update_bits() tries to read the
    register from the hardware and if it isn't readable it looks in the
    regmap cache to see what was written there last time to compare against
    what we want to write there. Eventually, we're unable to modify this
    register at all because the bits that we're trying to set are already
    set in the cache.
    
    This is doubly bad for the irq clear register because you have to write
    the bit to clear an interrupt. Given the irq is level triggered, we see
    an interrupt storm upon plugging in an HDMI cable and starting audio
    playback. The irq storm is so great that performance degrades
    significantly, leading to CPU soft lockups.
    
    Fix it by using regmap_write_bits() so that we really do write the bits
    in the clear register that we want to. This brings the number of irqs
    handled by lpass_dma_interrupt_handler() down from ~150k/sec to ~10/sec.
    
    Fixes: da0363f7bfd3 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting")
    Cc: Srinivasa Rao Mandadapu <[email protected]>
    Cc: Srinivas Kandagatla <[email protected]>
    Signed-off-by: Stephen Boyd <[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]>

ASoC: tas2770: Insert post reset delay [+ + +]
Author: Martin Povišer <[email protected]>
Date:   Fri Feb 4 10:53:01 2022 +0100

    ASoC: tas2770: Insert post reset delay
    
    commit 307f31452078792aab94a729fce33200c6e42dc4 upstream.
    
    Per TAS2770 datasheet there must be a 1 ms delay from reset to first
    command. So insert delays into the driver where appropriate.
    
    Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
    Signed-off-by: Martin Povišer <[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]>

 
ata: libata-core: Disable TRIM on M88V29 [+ + +]
Author: Zoltán Böszörményi <[email protected]>
Date:   Fri Feb 4 13:57:50 2022 +0100

    ata: libata-core: Disable TRIM on M88V29
    
    [ Upstream commit c8ea23d5fa59f28302d4e3370c75d9c308e64410 ]
    
    This device is a CF card, or possibly an SSD in CF form factor.
    It supports NCQ and high speed DMA.
    
    While it also advertises TRIM support, I/O errors are reported
    when the discard mount option fstrim is used. TRIM also fails
    when disabling NCQ and not just as an NCQ command.
    
    TRIM must be disabled for this device.
    
    Signed-off-by: Zoltán Böszörményi <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
atl1c: fix tx timeout after link flap on Mikrotik 10/25G NIC [+ + +]
Author: Gatis Peisenieks <[email protected]>
Date:   Fri Feb 11 08:51:23 2022 +0200

    atl1c: fix tx timeout after link flap on Mikrotik 10/25G NIC
    
    commit bf8e59fd315f304eb538546e35de6dc603e4709f upstream.
    
    If NIC had packets in tx queue at the moment link down event
    happened, it could result in tx timeout when link got back up.
    
    Since device has more than one tx queue we need to reset them
    accordingly.
    
    Fixes: 057f4af2b171 ("atl1c: add 4 RX/TX queue support for Mikrotik 10/25G NIC")
    Signed-off-by: Gatis Peisenieks <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ax25: improve the incomplete fix to avoid UAF and NPD bugs [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Fri Jan 28 12:47:15 2022 +0800

    ax25: improve the incomplete fix to avoid UAF and NPD bugs
    
    [ Upstream commit 4e0f718daf97d47cf7dec122da1be970f145c809 ]
    
    The previous commit 1ade48d0c27d ("ax25: NPD bug when detaching
    AX25 device") introduce lock_sock() into ax25_kill_by_device to
    prevent NPD bug. But the concurrency NPD or UAF bug will occur,
    when lock_sock() or release_sock() dereferences the ax25_cb->sock.
    
    The NULL pointer dereference bug can be shown as below:
    
    ax25_kill_by_device()        | ax25_release()
                                 |   ax25_destroy_socket()
                                 |     ax25_cb_del()
      ...                        |     ...
                                 |     ax25->sk=NULL;
      lock_sock(s->sk); //(1)    |
      s->ax25_dev = NULL;        |     ...
      release_sock(s->sk); //(2) |
      ...                        |
    
    The root cause is that the sock is set to null before dereference
    site (1) or (2). Therefore, this patch extracts the ax25_cb->sock
    in advance, and uses ax25_list_lock to protect it, which can synchronize
    with ax25_cb_del() and ensure the value of sock is not null before
    dereference sites.
    
    The concurrency UAF bug can be shown as below:
    
    ax25_kill_by_device()        | ax25_release()
                                 |   ax25_destroy_socket()
      ...                        |   ...
                                 |   sock_put(sk); //FREE
      lock_sock(s->sk); //(1)    |
      s->ax25_dev = NULL;        |   ...
      release_sock(s->sk); //(2) |
      ...                        |
    
    The root cause is that the sock is released before dereference
    site (1) or (2). Therefore, this patch uses sock_hold() to increase
    the refcount of sock and uses ax25_list_lock to protect it, which
    can synchronize with ax25_cb_del() in ax25_destroy_socket() and
    ensure the sock wil not be released before dereference sites.
    
    Signed-off-by: Duoming Zhou <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block/wbt: fix negative inflight counter when remove scsi device [+ + +]
Author: Laibin Qiu <[email protected]>
Date:   Sat Jan 22 19:10:45 2022 +0800

    block/wbt: fix negative inflight counter when remove scsi device
    
    commit e92bc4cd34de2ce454bdea8cd198b8067ee4e123 upstream.
    
    Now that we disable wbt by set WBT_STATE_OFF_DEFAULT in
    wbt_disable_default() when switch elevator to bfq. And when
    we remove scsi device, wbt will be enabled by wbt_enable_default.
    If it become false positive between wbt_wait() and wbt_track()
    when submit write request.
    
    The following is the scenario that triggered the problem.
    
    T1                          T2                           T3
                                elevator_switch_mq
                                bfq_init_queue
                                wbt_disable_default <= Set
                                rwb->enable_state (OFF)
    Submit_bio
    blk_mq_make_request
    rq_qos_throttle
    <= rwb->enable_state (OFF)
                                                             scsi_remove_device
                                                             sd_remove
                                                             del_gendisk
                                                             blk_unregister_queue
                                                             elv_unregister_queue
                                                             wbt_enable_default
                                                             <= Set rwb->enable_state (ON)
    q_qos_track
    <= rwb->enable_state (ON)
    ^^^^^^ this request will mark WBT_TRACKED without inflight add and will
    lead to drop rqw->inflight to -1 in wbt_done() which will trigger IO hung.
    
    Fix this by move wbt_enable_default() from elv_unregister to
    bfq_exit_queue(). Only re-enable wbt when bfq exit.
    
    Fixes: 76a8040817b4b ("blk-wbt: make sure throttle is enabled properly")
    
    Remove oneline stale comment, and kill one oneshot local variable.
    
    Signed-off-by: Ming Lei <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/linux-block/[email protected]/
    Signed-off-by: Laibin Qiu <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
block: fix surprise removal for drivers calling blk_set_queue_dying [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Thu Feb 17 08:52:31 2022 +0100

    block: fix surprise removal for drivers calling blk_set_queue_dying
    
    commit 7a5428dcb7902700b830e912feee4e845df7c019 upstream.
    
    Various block drivers call blk_set_queue_dying to mark a disk as dead due
    to surprise removal events, but since commit 8e141f9eb803 that doesn't
    work given that the GD_DEAD flag needs to be set to stop I/O.
    
    Replace the driver calls to blk_set_queue_dying with a new (and properly
    documented) blk_mark_disk_dead API, and fold blk_set_queue_dying into the
    only remaining caller.
    
    Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk")
    Reported-by: Markus Blöchl <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bonding: fix data-races around agg_select_timer [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Feb 14 11:15:53 2022 -0800

    bonding: fix data-races around agg_select_timer
    
    commit 9ceaf6f76b203682bb6100e14b3d7da4c0bedde8 upstream.
    
    syzbot reported that two threads might write over agg_select_timer
    at the same time. Make agg_select_timer atomic to fix the races.
    
    BUG: KCSAN: data-race in bond_3ad_initiate_agg_selection / bond_3ad_state_machine_handler
    
    read to 0xffff8881242aea90 of 4 bytes by task 1846 on cpu 1:
     bond_3ad_state_machine_handler+0x99/0x2810 drivers/net/bonding/bond_3ad.c:2317
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     worker_thread+0x616/0xa70 kernel/workqueue.c:2454
     kthread+0x1bf/0x1e0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    write to 0xffff8881242aea90 of 4 bytes by task 25910 on cpu 0:
     bond_3ad_initiate_agg_selection+0x18/0x30 drivers/net/bonding/bond_3ad.c:1998
     bond_open+0x658/0x6f0 drivers/net/bonding/bond_main.c:3967
     __dev_open+0x274/0x3a0 net/core/dev.c:1407
     dev_open+0x54/0x190 net/core/dev.c:1443
     bond_enslave+0xcef/0x3000 drivers/net/bonding/bond_main.c:1937
     do_set_master net/core/rtnetlink.c:2532 [inline]
     do_setlink+0x94f/0x2500 net/core/rtnetlink.c:2736
     __rtnl_newlink net/core/rtnetlink.c:3414 [inline]
     rtnl_newlink+0xfeb/0x13e0 net/core/rtnetlink.c:3529
     rtnetlink_rcv_msg+0x745/0x7e0 net/core/rtnetlink.c:5594
     netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2494
     rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5612
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x602/0x6d0 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x728/0x850 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg net/socket.c:725 [inline]
     ____sys_sendmsg+0x39a/0x510 net/socket.c:2413
     ___sys_sendmsg net/socket.c:2467 [inline]
     __sys_sendmsg+0x195/0x230 net/socket.c:2496
     __do_sys_sendmsg net/socket.c:2505 [inline]
     __se_sys_sendmsg net/socket.c:2503 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2503
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x00000050 -> 0x0000004f
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 25910 Comm: syz-executor.1 Tainted: G        W         5.17.0-rc4-syzkaller-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Cc: Jay Vosburgh <[email protected]>
    Cc: Veaceslav Falico <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bonding: force carrier update when releasing slave [+ + +]
Author: Zhang Changzhong <[email protected]>
Date:   Wed Feb 16 22:18:08 2022 +0800

    bonding: force carrier update when releasing slave
    
    commit a6ab75cec1e461f8a35559054c146c21428430b8 upstream.
    
    In __bond_release_one(), bond_set_carrier() is only called when bond
    device has no slave. Therefore, if we remove the up slave from a master
    with two slaves and keep the down slave, the master will remain up.
    
    Fix this by moving bond_set_carrier() out of if (!bond_has_slaves(bond))
    statement.
    
    Reproducer:
    $ insmod bonding.ko mode=0 miimon=100 max_bonds=2
    $ ifconfig bond0 up
    $ ifenslave bond0 eth0 eth1
    $ ifconfig eth0 down
    $ ifenslave -d bond0 eth1
    $ cat /proc/net/bonding/bond0
    
    Fixes: ff59c4563a8d ("[PATCH] bonding: support carrier state for master")
    Signed-off-by: Zhang Changzhong <[email protected]>
    Acked-by: Jay Vosburgh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
brcmfmac: firmware: Fix crash in brcm_alt_fw_path [+ + +]
Author: Phil Elwell <[email protected]>
Date:   Tue Jan 18 15:45:14 2022 +0000

    brcmfmac: firmware: Fix crash in brcm_alt_fw_path
    
    commit 665408f4c3a5c83e712871daa062721624b2b79e upstream.
    
    The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected
    by a check to the validity of the fwctx->req->board_type pointer. This
    results in a crash in strlcat when, for example, the WLAN chip is found
    in a USB dongle.
    
    Prevent the crash by adding the necessary check.
    
    See: https://github.com/raspberrypi/linux/issues/4833
    
    Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries")
    Signed-off-by: Phil Elwell <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
btrfs: send: in case of IO error log it [+ + +]
Author: Dāvis Mosāns <[email protected]>
Date:   Sat Feb 5 20:48:23 2022 +0200

    btrfs: send: in case of IO error log it
    
    commit 2e7be9db125a0bf940c5d65eb5c40d8700f738b5 upstream.
    
    Currently if we get IO error while doing send then we abort without
    logging information about which file caused issue.  So log it to help
    with debugging.
    
    CC: [email protected] # 4.9+
    Signed-off-by: Dāvis Mosāns <[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: cache reported zone during mount [+ + +]
Author: Naohiro Aota <[email protected]>
Date:   Thu Nov 11 14:14:38 2021 +0900

    btrfs: zoned: cache reported zone during mount
    
    commit 16beac87e95e2fb278b552397c8260637f8a63f7 upstream.
    
    When mounting a device, we are reporting the zones twice: once for
    checking the zone attributes in btrfs_get_dev_zone_info and once for
    loading block groups' zone info in
    btrfs_load_block_group_zone_info(). With a lot of block groups, that
    leads to a lot of REPORT ZONE commands and slows down the mount
    process.
    
    This patch introduces a zone info cache in struct
    btrfs_zoned_device_info. The cache is populated while in
    btrfs_get_dev_zone_info() and used for
    btrfs_load_block_group_zone_info() to reduce the number of REPORT ZONE
    commands. The zone cache is then released after loading the block
    groups, as it will not be much effective during the run time.
    
    Benchmark: Mount an HDD with 57,007 block groups
    Before patch: 171.368 seconds
    After patch: 64.064 seconds
    
    While it still takes a minute due to the slowness of loading all the
    block groups, the patch reduces the mount time by 1/3.
    
    Link: https://lore.kernel.org/linux-btrfs/CAHQ7scUiLtcTqZOMMY5kbWUBOhGRwKo6J6wYPT5WY+C=cD49nQ@mail.gmail.com/
    Fixes: 5b316468983d ("btrfs: get zone information of zoned block devices")
    CC: [email protected]
    Signed-off-by: Naohiro Aota <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cfg80211: fix race in netlink owner interface destruction [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Feb 1 14:09:51 2022 +0100

    cfg80211: fix race in netlink owner interface destruction
    
    commit f0a6fd1527067da537e9c48390237488719948ed upstream.
    
    My previous fix here to fix the deadlock left a race where
    the exact same deadlock (see the original commit referenced
    below) can still happen if cfg80211_destroy_ifaces() already
    runs while nl80211_netlink_notify() is still marking some
    interfaces as nl_owner_dead.
    
    The race happens because we have two loops here - first we
    dev_close() all the netdevs, and then we destroy them. If we
    also have two netdevs (first one need only be a wdev though)
    then we can find one during the first iteration, close it,
    and go to the second iteration -- but then find two, and try
    to destroy also the one we didn't close yet.
    
    Fix this by only iterating once.
    
    Reported-by: Toke Høiland-Jørgensen <[email protected]>
    Fixes: ea6b2098dd02 ("cfg80211: fix locking in netlink owner interface destruction")
    Tested-by: Toke Høiland-Jørgensen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cifs: fix set of group SID via NTSD xattrs [+ + +]
Author: Amir Goldstein <[email protected]>
Date:   Mon Jan 3 16:50:25 2022 +0200

    cifs: fix set of group SID via NTSD xattrs
    
    commit dd5a927e411836eaef44eb9b00fece615e82e242 upstream.
    
    'setcifsacl -g <SID>' silently fails to set the group SID on server.
    
    Actually, the bug existed since commit 438471b67963 ("CIFS: Add support
    for setting owner info, dos attributes, and create time"), but this fix
    will not apply cleanly to kernel versions <= v5.10.
    
    Fixes: 3970acf7ddb9 ("SMB3: Add support for getting and setting SACLs")
    Cc: [email protected] # 5.11+
    Signed-off-by: Amir Goldstein <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
copy_process(): Move fd_install() out of sighand->siglock critical section [+ + +]
Author: Waiman Long <[email protected]>
Date:   Tue Feb 8 11:39:12 2022 -0500

    copy_process(): Move fd_install() out of sighand->siglock critical section
    
    commit ddc204b517e60ae64db34f9832dc41dafa77c751 upstream.
    
    I was made aware of the following lockdep splat:
    
    [ 2516.308763] =====================================================
    [ 2516.309085] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
    [ 2516.309433] 5.14.0-51.el9.aarch64+debug #1 Not tainted
    [ 2516.309703] -----------------------------------------------------
    [ 2516.310149] stress-ng/153663 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
    [ 2516.310512] ffff0000e422b198 (&newf->file_lock){+.+.}-{2:2}, at: fd_install+0x368/0x4f0
    [ 2516.310944]
                   and this task is already holding:
    [ 2516.311248] ffff0000c08140d8 (&sighand->siglock){-.-.}-{2:2}, at: copy_process+0x1e2c/0x3e80
    [ 2516.311804] which would create a new lock dependency:
    [ 2516.312066]  (&sighand->siglock){-.-.}-{2:2} -> (&newf->file_lock){+.+.}-{2:2}
    [ 2516.312446]
                   but this new dependency connects a HARDIRQ-irq-safe lock:
    [ 2516.312983]  (&sighand->siglock){-.-.}-{2:2}
       :
    [ 2516.330700]  Possible interrupt unsafe locking scenario:
    
    [ 2516.331075]        CPU0                    CPU1
    [ 2516.331328]        ----                    ----
    [ 2516.331580]   lock(&newf->file_lock);
    [ 2516.331790]                                local_irq_disable();
    [ 2516.332231]                                lock(&sighand->siglock);
    [ 2516.332579]                                lock(&newf->file_lock);
    [ 2516.332922]   <Interrupt>
    [ 2516.333069]     lock(&sighand->siglock);
    [ 2516.333291]
                    *** DEADLOCK ***
    [ 2516.389845]
                   stack backtrace:
    [ 2516.390101] CPU: 3 PID: 153663 Comm: stress-ng Kdump: loaded Not tainted 5.14.0-51.el9.aarch64+debug #1
    [ 2516.390756] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
    [ 2516.391155] Call trace:
    [ 2516.391302]  dump_backtrace+0x0/0x3e0
    [ 2516.391518]  show_stack+0x24/0x30
    [ 2516.391717]  dump_stack_lvl+0x9c/0xd8
    [ 2516.391938]  dump_stack+0x1c/0x38
    [ 2516.392247]  print_bad_irq_dependency+0x620/0x710
    [ 2516.392525]  check_irq_usage+0x4fc/0x86c
    [ 2516.392756]  check_prev_add+0x180/0x1d90
    [ 2516.392988]  validate_chain+0x8e0/0xee0
    [ 2516.393215]  __lock_acquire+0x97c/0x1e40
    [ 2516.393449]  lock_acquire.part.0+0x240/0x570
    [ 2516.393814]  lock_acquire+0x90/0xb4
    [ 2516.394021]  _raw_spin_lock+0xe8/0x154
    [ 2516.394244]  fd_install+0x368/0x4f0
    [ 2516.394451]  copy_process+0x1f5c/0x3e80
    [ 2516.394678]  kernel_clone+0x134/0x660
    [ 2516.394895]  __do_sys_clone3+0x130/0x1f4
    [ 2516.395128]  __arm64_sys_clone3+0x5c/0x7c
    [ 2516.395478]  invoke_syscall.constprop.0+0x78/0x1f0
    [ 2516.395762]  el0_svc_common.constprop.0+0x22c/0x2c4
    [ 2516.396050]  do_el0_svc+0xb0/0x10c
    [ 2516.396252]  el0_svc+0x24/0x34
    [ 2516.396436]  el0t_64_sync_handler+0xa4/0x12c
    [ 2516.396688]  el0t_64_sync+0x198/0x19c
    [ 2517.491197] NET: Registered PF_ATMPVC protocol family
    [ 2517.491524] NET: Registered PF_ATMSVC protocol family
    [ 2591.991877] sched: RT throttling activated
    
    One way to solve this problem is to move the fd_install() call out of
    the sighand->siglock critical section.
    
    Before commit 6fd2fe494b17 ("copy_process(): don't use ksys_close()
    on cleanups"), the pidfd installation was done without holding both
    the task_list lock and the sighand->siglock. Obviously, holding these
    two locks are not really needed to protect the fd_install() call.
    So move the fd_install() call down to after the releases of both locks.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 6fd2fe494b17 ("copy_process(): don't use ksys_close() on cleanups")
    Reviewed-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Waiman Long <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
display/amd: decrease message verbosity about watermarks table failure [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Jan 25 15:49:47 2022 -0600

    display/amd: decrease message verbosity about watermarks table failure
    
    [ Upstream commit 03ad3093c7c069d6ab4403730009ebafeea9ee37 ]
    
    A number of BIOS versions have a problem with the watermarks table not
    being configured properly.  This manifests as a very scary looking warning
    during resume from s0i3.  This should be harmless in most cases and is well
    understood, so decrease the assertion to a clearer warning about the problem.
    
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: ptdma: Fix the error handling path in pt_core_init() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Feb 5 07:58:44 2022 +0100

    dmaengine: ptdma: Fix the error handling path in pt_core_init()
    
    commit 3c62fd3406e0b2277c76a6984d3979c7f3f1d129 upstream.
    
    In order to free resources correctly in the error handling path of
    pt_core_init(), 2 goto's have to be switched. Otherwise, some resources
    will leak and we will try to release things that have not been allocated
    yet.
    
    Also move a dev_err() to a place where it is more meaningful.
    
    Fixes: fa5d823b16a9 ("dmaengine: ptdma: Initial driver for the AMD PTDMA")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Acked-by: Sanjay R Mehta <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/41a963a35173f89c874f5c44df5530dc09fea8da.1644044244.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dmaengine: sh: rcar-dmac: Check for error num after dma_set_max_seg_size [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Tue Jan 11 09:12:39 2022 +0800

    dmaengine: sh: rcar-dmac: Check for error num after dma_set_max_seg_size
    
    commit da2ad87fba0891576aadda9161b8505fde81a84d upstream.
    
    As the possible failure of the dma_set_max_seg_size(), it should be
    better to check the return value of the dma_set_max_seg_size().
    
    Fixes: 97d49c59e219 ("dmaengine: rcar-dmac: set scatter/gather max segment size")
    Reported-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[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: sh: rcar-dmac: Check for error num after setting mask [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Thu Jan 6 11:09:39 2022 +0800

    dmaengine: sh: rcar-dmac: Check for error num after setting mask
    
    commit 2d21543efe332cd8c8f212fb7d365bc8b0690bfa upstream.
    
    Because of the possible failure of the dma_supported(), the
    dma_set_mask_and_coherent() may return error num.
    Therefore, it should be better to check it and return the error if
    fails.
    
    Fixes: dc312349e875 ("dmaengine: rcar-dmac: Widen DMA mask to 40 bits")
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[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: stm32-dmamux: Fix PM disable depth imbalance in stm32_dmamux_probe [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Sat Jan 8 08:53:36 2022 +0000

    dmaengine: stm32-dmamux: Fix PM disable depth imbalance in stm32_dmamux_probe
    
    commit e831c7aba950f3ae94002b10321279654525e5ec upstream.
    
    The pm_runtime_enable will increase power disable depth.
    If the probe fails, we should use pm_runtime_disable() to balance
    pm_runtime_enable().
    
    Fixes: 4f3ceca254e0 ("dmaengine: stm32-dmamux: Add PM Runtime support")
    Signed-off-by: Miaoqian Lin <[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: Greg Kroah-Hartman <[email protected]>

 
dpaa2-eth: Initialize mutex used in one step timestamping path [+ + +]
Author: Radu Bulie <[email protected]>
Date:   Mon Feb 14 19:45:34 2022 +0200

    dpaa2-eth: Initialize mutex used in one step timestamping path
    
    commit 07dd44852be89386ab12210df90a2d78779f3bff upstream.
    
    1588 Single Step Timestamping code path uses a mutex to
    enforce atomicity for two events:
    - update of ptp single step register
    - transmit ptp event packet
    
    Before this patch the mutex was not initialized. This
    caused unexpected crashes in the Tx function.
    
    Fixes: c55211892f463 ("dpaa2-eth: support PTP Sync packet one-step timestamping")
    Signed-off-by: Radu Bulie <[email protected]>
    Reviewed-by: Ioana Ciornei <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dpaa2-switch: fix default return of dpaa2_switch_flower_parse_mirror_key [+ + +]
Author: Tom Rix <[email protected]>
Date:   Mon Feb 14 07:41:39 2022 -0800

    dpaa2-switch: fix default return of dpaa2_switch_flower_parse_mirror_key
    
    commit 2a36ed7c1cd55742503bed81d2cc0ea83bd0ad0c upstream.
    
    Clang static analysis reports this representative problem
    dpaa2-switch-flower.c:616:24: warning: The right operand of '=='
      is a garbage value
      tmp->cfg.vlan_id == vlan) {
                       ^  ~~~~
    vlan is set in dpaa2_switch_flower_parse_mirror_key(). However
    this function can return success without setting vlan.  So
    change the default return to -EOPNOTSUPP.
    
    Fixes: 0f3faece5808 ("dpaa2-switch: add VLAN based mirroring")
    Signed-off-by: Tom Rix <[email protected]>
    Reviewed-by: Ioana Ciornei <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Fri Feb 4 01:30:08 2022 +0800

    Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
    
    [ Upstream commit 8bc69f86328e87a0ffa79438430cc82f3aa6a194 ]
    
    kobject_init_and_add() takes reference even when it fails.
    According to the doc of kobject_init_and_add():
    
       If this function returns an error, kobject_put() must be called to
       properly clean up the memory associated with the object.
    
    Fix memory leak by calling kobject_put().
    
    Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Juan Vazquez <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Cap pflip irqs per max otg number [+ + +]
Author: Roman Li <[email protected]>
Date:   Wed Feb 2 14:30:09 2022 -0500

    drm/amd/display: Cap pflip irqs per max otg number
    
    [ Upstream commit 328e34a5ad227399391891d454043e5d73e598d2 ]
    
    [Why]
    pflip interrupt order are mapped 1 to 1 to otg id.
    e.g. if irq_src=26 corresponds to otg0 then 27->otg1, 28->otg2...
    
    Linux DM registers pflip interrupts per number of crtcs.
    In fused pipe case crtc numbers can be less than otg id.
    
    e.g. if one pipe out of 3(otg#0-2) is fused adev->mode_info.num_crtc=2
    so DM only registers irq_src 26,27.
    This is a bug since if pipe#2 remains unfused DM never gets
    otg2 pflip interrupt (irq_src=28)
    That may results in gfx failure due to pflip timeout.
    
    [How]
    Register pflip interrupts per max num of otg instead of num_crtc
    
    Signed-off-by: Roman Li <[email protected]>
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: fix yellow carp wm clamping [+ + +]
Author: Dmytro Laktyushkin <[email protected]>
Date:   Thu Jan 27 11:55:49 2022 -0500

    drm/amd/display: fix yellow carp wm clamping
    
    [ Upstream commit 60fdf98a774eee244a4e00c34a9e7729b61d0f44 ]
    
    Fix clamping to match register field size
    
    Reviewed-by: Charlene Liu <[email protected]>
    Acked-by: Jasdeep Dhillon <[email protected]>
    Signed-off-by: Dmytro Laktyushkin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm: correct the sequence of sending gpu reset msg [+ + +]
Author: Yifan Zhang <[email protected]>
Date:   Fri Feb 11 17:58:08 2022 +0800

    drm/amd/pm: correct the sequence of sending gpu reset msg
    
    commit 9c4f59ea3f865693150edf0c91d1cc6b451360dd upstream.
    
    the 2nd parameter should be smu msg type rather than asic msg index.
    
    Fixes: 7d38d9dc4ecc ("drm/amdgpu: add mode2 reset support for yellow carp")
    Signed-off-by: Yifan Zhang <[email protected]>
    Acked-by: Aaron Liu <[email protected]>
    Reviewed-by: Huang Rui <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd: add support to check whether the system is set to s3 [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Jan 25 21:35:09 2022 -0600

    drm/amd: add support to check whether the system is set to s3
    
    [ Upstream commit f52a2b8badbd24faf73a13c9c07fdb9d07352944 ]
    
    This will be used to help make decisions on what to do in
    misconfigured systems.
    
    v2: squash in semicolon fix from Stephen Rothwell
    
    Signed-off-by: Mario Limonciello <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd: Only run s3 or s0ix if system is configured properly [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Jan 25 21:37:57 2022 -0600

    drm/amd: Only run s3 or s0ix if system is configured properly
    
    [ Upstream commit 04ef860469fda6a646dc841190d05b31fae68e8c ]
    
    This will cause misconfigured systems to not run the GPU suspend
    routines.
    
    * In APUs that are properly configured system will go into s2idle.
    * In APUs that are intended to be S3 but user selects
      s2idle the GPU will stay fully powered for the suspend.
    * In APUs that are intended to be s2idle and system misconfigured
      the GPU will stay fully powered for the suspend.
    * In systems that are intended to be s2idle, but AMD dGPU is also
      present, the dGPU will go through S3
    
    Signed-off-by: Mario Limonciello <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd: Warn users about potential s0ix problems [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Jan 11 14:00:26 2022 -0600

    drm/amd: Warn users about potential s0ix problems
    
    [ Upstream commit a6ed2035878e5ad2e43ed175d8812ac9399d6c40 ]
    
    On some OEM setups users can configure the BIOS for S3 or S2idle.
    When configured to S3 users can still choose 's2idle' in the kernel by
    using `/sys/power/mem_sleep`.  Before commit 6dc8265f9803 ("drm/amdgpu:
    always reset the asic in suspend (v2)"), the GPU would crash.  Now when
    configured this way, the system should resume but will use more power.
    
    As such, adjust the `amdpu_acpi_is_s0ix function` to warn users about
    potential power consumption issues during their first attempt at
    suspending.
    
    Reported-by: Bjoren Dasse <[email protected]>
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1824
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: fix logic inversion in check [+ + +]
Author: Christian König <[email protected]>
Date:   Fri Jan 28 13:21:10 2022 +0100

    drm/amdgpu: fix logic inversion in check
    
    [ Upstream commit e8ae38720e1a685fd98cfa5ae118c9d07b45ca79 ]
    
    We probably never trigger this, but the logic inside the check is
    inverted.
    
    Signed-off-by: Christian König <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix. [+ + +]
Author: Rajib Mahapatra <[email protected]>
Date:   Thu Feb 10 18:46:40 2022 +0530

    drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix.
    
    commit f8f4e2a518347063179def4e64580b2d28233d03 upstream.
    
    [Why]
    SDMA ring buffer test failed if suspend is aborted during
    S0i3 resume.
    
    [How]
    If suspend is aborted for some reason during S0i3 resume
    cycle, it follows SDMA ring test failing and errors in amdgpu
    resume. For RN/CZN/Picasso, SMU saves and restores SDMA
    registers during S0ix cycle. So, skipping SDMA suspend and
    resume from driver solves the issue. This time, the system
    is able to resume gracefully even the suspend is aborted.
    
    Reviewed-by: Mario Limonciello <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Rajib Mahapatra <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/atomic: Don't pollute crtc_state->mode_blob with error pointers [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Wed Feb 9 11:19:27 2022 +0200

    drm/atomic: Don't pollute crtc_state->mode_blob with error pointers
    
    commit 439cf34c8e0a8a33d8c15a31be1b7423426bc765 upstream.
    
    Make sure we don't assign an error pointer to crtc_state->mode_blob
    as that will break all kinds of places that assume either NULL or a
    valid pointer (eg. drm_property_blob_put()).
    
    Cc: [email protected]
    Reported-by: fuyufan <[email protected]>
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Acked-by: Maxime Ripard <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/cma-helper: Set VM_DONTEXPAND for mmap [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Wed Oct 13 10:36:54 2021 -0400

    drm/cma-helper: Set VM_DONTEXPAND for mmap
    
    commit 59f39bfa6553d598cb22f694d45e89547f420d85 upstream.
    
    drm_gem_cma_mmap() cannot assume every implementation of dma_mmap_wc()
    will end up calling remap_pfn_range() (which happens to set the relevant
    vma flag, among others), so in order to make sure expectations around
    VM_DONTEXPAND are met, let it explicitly set the flag like most other
    GEM mmap implementations do.
    
    This avoids repeated warnings on a small minority of systems where the
    display is behind an IOMMU, and has a simple driver which does not
    override drm_gem_cma_default_funcs. Arm hdlcd is an in-tree affected
    driver. Out-of-tree, the Apple DCP driver is affected; this fix is
    required for DCP to be mainlined.
    
    [Alyssa: Update commit message.]
    
    Fixes: c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
    Acked-by: Daniel Vetter <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Signed-off-by: Alyssa Rosenzweig <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/gvt: Make DRM_I915_GVT depend on X86 [+ + +]
Author: Siva Mullati <[email protected]>
Date:   Fri Jan 7 15:22:35 2022 +0530

    drm/i915/gvt: Make DRM_I915_GVT depend on X86
    
    commit d72d69abfdb6e0375981cfdda8eb45143f12c77d upstream.
    
    GVT is not supported on non-x86 platforms, So add
    dependency of X86 on config parameter DRM_I915_GVT.
    
    Fixes: 0ad35fed618c ("drm/i915: gvt: Introduce the basic architecture of GVT-g")
    Signed-off-by: Siva Mullati <[email protected]>
    Signed-off-by: Zhi Wang <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Zhi Wang <[email protected]>
    Signed-off-by: Zhi Wang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/opregion: check port number bounds for SWSCI display power state [+ + +]
Author: Jani Nikula <[email protected]>
Date:   Thu Feb 10 12:36:42 2022 +0200

    drm/i915/opregion: check port number bounds for SWSCI display power state
    
    commit ea958422291de248b9e2eaaeea36004e84b64043 upstream.
    
    The mapping from enum port to whatever port numbering scheme is used by
    the SWSCI Display Power State Notification is odd, and the memory of it
    has faded. In any case, the parameter only has space for ports numbered
    [0..4], and UBSAN reports bit shift beyond it when the platform has port
    F or more.
    
    Since the SWSCI functionality is supposed to be obsolete for new
    platforms (i.e. ones that might have port F or more), just bail out
    early if the mapped and mangled port number is beyond what the Display
    Power State Notification can support.
    
    Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable")
    Cc: <[email protected]> # v3.13+
    Cc: Ville Syrjälä <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800
    Signed-off-by: Jani Nikula <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com
    (cherry picked from commit 24a644ebbfd3b13cda702f98907f9dd123e34bf9)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/ttm: tweak priority hint selection [+ + +]
Author: Matthew Auld <[email protected]>
Date:   Wed Feb 9 11:16:52 2022 +0000

    drm/i915/ttm: tweak priority hint selection
    
    commit 0bdc0a0699929c814a8aecd55d2accb8c11beae2 upstream.
    
    For some reason we are selecting PRIO_HAS_PAGES when we don't have
    mm.pages, and vice versa.
    
    v2(Thomas):
      - Add missing fixes tag
    
    Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Thomas Hellström <[email protected]>
    Reviewed-by: Thomas Hellström <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit ba2c5d15022a565da187d90e2fe44768e33e5034)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915: Fix dbuf slice config lookup [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Mon Feb 7 15:26:59 2022 +0200

    drm/i915: Fix dbuf slice config lookup
    
    commit 698bef8ff5d2edea5d1c9d6e5adf1bfed1e8a106 upstream.
    
    Apparently I totally fumbled the loop condition when I
    removed the ARRAY_SIZE() stuff from the dbuf slice config
    lookup. Comparing the loop index with the active_pipes bitmask
    is utter nonsense, what we want to do is check to see if the
    mask is zero or not.
    
    Note that the code actually ended up working correctly despite
    the fumble, up until commit eef173954432 ("drm/i915: Allow
    !join_mbus cases for adlp+ dbuf configuration") when things
    broke for real.
    
    Cc: [email protected]
    Fixes: 05e8155afe35 ("drm/i915: Use a sentinel to terminate the dbuf slice arrays")
    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 a28fde308c3c1c174249ff9559b57f24e6850086)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/i915: Fix mbus join config lookup [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Mon Feb 7 15:27:00 2022 +0200

    drm/i915: Fix mbus join config lookup
    
    commit 8d9d2a723d64b650f2e6423024ccb4a33f0cdc40 upstream.
    
    The bogus loop from compute_dbuf_slices() was copied into
    check_mbus_joined() as well. So this lookup is wrong as well.
    Fix it.
    
    Cc: [email protected]
    Fixes: f4dc00863226 ("drm/i915/adl_p: MBUS programming")
    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 053f2b85631316a9226f6340c1c0fd95634f7a5b)
    Signed-off-by: Tvrtko Ursulin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/nouveau/pmu/gm200-: use alternate falcon reset sequence [+ + +]
Author: Ben Skeggs <[email protected]>
Date:   Thu Feb 25 14:54:59 2021 +1000

    drm/nouveau/pmu/gm200-: use alternate falcon reset sequence
    
    commit 4cdd2450bf739bada353e82d27b00db9af8c3001 upstream.
    
    Signed-off-by: Ben Skeggs <[email protected]>
    Reviewed-by: Karol Herbst <[email protected]>
    Signed-off-by: Karol Herbst <[email protected]>
    Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
drm/radeon: Fix backlight control on iMac 12,1 [+ + +]
Author: Nicholas Bishop <[email protected]>
Date:   Fri Feb 11 14:57:39 2022 -0500

    drm/radeon: Fix backlight control on iMac 12,1
    
    commit 364438fd629f7611a84c8e6d7de91659300f1502 upstream.
    
    The iMac 12,1 does not use the gmux driver for backlight, so the radeon
    backlight device is needed to set the brightness.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1838
    Signed-off-by: Nicholas Bishop <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/rockchip: dw_hdmi: Do not leave clock enabled in error case [+ + +]
Author: Sascha Hauer <[email protected]>
Date:   Wed Jan 26 15:55:24 2022 +0100

    drm/rockchip: dw_hdmi: Do not leave clock enabled in error case
    
    [ Upstream commit c0cfbb122275da1b726481de5a8cffeb24e6322b ]
    
    The driver returns an error when devm_phy_optional_get() fails leaving
    the previously enabled clock turned on. Change order and enable the
    clock only after the phy has been acquired.
    
    Signed-off-by: Sascha Hauer <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drop_monitor: fix data-race in dropmon_net_event / trace_napi_poll_hit [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Feb 10 09:13:31 2022 -0800

    drop_monitor: fix data-race in dropmon_net_event / trace_napi_poll_hit
    
    commit dcd54265c8bc14bd023815e36e2d5f9d66ee1fee upstream.
    
    trace_napi_poll_hit() is reading stat->dev while another thread can write
    on it from dropmon_net_event()
    
    Use READ_ONCE()/WRITE_ONCE() here, RCU rules are properly enforced already,
    we only have to take care of load/store tearing.
    
    BUG: KCSAN: data-race in dropmon_net_event / trace_napi_poll_hit
    
    write to 0xffff88816f3ab9c0 of 8 bytes by task 20260 on cpu 1:
     dropmon_net_event+0xb8/0x2b0 net/core/drop_monitor.c:1579
     notifier_call_chain kernel/notifier.c:84 [inline]
     raw_notifier_call_chain+0x53/0xb0 kernel/notifier.c:392
     call_netdevice_notifiers_info net/core/dev.c:1919 [inline]
     call_netdevice_notifiers_extack net/core/dev.c:1931 [inline]
     call_netdevice_notifiers net/core/dev.c:1945 [inline]
     unregister_netdevice_many+0x867/0xfb0 net/core/dev.c:10415
     ip_tunnel_delete_nets+0x24a/0x280 net/ipv4/ip_tunnel.c:1123
     vti_exit_batch_net+0x2a/0x30 net/ipv4/ip_vti.c:515
     ops_exit_list net/core/net_namespace.c:173 [inline]
     cleanup_net+0x4dc/0x8d0 net/core/net_namespace.c:597
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     worker_thread+0x616/0xa70 kernel/workqueue.c:2454
     kthread+0x1bf/0x1e0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    read to 0xffff88816f3ab9c0 of 8 bytes by interrupt on cpu 0:
     trace_napi_poll_hit+0x89/0x1c0 net/core/drop_monitor.c:292
     trace_napi_poll include/trace/events/napi.h:14 [inline]
     __napi_poll+0x36b/0x3f0 net/core/dev.c:6366
     napi_poll net/core/dev.c:6432 [inline]
     net_rx_action+0x29e/0x650 net/core/dev.c:6519
     __do_softirq+0x158/0x2de kernel/softirq.c:558
     do_softirq+0xb1/0xf0 kernel/softirq.c:459
     __local_bh_enable_ip+0x68/0x70 kernel/softirq.c:383
     __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
     _raw_spin_unlock_bh+0x33/0x40 kernel/locking/spinlock.c:210
     spin_unlock_bh include/linux/spinlock.h:394 [inline]
     ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]
     wg_packet_decrypt_worker+0x73c/0x780 drivers/net/wireguard/receive.c:506
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     worker_thread+0x616/0xa70 kernel/workqueue.c:2454
     kthread+0x1bf/0x1e0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    value changed: 0xffff88815883e000 -> 0x0000000000000000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 26435 Comm: kworker/0:1 Not tainted 5.17.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: wg-crypt-wg2 wg_packet_decrypt_worker
    
    Fixes: 4ea7e38696c7 ("dropmon: add ability to detect when hardware dropsrxpackets")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Neil Horman <[email protected]>
    Reported-by: syzbot <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
EDAC: Fix calculation of returned address and next offset in edac_align_ptr() [+ + +]
Author: Eliav Farber <[email protected]>
Date:   Thu Jan 13 10:06:19 2022 +0000

    EDAC: Fix calculation of returned address and next offset in edac_align_ptr()
    
    commit f8efca92ae509c25e0a4bd5d0a86decea4f0c41e upstream.
    
    Do alignment logic properly and use the "ptr" local variable for
    calculating the remainder of the alignment.
    
    This became an issue because struct edac_mc_layer has a size that is not
    zero modulo eight, and the next offset that was prepared for the private
    data was unaligned, causing an alignment exception.
    
    The patch in Fixes: which broke this actually wanted to "what we
    actually care about is the alignment of the actual pointer that's about
    to be returned." But it didn't check that alignment.
    
    Use the correct variable "ptr" for that.
    
      [ bp: Massage commit message. ]
    
    Fixes: 8447c4d15e35 ("edac: Do alignment logic properly in edac_align_ptr()")
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Borislav Petkov <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fs/proc: task_mmu.c: don't read mapcount for migration entry [+ + +]
Author: Yang Shi <[email protected]>
Date:   Fri Feb 11 16:32:26 2022 -0800

    fs/proc: task_mmu.c: don't read mapcount for migration entry
    
    commit 24d7275ce2791829953ed4e72f68277ceb2571c6 upstream.
    
    The syzbot reported the below BUG:
    
      kernel BUG at include/linux/page-flags.h:785!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline]
      RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744
      Call Trace:
        page_mapcount include/linux/mm.h:837 [inline]
        smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466
        smaps_pte_entry fs/proc/task_mmu.c:538 [inline]
        smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601
        walk_pmd_range mm/pagewalk.c:128 [inline]
        walk_pud_range mm/pagewalk.c:205 [inline]
        walk_p4d_range mm/pagewalk.c:240 [inline]
        walk_pgd_range mm/pagewalk.c:277 [inline]
        __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379
        walk_page_vma+0x277/0x350 mm/pagewalk.c:530
        smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768
        smap_gather_stats fs/proc/task_mmu.c:741 [inline]
        show_smap+0xc6/0x440 fs/proc/task_mmu.c:822
        seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272
        seq_read+0x3e0/0x5b0 fs/seq_file.c:162
        vfs_read+0x1b5/0x600 fs/read_write.c:479
        ksys_read+0x12d/0x250 fs/read_write.c:619
        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+0x44/0xae
    
    The reproducer was trying to read /proc/$PID/smaps when calling
    MADV_FREE at the mean time.  MADV_FREE may split THPs if it is called
    for partial THP.  It may trigger the below race:
    
               CPU A                         CPU B
               -----                         -----
      smaps walk:                      MADV_FREE:
      page_mapcount()
        PageCompound()
                                       split_huge_page()
        page = compound_head(page)
        PageDoubleMap(page)
    
    When calling PageDoubleMap() this page is not a tail page of THP anymore
    so the BUG is triggered.
    
    This could be fixed by elevated refcount of the page before calling
    mapcount, but that would prevent it from counting migration entries, and
    it seems overkilling because the race just could happen when PMD is
    split so all PTE entries of tail pages are actually migration entries,
    and smaps_account() does treat migration entries as mapcount == 1 as
    Kirill pointed out.
    
    Add a new parameter for smaps_account() to tell this entry is migration
    entry then skip calling page_mapcount().  Don't skip getting mapcount
    for device private entries since they do track references with mapcount.
    
    Pagemap also has the similar issue although it was not reported.  Fixed
    it as well.
    
    [[email protected]: v4]
      Link: https://lkml.kernel.org/r/[email protected]
    [[email protected]: avoid unused variable warning in pagemap_pmd_range()]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: e9b61f19858a ("thp: reintroduce split_huge_page()")
    Signed-off-by: Yang Shi <[email protected]>
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reported-by: [email protected]
    Acked-by: David Hildenbrand <[email protected]>
    Cc: "Kirill A. Shutemov" <[email protected]>
    Cc: Jann Horn <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Alexey Dobriyan <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gcc-plugins/stackleak: Use noinstr in favor of notrace [+ + +]
Author: Kees Cook <[email protected]>
Date:   Thu Feb 3 12:17:54 2022 -0800

    gcc-plugins/stackleak: Use noinstr in favor of notrace
    
    [ Upstream commit dcb85f85fa6f142aae1fe86f399d4503d49f2b60 ]
    
    While the stackleak plugin was already using notrace, objtool is now a
    bit more picky.  Update the notrace uses to noinstr.  Silences the
    following objtool warnings when building with:
    
    CONFIG_DEBUG_ENTRY=y
    CONFIG_STACK_VALIDATION=y
    CONFIG_VMLINUX_VALIDATION=y
    CONFIG_GCC_PLUGIN_STACKLEAK=y
    
      vmlinux.o: warning: objtool: do_syscall_64()+0x9: call to stackleak_track_stack() leaves .noinstr.text section
      vmlinux.o: warning: objtool: do_int80_syscall_32()+0x9: call to stackleak_track_stack() leaves .noinstr.text section
      vmlinux.o: warning: objtool: exc_general_protection()+0x22: call to stackleak_track_stack() leaves .noinstr.text section
      vmlinux.o: warning: objtool: fixup_bad_iret()+0x20: call to stackleak_track_stack() leaves .noinstr.text section
      vmlinux.o: warning: objtool: do_machine_check()+0x27: call to stackleak_track_stack() leaves .noinstr.text section
      vmlinux.o: warning: objtool: .text+0x5346e: call to stackleak_erase() leaves .noinstr.text section
      vmlinux.o: warning: objtool: .entry.text+0x143: call to stackleak_erase() leaves .noinstr.text section
      vmlinux.o: warning: objtool: .entry.text+0x10eb: call to stackleak_erase() leaves .noinstr.text section
      vmlinux.o: warning: objtool: .entry.text+0x17f9: call to stackleak_erase() leaves .noinstr.text section
    
    Note that the plugin's addition of calls to stackleak_track_stack() from
    noinstr functions is expected to be safe, as it isn't runtime
    instrumentation and is self-contained.
    
    Cc: Alexander Popov <[email protected]>
    Suggested-by: Peter Zijlstra <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: amd_sfh: Add illuminance mask to limit ALS max value [+ + +]
Author: Basavaraj Natikar <[email protected]>
Date:   Mon Jan 31 22:48:33 2022 +0530

    HID: amd_sfh: Add illuminance mask to limit ALS max value
    
    commit 91aaea527bc3b707c5d3208cde035421ed54f79c upstream.
    
    ALS illuminance value present only in first 15 bits from SFH firmware
    for V2 platforms. Hence added a mask of 15 bit to limit ALS max
    illuminance values to get correct illuminance value.
    
    Fixes: 0aad9c95eb9a ("HID: amd_sfh: Extend ALS support for newer AMD platform")
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: amd_sfh: Correct the structure field name [+ + +]
Author: Basavaraj Natikar <[email protected]>
Date:   Tue Feb 8 17:51:09 2022 +0530

    HID: amd_sfh: Correct the structure field name
    
    commit aa0b724a2bf041036e56cbb3b4b3afde7c5e7c9e upstream.
    
    Misinterpreted intr_enable field name. Hence correct the structure
    field name accordingly to reflect the functionality.
    
    Fixes: f264481ad614 ("HID: amd_sfh: Extend driver capabilities for multi-generation support")
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: amd_sfh: Increase sensor command timeout [+ + +]
Author: Basavaraj Natikar <[email protected]>
Date:   Mon Jan 31 22:48:32 2022 +0530

    HID: amd_sfh: Increase sensor command timeout
    
    commit a7072c01c3ac3ae6ecd08fa7b43431cfc8ed331f upstream.
    
    HPD sensors take more time to initialize. Hence increasing sensor
    command timeout to get response with status within a max timeout.
    
    Fixes: 173709f50e98 ("HID: amd_sfh: Add command response to check command status")
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: elo: fix memory leak in elo_probe [+ + +]
Author: Dongliang Mu <[email protected]>
Date:   Sat Jan 22 17:48:26 2022 +0800

    HID: elo: fix memory leak in elo_probe
    
    [ Upstream commit 817b8b9c5396d2b2d92311b46719aad5d3339dbe ]
    
    When hid_parse() in elo_probe() fails, it forgets to call usb_put_dev to
    decrease the refcount.
    
    Fix this by adding usb_put_dev() in the error handling code of elo_probe().
    
    Fixes: fbf42729d0e9 ("HID: elo: update the reference count of the usb device structure")
    Reported-by: syzkaller <[email protected]>
    Signed-off-by: Dongliang Mu <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: i2c-hid: goodix: Fix a lockdep splat [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Fri Jan 28 17:46:25 2022 +0000

    HID: i2c-hid: goodix: Fix a lockdep splat
    
    commit 2787710f73fcce4a9bdab540aaf1aef778a27462 upstream.
    
    I'm was on the receiving end of a lockdep splat from this driver and after
    scratching my head I couldn't be entirely sure it was a false positive
    given we would also have to think about whether the regulator locking is
    safe (since the notifier is called whilst holding regulator locks which
    are also needed for regulator_is_enabled() ).
    
    Regardless of whether it is a real bug or not, the mutex isn't needed.
    We can use reference counting tricks instead to avoid races with the
    notifier calls.
    
    The observed splat follows:
    
    ------------------------------------------------------
    kworker/u16:3/127 is trying to acquire lock:
    ffff00008021fb20 (&ihid_goodix->regulator_mutex){+.+.}-{4:4}, at: ihid_goodix_vdd_notify+0x30/0x94
    
    but task is already holding lock:
    ffff0000835c60c0 (&(&rdev->notifier)->rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x30/0x70
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (&(&rdev->notifier)->rwsem){++++}-{4:4}:
           down_write+0x68/0x8c
           blocking_notifier_chain_register+0x54/0x70
           regulator_register_notifier+0x1c/0x24
           devm_regulator_register_notifier+0x58/0x98
           i2c_hid_of_goodix_probe+0xdc/0x158
           i2c_device_probe+0x25d/0x270
           really_probe+0x174/0x2cc
           __driver_probe_device+0xc0/0xd8
           driver_probe_device+0x50/0xe4
           __device_attach_driver+0xa8/0xc0
           bus_for_each_drv+0x9c/0xc0
           __device_attach_async_helper+0x6c/0xbc
           async_run_entry_fn+0x38/0x100
           process_one_work+0x294/0x438
           worker_thread+0x180/0x258
           kthread+0x120/0x130
           ret_from_fork+0x10/0x20
    
    -> #0 (&ihid_goodix->regulator_mutex){+.+.}-{4:4}:
           __lock_acquire+0xd24/0xfe8
           lock_acquire+0x288/0x2f4
           __mutex_lock+0xa0/0x338
           mutex_lock_nested+0x3c/0x5c
           ihid_goodix_vdd_notify+0x30/0x94
           notifier_call_chain+0x6c/0x8c
           blocking_notifier_call_chain+0x48/0x70
           _notifier_call_chain.isra.0+0x18/0x20
           _regulator_enable+0xc0/0x178
           regulator_enable+0x40/0x7c
           goodix_i2c_hid_power_up+0x18/0x20
           i2c_hid_core_power_up.isra.0+0x1c/0x2c
           i2c_hid_core_probe+0xd8/0x3d4
           i2c_hid_of_goodix_probe+0x14c/0x158
           i2c_device_probe+0x25c/0x270
           really_probe+0x174/0x2cc
           __driver_probe_device+0xc0/0xd8
           driver_probe_device+0x50/0xe4
           __device_attach_driver+0xa8/0xc0
           bus_for_each_drv+0x9c/0xc0
           __device_attach_async_helper+0x6c/0xbc
           async_run_entry_fn+0x38/0x100
           process_one_work+0x294/0x438
           worker_thread+0x180/0x258
           kthread+0x120/0x130
           ret_from_fork+0x10/0x20
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&(&rdev->notifier)->rwsem);
                                   lock(&ihid_goodix->regulator_mutex);
                                   lock(&(&rdev->notifier)->rwsem);
      lock(&ihid_goodix->regulator_mutex);
    
     *** DEADLOCK ***
    
    Signed-off-by: Daniel Thompson <[email protected]>
    Fixes: 18eeef46d359 ("HID: i2c-hid: goodix: Tie the reset line to true state of the regulator")
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: HID:Add support for UGTABLET WP5540 [+ + +]
Author: Sergio Costas <[email protected]>
Date:   Fri Feb 4 10:01:17 2022 +0100

    HID:Add support for UGTABLET WP5540
    
    commit fd5dd6acd8f823ea804f76d3af64fa1be9d5fb78 upstream.
    
    This patch adds support for the UGTABLET WP5540 digitizer tablet
    devices. Without it, the pen moves the cursor, but neither the
    buttons nor the tap sensor in the tip do work.
    
    Signed-off-by: Sergio Costas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: brcmstb: fix support for DSL and CM variants [+ + +]
Author: Rafał Miłecki <[email protected]>
Date:   Tue Feb 15 08:27:35 2022 +0100

    i2c: brcmstb: fix support for DSL and CM variants
    
    commit 834cea3a252ed4847db076a769ad9efe06afe2d5 upstream.
    
    DSL and CM (Cable Modem) support 8 B max transfer size and have a custom
    DT binding for that reason. This driver was checking for a wrong
    "compatible" however which resulted in an incorrect setup.
    
    Fixes: e2e5a2c61837 ("i2c: brcmstb: Adding support for CM and DSL SoCs")
    Signed-off-by: Rafał Miłecki <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: qcom-cci: don't delete an unregistered adapter [+ + +]
Author: Vladimir Zapolskiy <[email protected]>
Date:   Thu Feb 3 18:47:00 2022 +0200

    i2c: qcom-cci: don't delete an unregistered adapter
    
    commit a0d48505a1d68e27220369e2dd1e3573a2f362d2 upstream.
    
    If i2c_add_adapter() fails to add an I2C adapter found on QCOM CCI
    controller, on error path i2c_del_adapter() is still called.
    
    Fortunately there is a sanity check in the I2C core, so the only
    visible implication is a printed debug level message:
    
        i2c-core: attempting to delete unregistered adapter [Qualcomm-CCI]
    
    Nevertheless it would be reasonable to correct the probe error path.
    
    Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver")
    Signed-off-by: Vladimir Zapolskiy <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: qcom-cci: don't put a device tree node before i2c_add_adapter() [+ + +]
Author: Vladimir Zapolskiy <[email protected]>
Date:   Thu Feb 3 18:47:03 2022 +0200

    i2c: qcom-cci: don't put a device tree node before i2c_add_adapter()
    
    commit 02a4a69667a2ad32f3b52ca906f19628fbdd8a01 upstream.
    
    There is a minor chance for a race, if a pointer to an i2c-bus subnode
    is stored and then reused after releasing its reference, and it would
    be sufficient to get one more reference under a loop over children
    subnodes.
    
    Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver")
    Signed-off-by: Vladimir Zapolskiy <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ice: enable parsing IPSEC SPI headers for RSS [+ + +]
Author: Jesse Brandeburg <[email protected]>
Date:   Fri Feb 11 09:14:18 2022 -0800

    ice: enable parsing IPSEC SPI headers for RSS
    
    commit 86006f996346e8a5a1ea80637ec949ceeea4ecbc upstream.
    
    The COMMS package can enable the hardware parser to recognize IPSEC
    frames with ESP header and SPI identifier.  If this package is available
    and configured for loading in /lib/firmware, then the driver will
    succeed in enabling this protocol type for RSS.
    
    This in turn allows the hardware to hash over the SPI and use it to pick
    a consistent receive queue for the same secure flow. Without this all
    traffic is steered to the same queue for multiple traffic threads from
    the same IP address. For that reason this is marked as a fix, as the
    driver supports the model, but it wasn't enabled.
    
    If the package is not available, adding this type will fail, but the
    failure is ignored on purpose as it has no negative affect.
    
    Fixes: c90ed40cefe1 ("ice: Enable writing hardware filtering tables")
    Signed-off-by: Jesse Brandeburg <[email protected]>
    Tested-by: Gurucharan G <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ipv4: fix data races in fib_alias_hw_flags_set [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Feb 16 09:32:16 2022 -0800

    ipv4: fix data races in fib_alias_hw_flags_set
    
    commit 9fcf986cc4bc6a3a39f23fbcbbc3a9e52d3c24fd upstream.
    
    fib_alias_hw_flags_set() can be used by concurrent threads,
    and is only RCU protected.
    
    We need to annotate accesses to following fields of struct fib_alias:
    
        offload, trap, offload_failed
    
    Because of READ_ONCE()WRITE_ONCE() limitations, make these
    field u8.
    
    BUG: KCSAN: data-race in fib_alias_hw_flags_set / fib_alias_hw_flags_set
    
    read to 0xffff888134224a6a of 1 bytes by task 2013 on cpu 1:
     fib_alias_hw_flags_set+0x28a/0x470 net/ipv4/fib_trie.c:1050
     nsim_fib4_rt_hw_flags_set drivers/net/netdevsim/fib.c:350 [inline]
     nsim_fib4_rt_add drivers/net/netdevsim/fib.c:367 [inline]
     nsim_fib4_rt_insert drivers/net/netdevsim/fib.c:429 [inline]
     nsim_fib4_event drivers/net/netdevsim/fib.c:461 [inline]
     nsim_fib_event drivers/net/netdevsim/fib.c:881 [inline]
     nsim_fib_event_work+0x1852/0x2cf0 drivers/net/netdevsim/fib.c:1477
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     process_scheduled_works kernel/workqueue.c:2370 [inline]
     worker_thread+0x7df/0xa70 kernel/workqueue.c:2456
     kthread+0x1bf/0x1e0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    write to 0xffff888134224a6a of 1 bytes by task 4872 on cpu 0:
     fib_alias_hw_flags_set+0x2d5/0x470 net/ipv4/fib_trie.c:1054
     nsim_fib4_rt_hw_flags_set drivers/net/netdevsim/fib.c:350 [inline]
     nsim_fib4_rt_add drivers/net/netdevsim/fib.c:367 [inline]
     nsim_fib4_rt_insert drivers/net/netdevsim/fib.c:429 [inline]
     nsim_fib4_event drivers/net/netdevsim/fib.c:461 [inline]
     nsim_fib_event drivers/net/netdevsim/fib.c:881 [inline]
     nsim_fib_event_work+0x1852/0x2cf0 drivers/net/netdevsim/fib.c:1477
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     process_scheduled_works kernel/workqueue.c:2370 [inline]
     worker_thread+0x7df/0xa70 kernel/workqueue.c:2456
     kthread+0x1bf/0x1e0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    value changed: 0x00 -> 0x02
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 4872 Comm: kworker/0:0 Not tainted 5.17.0-rc3-syzkaller-00188-g1d41d2e82623-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events nsim_fib_event_work
    
    Fixes: 90b93f1b31f8 ("ipv4: Add "offload" and "trap" indications to routes")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ipv6: fix data-race in fib6_info_hw_flags_set / fib6_purge_rt [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Feb 16 09:32:17 2022 -0800

    ipv6: fix data-race in fib6_info_hw_flags_set / fib6_purge_rt
    
    commit d95d6320ba7a51d61c097ffc3bcafcf70283414e upstream.
    
    Because fib6_info_hw_flags_set() is called without any synchronization,
    all accesses to gi6->offload, fi->trap and fi->offload_failed
    need some basic protection like READ_ONCE()/WRITE_ONCE().
    
    BUG: KCSAN: data-race in fib6_info_hw_flags_set / fib6_purge_rt
    
    read to 0xffff8881087d5886 of 1 bytes by task 13953 on cpu 0:
     fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1007 [inline]
     fib6_purge_rt+0x4f/0x580 net/ipv6/ip6_fib.c:1033
     fib6_del_route net/ipv6/ip6_fib.c:1983 [inline]
     fib6_del+0x696/0x890 net/ipv6/ip6_fib.c:2028
     __ip6_del_rt net/ipv6/route.c:3876 [inline]
     ip6_del_rt+0x83/0x140 net/ipv6/route.c:3891
     __ipv6_dev_ac_dec+0x2b5/0x370 net/ipv6/anycast.c:374
     ipv6_dev_ac_dec net/ipv6/anycast.c:387 [inline]
     __ipv6_sock_ac_close+0x141/0x200 net/ipv6/anycast.c:207
     ipv6_sock_ac_close+0x79/0x90 net/ipv6/anycast.c:220
     inet6_release+0x32/0x50 net/ipv6/af_inet6.c:476
     __sock_release net/socket.c:650 [inline]
     sock_close+0x6c/0x150 net/socket.c:1318
     __fput+0x295/0x520 fs/file_table.c:280
     ____fput+0x11/0x20 fs/file_table.c:313
     task_work_run+0x8e/0x110 kernel/task_work.c:164
     tracehook_notify_resume include/linux/tracehook.h:189 [inline]
     exit_to_user_mode_loop kernel/entry/common.c:175 [inline]
     exit_to_user_mode_prepare+0x160/0x190 kernel/entry/common.c:207
     __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
     syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:300
     do_syscall_64+0x50/0xd0 arch/x86/entry/common.c:86
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    write to 0xffff8881087d5886 of 1 bytes by task 1912 on cpu 1:
     fib6_info_hw_flags_set+0x155/0x3b0 net/ipv6/route.c:6230
     nsim_fib6_rt_hw_flags_set drivers/net/netdevsim/fib.c:668 [inline]
     nsim_fib6_rt_add drivers/net/netdevsim/fib.c:691 [inline]
     nsim_fib6_rt_insert drivers/net/netdevsim/fib.c:756 [inline]
     nsim_fib6_event drivers/net/netdevsim/fib.c:853 [inline]
     nsim_fib_event drivers/net/netdevsim/fib.c:886 [inline]
     nsim_fib_event_work+0x284f/0x2cf0 drivers/net/netdevsim/fib.c:1477
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     worker_thread+0x616/0xa70 kernel/workqueue.c:2454
     kthread+0x2c7/0x2e0 kernel/kthread.c:327
     ret_from_fork+0x1f/0x30
    
    value changed: 0x22 -> 0x2a
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 1912 Comm: kworker/1:3 Not tainted 5.16.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events nsim_fib_event_work
    
    Fixes: 0c5fcf9e249e ("IPv6: Add "offload failed" indication to routes")
    Fixes: bb3c4ab93e44 ("ipv6: Add "offload" and "trap" indications to routes")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Amit Cohen <[email protected]>
    Cc: Ido Schimmel <[email protected]>
    Reported-by: syzbot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ipv6: mcast: use rcu-safe version of ipv6_get_lladdr() [+ + +]
Author: Ignat Korchagin <[email protected]>
Date:   Fri Feb 11 17:30:42 2022 +0000

    ipv6: mcast: use rcu-safe version of ipv6_get_lladdr()
    
    commit 26394fc118d6115390bd5b3a0fb17096271da227 upstream.
    
    Some time ago 8965779d2c0e ("ipv6,mcast: always hold idev->lock before mca_lock")
    switched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafe
    version. That was OK, because idev->lock was held for these codepaths.
    
    In 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks were
    removed, so we probably need to restore the original rcu-safe call.
    
    Otherwise, we occasionally get a machine crashed/stalled with the following
    in dmesg:
    
    [ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI
    [ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G           O      5.15.19-cloudflare-2022.2.1 #1
    [ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV
    [ 3406.009552][T230589] Workqueue: mld mld_ifc_work
    [ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60
    [ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b
    [ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202
    [ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040
    [ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008
    [ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000
    [ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100
    [ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000
    [ 3406.125730][T230589] FS:  0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000
    [ 3406.138992][T230589] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0
    [ 3406.162421][T230589] Call Trace:
    [ 3406.170235][T230589]  <TASK>
    [ 3406.177736][T230589]  mld_newpack+0xfe/0x1a0
    [ 3406.186686][T230589]  add_grhead+0x87/0xa0
    [ 3406.195498][T230589]  add_grec+0x485/0x4e0
    [ 3406.204310][T230589]  ? newidle_balance+0x126/0x3f0
    [ 3406.214024][T230589]  mld_ifc_work+0x15d/0x450
    [ 3406.223279][T230589]  process_one_work+0x1e6/0x380
    [ 3406.232982][T230589]  worker_thread+0x50/0x3a0
    [ 3406.242371][T230589]  ? rescuer_thread+0x360/0x360
    [ 3406.252175][T230589]  kthread+0x127/0x150
    [ 3406.261197][T230589]  ? set_kthread_struct+0x40/0x40
    [ 3406.271287][T230589]  ret_from_fork+0x22/0x30
    [ 3406.280812][T230589]  </TASK>
    [ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders]
    [ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---
    
    Fixes: 88e2ca308094 ("mld: convert ifmcaddr6 to RCU")
    Reported-by: David Pinilla Caparros <[email protected]>
    Signed-off-by: Ignat Korchagin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ipv6: per-netns exclusive flowlabel checks [+ + +]
Author: Willem de Bruijn <[email protected]>
Date:   Tue Feb 15 11:00:37 2022 -0500

    ipv6: per-netns exclusive flowlabel checks
    
    commit 0b0dff5b3b98c5c7ce848151df9da0b3cdf0cc8b upstream.
    
    Ipv6 flowlabels historically require a reservation before use.
    Optionally in exclusive mode (e.g., user-private).
    
    Commit 59c820b2317f ("ipv6: elide flowlabel check if no exclusive
    leases exist") introduced a fastpath that avoids this check when no
    exclusive leases exist in the system, and thus any flowlabel use
    will be granted.
    
    That allows skipping the control operation to reserve a flowlabel
    entirely. Though with a warning if the fast path fails:
    
      This is an optimization. Robust applications still have to revert to
      requesting leases if the fast path fails due to an exclusive lease.
    
    Still, this is subtle. Better isolate network namespaces from each
    other. Flowlabels are per-netns. Also record per-netns whether
    exclusive leases are in use. Then behavior does not change based on
    activity in other netns.
    
    Changes
      v2
        - wrap in IS_ENABLED(CONFIG_IPV6) to avoid breakage if disabled
    
    Fixes: 59c820b2317f ("ipv6: elide flowlabel check if no exclusive leases exist")
    Link: https://lore.kernel.org/netdev/MWHPR2201MB1072BCCCFCE779E4094837ACD0329@MWHPR2201MB1072.namprd22.prod.outlook.com/
    Reported-by: Congyu Liu <[email protected]>
    Signed-off-by: Willem de Bruijn <[email protected]>
    Tested-by: Congyu Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
irqchip/sifive-plic: Add missing thead,c900-plic match string [+ + +]
Author: Guo Ren <[email protected]>
Date:   Sun Jan 30 21:56:34 2022 +0800

    irqchip/sifive-plic: Add missing thead,c900-plic match string
    
    [ Upstream commit 1d4df649cbb4b26d19bea38ecff4b65b10a1bbca ]
    
    The thead,c900-plic has been used in opensbi to distinguish
    PLIC [1]. Although PLICs have the same behaviors in Linux,
    they are different hardware with some custom initializing in
    firmware(opensbi).
    
    Qute opensbi patch commit-msg by Samuel:
    
      The T-HEAD PLIC implementation requires setting a delegation bit
      to allow access from S-mode. Now that the T-HEAD PLIC has its own
      compatible string, set this bit automatically from the PLIC driver,
      instead of reaching into the PLIC's MMIO space from another driver.
    
    [1]: https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6
    
    Signed-off-by: Guo Ren <[email protected]>
    Cc: Anup Patel <[email protected]>
    Cc: Marc Zyngier <[email protected]>
    Cc: Palmer Dabbelt <[email protected]>
    Cc: Samuel Holland <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Tested-by: Samuel Holland <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
iwlwifi: fix use-after-free [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Feb 8 11:47:30 2022 +0100

    iwlwifi: fix use-after-free
    
    commit bea2662e7818e15d7607d17d57912ac984275d94 upstream.
    
    If no firmware was present at all (or, presumably, all of the
    firmware files failed to parse), we end up unbinding by calling
    device_release_driver(), which calls remove(), which then in
    iwlwifi calls iwl_drv_stop(), freeing the 'drv' struct. However
    the new code I added will still erroneously access it after it
    was freed.
    
    Set 'failure=false' in this case to avoid the access, all data
    was already freed anyway.
    
    Cc: [email protected]
    Reported-by: Stefan Agner <[email protected]>
    Reported-by: Wolfgang Walter <[email protected]>
    Reported-by: Jason Self <[email protected]>
    Reported-by: Dominik Behr <[email protected]>
    Reported-by: Marek Marczykowski-Górecki <[email protected]>
    Fixes: ab07506b0454 ("iwlwifi: fix leaks/bad data after failed firmware load")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/20220208114728.e6b514cf4c85.Iffb575ca2a623d7859b542c33b2a507d01554251@changeid
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iwlwifi: mvm: don't send SAR GEO command for 3160 devices [+ + +]
Author: Luca Coelho <[email protected]>
Date:   Fri Jan 28 14:48:51 2022 +0200

    iwlwifi: mvm: don't send SAR GEO command for 3160 devices
    
    commit 5f06f6bf8d816578c390a2b8a485d40adcca4749 upstream.
    
    SAR GEO offsets are not supported on 3160 devices.  The code was
    refactored and caused us to start sending the command anyway, which
    causes a FW assertion failure.  Fix that only considering this feature
    supported on FW API with major version is 17 if the device is not
    3160.
    
    Additionally, fix the caller of iwl_mvm_sar_geo_init() so that it
    checks for the return value, which it was ignoring.
    
    Reported-by: Len Brown <[email protected]>
    Signed-off-by: Luca Coelho <[email protected]>
    Fixes: 78a19d5285d9 ("iwlwifi: mvm: Read the PPAG and SAR tables at INIT stage")
    Signed-off-by: Luca Coelho <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/iwlwifi.20220128144623.96f683a89b42.I14e2985bfd7ddd8a8d83eb1869b800c0e7f30db4@changeid
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iwlwifi: pcie: fix locking when "HW not ready" [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Fri Jan 28 14:30:52 2022 +0200

    iwlwifi: pcie: fix locking when "HW not ready"
    
    commit e9848aed147708a06193b40d78493b0ef6abccf2 upstream.
    
    If we run into this error path, we shouldn't unlock the mutex
    since it's not locked since. Fix this.
    
    Fixes: a6bd005fe92d ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Luca Coelho <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/iwlwifi.20220128142706.5d16821d1433.Id259699ddf9806459856d6aefbdbe54477aecffd@changeid
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iwlwifi: pcie: gen2: fix locking when "HW not ready" [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Fri Jan 28 14:30:53 2022 +0200

    iwlwifi: pcie: gen2: fix locking when "HW not ready"
    
    commit 4c29c1e27a1e178a219b3877d055e6dd643bdfda upstream.
    
    If we run into this error path, we shouldn't unlock the mutex
    since it's not locked since. Fix this in the gen2 code as well.
    
    Fixes: eda50cde58de ("iwlwifi: pcie: add context information support")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Luca Coelho <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/iwlwifi.20220128142706.b8b0dfce16ef.Ie20f0f7b23e5911350a2766524300d2915e7b677@changeid
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kconfig: fix failing to generate auto.conf [+ + +]
Author: Jing Leng <[email protected]>
Date:   Fri Feb 11 17:27:36 2022 +0800

    kconfig: fix failing to generate auto.conf
    
    [ Upstream commit 1b9e740a81f91ae338b29ed70455719804957b80 ]
    
    When the KCONFIG_AUTOCONFIG is specified (e.g. export \
    KCONFIG_AUTOCONFIG=output/config/auto.conf), the directory of
    include/config/ will not be created, so kconfig can't create deps
    files in it and auto.conf can't be generated.
    
    Signed-off-by: Jing Leng <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kconfig: let 'shell' return enough output for deep path names [+ + +]
Author: Brenda Streiff <[email protected]>
Date:   Fri Jan 28 16:01:28 2022 -0600

    kconfig: let 'shell' return enough output for deep path names
    
    [ Upstream commit 8a4c5b2a6d8ea079fa36034e8167de87ab6f8880 ]
    
    The 'shell' built-in only returns the first 256 bytes of the command's
    output. In some cases, 'shell' is used to return a path; by bumping up
    the buffer size to 4096 this lets us capture up to PATH_MAX.
    
    The specific case where I ran into this was due to commit 1e860048c53e
    ("gcc-plugins: simplify GCC plugin-dev capability test"). After this
    change, we now use `$(shell,$(CC) -print-file-name=plugin)` to return
    a path; if the gcc path is particularly long, then the path ends up
    truncated at the 256 byte mark, which makes the HAVE_GCC_PLUGINS
    depends test always fail.
    
    Signed-off-by: Brenda Streiff <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kselftest: Fix vdso_test_abi return status [+ + +]
Author: Vincenzo Frascino <[email protected]>
Date:   Mon Jan 31 11:34:05 2022 +0000

    kselftest: Fix vdso_test_abi return status
    
    [ Upstream commit ec049891b2dc16591813eacaddc476b3d27c8c14 ]
    
    vdso_test_abi contains a batch of tests that verify the validity of the
    vDSO ABI.
    
    When a vDSO symbol is not found the relevant test is skipped reporting
    KSFT_SKIP. All the tests return values are then added in a single
    variable which is checked to verify failures. This approach can have
    side effects which result in reporting the wrong kselftest exit status.
    
    Fix vdso_test_abi verifying the return code of each test separately.
    
    Cc: Shuah Khan <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Reported-by: Cristian Marussi <[email protected]>
    Signed-off-by: Vincenzo Frascino <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kselftest: signal all child processes [+ + +]
Author: Li Zhijian <[email protected]>
Date:   Fri Dec 17 17:29:55 2021 +0800

    kselftest: signal all child processes
    
    [ Upstream commit 92d25637a3a45904292c93f1863c6bbda4e3e38f ]
    
    We have some many cases that will create child process as well, such as
    pidfd_wait. Previously, we will signal/kill the parent process when it
    is time out, but this signal will not be sent to its child process. In
    such case, if child process doesn't terminate itself, ksefltest framework
    will hang forever.
    
    Here we group all its child processes so that kill() can signal all of
    them in timeout.
    
    Fixed change log: Shuah Khan <[email protected]>
    
    Suggested-by: yang xu <[email protected]>
    Signed-off-by: Li Zhijian <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ksmbd: don't align last entry offset in smb2 query directory [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Sun Jan 30 18:31:01 2022 +0900

    ksmbd: don't align last entry offset in smb2 query directory
    
    [ Upstream commit 04e260948a160d3b7d622bf4c8a96fa4577c09bd ]
    
    When checking smb2 query directory packets from other servers,
    OutputBufferLength is different with ksmbd. Other servers add an unaligned
    next offset to OutputBufferLength for the last entry.
    
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ksmbd: fix same UniqueId for dot and dotdot entries [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Sun Jan 30 18:28:56 2022 +0900

    ksmbd: fix same UniqueId for dot and dotdot entries
    
    [ Upstream commit 97550c7478a2da93e348d8c3075d92cddd473a78 ]
    
    ksmbd sets the inode number to UniqueId. However, the same UniqueId for
    dot and dotdot entry is set to the inode number of the parent inode.
    This patch set them using the current inode and parent inode.
    
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kunit: tool: Import missing importlib.abc [+ + +]
Author: Michał Winiarski <[email protected]>
Date:   Thu Jan 13 00:36:57 2022 +0100

    kunit: tool: Import missing importlib.abc
    
    [ Upstream commit 235528072f28b3b0a1446279b7eaddda36dbf743 ]
    
    Python 3.10.0 contains:
    9e09849d20 ("bpo-41006: importlib.util no longer imports typing (GH-20938)")
    
    It causes importlib.util to no longer import importlib.abs, which leads
    to the following error when trying to use kunit with qemu:
    AttributeError: module 'importlib' has no attribute 'abc'. Did you mean: '_abc'?
    
    Add the missing import.
    
    Signed-off-by: Michał Winiarski <[email protected]>
    Reviewed-by: Daniel Latypov <[email protected]>
    Reviewed-by: Brendan Higgins <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: x86/pmu: Don't truncate the PerfEvtSeln MSR when creating a perf event [+ + +]
Author: Jim Mattson <[email protected]>
Date:   Wed Feb 2 17:48:12 2022 -0800

    KVM: x86/pmu: Don't truncate the PerfEvtSeln MSR when creating a perf event
    
    [ Upstream commit b8bfee85f1307426e0242d654f3a14c06ef639c5 ]
    
    AMD's event select is 3 nybbles, with the high nybble in bits 35:32 of
    a PerfEvtSeln MSR. Don't drop the high nybble when setting up the
    config field of a perf_event_attr structure for a call to
    perf_event_create_kernel_counter().
    
    Fixes: ca724305a2b0 ("KVM: x86/vPMU: Implement AMD vPMU code for KVM")
    Reported-by: Stephane Eranian <[email protected]>
    Signed-off-by: Jim Mattson <[email protected]>
    Message-Id: <[email protected]>
    Reviewed-by: David Dunn <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: x86/pmu: Refactoring find_arch_event() to pmc_perf_hw_id() [+ + +]
Author: Like Xu <[email protected]>
Date:   Tue Nov 30 15:42:17 2021 +0800

    KVM: x86/pmu: Refactoring find_arch_event() to pmc_perf_hw_id()
    
    [ Upstream commit 7c174f305cbee6bdba5018aae02b84369e7ab995 ]
    
    The find_arch_event() returns a "unsigned int" value,
    which is used by the pmc_reprogram_counter() to
    program a PERF_TYPE_HARDWARE type perf_event.
    
    The returned value is actually the kernel defined generic
    perf_hw_id, let's rename it to pmc_perf_hw_id() with simpler
    incoming parameters for better self-explanation.
    
    Signed-off-by: Like Xu <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: x86/pmu: Use AMD64_RAW_EVENT_MASK for PERF_TYPE_RAW [+ + +]
Author: Jim Mattson <[email protected]>
Date:   Wed Feb 2 17:48:13 2022 -0800

    KVM: x86/pmu: Use AMD64_RAW_EVENT_MASK for PERF_TYPE_RAW
    
    [ Upstream commit 710c476514313c74045c41c0571bb5178fd16e3d ]
    
    AMD's event select is 3 nybbles, with the high nybble in bits 35:32 of
    a PerfEvtSeln MSR. Don't mask off the high nybble when configuring a
    RAW perf event.
    
    Fixes: ca724305a2b0 ("KVM: x86/vPMU: Implement AMD vPMU code for KVM")
    Signed-off-by: Jim Mattson <[email protected]>
    Message-Id: <[email protected]>
    Reviewed-by: David Dunn <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: x86/xen: Fix runstate updates to be atomic when preempting vCPU [+ + +]
Author: David Woodhouse <[email protected]>
Date:   Mon Oct 25 14:29:01 2021 +0100

    KVM: x86/xen: Fix runstate updates to be atomic when preempting vCPU
    
    commit fcb732d8f8cf6084f8480015ad41d25fb023a4dd upstream.
    
    There are circumstances whem kvm_xen_update_runstate_guest() should not
    sleep because it ends up being called from __schedule() when the vCPU
    is preempted:
    
    [  222.830825]  kvm_xen_update_runstate_guest+0x24/0x100
    [  222.830878]  kvm_arch_vcpu_put+0x14c/0x200
    [  222.830920]  kvm_sched_out+0x30/0x40
    [  222.830960]  __schedule+0x55c/0x9f0
    
    To handle this, make it use the same trick as __kvm_xen_has_interrupt(),
    of using the hva from the gfn_to_hva_cache directly. Then it can use
    pagefault_disable() around the accesses and just bail out if the page
    is absent (which is unlikely).
    
    I almost switched to using a gfn_to_pfn_cache here and bailing out if
    kvm_map_gfn() fails, like kvm_steal_time_set_preempted() does — but on
    closer inspection it looks like kvm_map_gfn() will *always* fail in
    atomic context for a page in IOMEM, which means it will silently fail
    to make the update every single time for such guests, AFAICT. So I
    didn't do it that way after all. And will probably fix that one too.
    
    Cc: [email protected]
    Fixes: 30b5c851af79 ("KVM: x86/xen: Add support for vCPU runstate information")
    Signed-off-by: David Woodhouse <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: nSVM/nVMX: set nested_run_pending on VM entry which is a result of RSM [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Mon Feb 7 17:54:21 2022 +0200

    KVM: x86: nSVM/nVMX: set nested_run_pending on VM entry which is a result of RSM
    
    commit 759cbd59674a6c0aec616a3f4f0740ebd3f5fbef upstream.
    
    While RSM induced VM entries are not full VM entries,
    they still need to be followed by actual VM entry to complete it,
    unlike setting the nested state.
    
    This patch fixes boot of hyperv and SMM enabled
    windows VM running nested on KVM, which fail due
    to this issue combined with lack of dirty bit setting.
    
    Signed-off-by: Maxim Levitsky <[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: x86: nSVM: fix potential NULL derefernce on nested migration [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Mon Feb 7 17:54:19 2022 +0200

    KVM: x86: nSVM: fix potential NULL derefernce on nested migration
    
    commit e1779c2714c3023e4629825762bcbc43a3b943df upstream.
    
    Turns out that due to review feedback and/or rebases
    I accidentally moved the call to nested_svm_load_cr3 to be too early,
    before the NPT is enabled, which is very wrong to do.
    
    KVM can't even access guest memory at that point as nested NPT
    is needed for that, and of course it won't initialize the walk_mmu,
    which is main issue the patch was addressing.
    
    Fix this for real.
    
    Fixes: 232f75d3b4b5 ("KVM: nSVM: call nested_svm_load_cr3 on nested state load")
    Cc: [email protected]
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: nSVM: mark vmcb01 as dirty when restoring SMM saved state [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Mon Feb 7 17:54:20 2022 +0200

    KVM: x86: nSVM: mark vmcb01 as dirty when restoring SMM saved state
    
    commit e8efa4ff00374d2e6f47f6e4628ca3b541c001af upstream.
    
    While usually, restoring the smm state makes the KVM enter
    the nested guest thus a different vmcb (vmcb02 vs vmcb01),
    KVM should still mark it as dirty, since hardware
    can in theory cache multiple vmcbs.
    
    Failure to do so, combined with lack of setting the
    nested_run_pending (which is fixed in the next patch),
    might make KVM re-enter vmcb01, which was just exited from,
    with completely different set of guest state registers
    (SMM vs non SMM) and without proper dirty bits set,
    which results in the CPU reusing stale IDTR pointer
    which leads to a guest shutdown on any interrupt.
    
    On the real hardware this usually doesn't happen,
    but when running nested, L0's KVM does check and
    honour few dirty bits, causing this issue to happen.
    
    This patch fixes boot of hyperv and SMM enabled
    windows VM running nested on KVM.
    
    Signed-off-by: Maxim Levitsky <[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: x86: SVM: don't passthrough SMAP/SMEP/PKE bits in !NPT && !gCR0.PG case [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Mon Feb 7 17:54:18 2022 +0200

    KVM: x86: SVM: don't passthrough SMAP/SMEP/PKE bits in !NPT && !gCR0.PG case
    
    commit c53bbe2145f51d3bc0438c2db02e737b9b598bf3 upstream.
    
    When the guest doesn't enable paging, and NPT/EPT is disabled, we
    use guest't paging CR3's as KVM's shadow paging pointer and
    we are technically in direct mode as if we were to use NPT/EPT.
    
    In direct mode we create SPTEs with user mode permissions
    because usually in the direct mode the NPT/EPT doesn't
    need to restrict access based on guest CPL
    (there are MBE/GMET extenstions for that but KVM doesn't use them).
    
    In this special "use guest paging as direct" mode however,
    and if CR4.SMAP/CR4.SMEP are enabled, that will make the CPU
    fault on each access and KVM will enter endless loop of page faults.
    
    Since page protection doesn't have any meaning in !PG case,
    just don't passthrough these bits.
    
    The fix is the same as was done for VMX in commit:
    commit 656ec4a4928a ("KVM: VMX: fix SMEP and SMAP without EPT")
    
    This fixes the boot of windows 10 without NPT for good.
    (Without this patch, BSP boots, but APs were stuck in endless
    loop of page faults, causing the VM boot with 1 CPU)
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Cc: [email protected]
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lib/iov_iter: initialize "flags" in new pipe_buffer [+ + +]
Author: Max Kellermann <[email protected]>
Date:   Mon Feb 21 11:03:13 2022 +0100

    lib/iov_iter: initialize "flags" in new pipe_buffer
    
    commit 9d2231c5d74e13b2a0546fee6737ee4446017903 upstream.
    
    The functions copy_page_to_iter_pipe() and push_pipe() can both
    allocate a new pipe_buffer, but the "flags" member initializer is
    missing.
    
    Fixes: 241699cd72a8 ("new iov_iter flavour: pipe-backed")
    To: Alexander Viro <[email protected]>
    To: [email protected]
    To: [email protected]
    Cc: [email protected]
    Signed-off-by: Max Kellermann <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
libsubcmd: Fix use-after-free for realloc(..., 0) [+ + +]
Author: Kees Cook <[email protected]>
Date:   Sun Feb 13 10:24:43 2022 -0800

    libsubcmd: Fix use-after-free for realloc(..., 0)
    
    commit 52a9dab6d892763b2a8334a568bd4e2c1a6fde66 upstream.
    
    GCC 12 correctly reports a potential use-after-free condition in the
    xrealloc helper. Fix the warning by avoiding an implicit "free(ptr)"
    when size == 0:
    
    In file included from help.c:12:
    In function 'xrealloc',
        inlined from 'add_cmdname' at help.c:24:2: subcmd-util.h:56:23: error: pointer may be used after 'realloc' [-Werror=use-after-free]
       56 |                 ret = realloc(ptr, size);
          |                       ^~~~~~~~~~~~~~~~~~
    subcmd-util.h:52:21: note: call to 'realloc' here
       52 |         void *ret = realloc(ptr, size);
          |                     ^~~~~~~~~~~~~~~~~~
    subcmd-util.h:58:31: error: pointer may be used after 'realloc' [-Werror=use-after-free]
       58 |                         ret = realloc(ptr, 1);
          |                               ^~~~~~~~~~~~~~~
    subcmd-util.h:52:21: note: call to 'realloc' here
       52 |         void *ret = realloc(ptr, size);
          |                     ^~~~~~~~~~~~~~~~~~
    
    Fixes: 2f4ce5ec1d447beb ("perf tools: Finalize subcmd independence")
    Reported-by: Valdis Klētnieks <[email protected]>
    Signed-off-by: Kees Kook <[email protected]>
    Tested-by: Valdis Klētnieks <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Acked-by: Josh Poimboeuf <[email protected]>
    Cc: [email protected]
    Cc: Valdis Klētnieks <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 5.15.25 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Feb 23 12:03:22 2022 +0100

    Linux 5.15.25
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Slade Watkins <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lockdep: Correct lock_classes index mapping [+ + +]
Author: Cheng Jui Wang <[email protected]>
Date:   Thu Feb 10 18:50:11 2022 +0800

    lockdep: Correct lock_classes index mapping
    
    commit 28df029d53a2fd80c1b8674d47895648ad26dcfb upstream.
    
    A kernel exception was hit when trying to dump /proc/lockdep_chains after
    lockdep report "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!":
    
    Unable to handle kernel paging request at virtual address 00054005450e05c3
    ...
    00054005450e05c3] address between user and kernel address ranges
    ...
    pc : [0xffffffece769b3a8] string+0x50/0x10c
    lr : [0xffffffece769ac88] vsnprintf+0x468/0x69c
    ...
     Call trace:
      string+0x50/0x10c
      vsnprintf+0x468/0x69c
      seq_printf+0x8c/0xd8
      print_name+0x64/0xf4
      lc_show+0xb8/0x128
      seq_read_iter+0x3cc/0x5fc
      proc_reg_read_iter+0xdc/0x1d4
    
    The cause of the problem is the function lock_chain_get_class() will
    shift lock_classes index by 1, but the index don't need to be shifted
    anymore since commit 01bb6f0af992 ("locking/lockdep: Change the range
    of class_idx in held_lock struct") already change the index to start
    from 0.
    
    The lock_classes[-1] located at chain_hlocks array. When printing
    lock_classes[-1] after the chain_hlocks entries are modified, the
    exception happened.
    
    The output of lockdep_chains are incorrect due to this problem too.
    
    Fixes: f611e8cf98ec ("lockdep: Take read/write status in consideration when generate chainkey")
    Signed-off-by: Cheng Jui Wang <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Boqun Feng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mac80211: mlme: check for null after calling kmemdup [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Wed Jan 5 16:15:59 2022 +0800

    mac80211: mlme: check for null after calling kmemdup
    
    commit a72c01a94f1d285a274219d36e2a17b4846c0615 upstream.
    
    As the possible failure of the alloc, the ifmgd->assoc_req_ies might be
    NULL pointer returned from kmemdup().
    Therefore it might be better to free the skb and return error in order
    to fail the association, like ieee80211_assoc_success().
    Also, the caller, ieee80211_do_assoc(), needs to deal with the return
    value from ieee80211_send_assoc().
    
    Fixes: 4d9ec73d2b78 ("cfg80211: Report Association Request frame IEs in association events")
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [fix some paths to be errors, not success]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: don't try to NUMA-migrate COW pages that have other uses [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Thu Feb 17 08:57:47 2022 -0800

    mm: don't try to NUMA-migrate COW pages that have other uses
    
    commit 80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6 upstream.
    
    Oded Gabbay reports that enabling NUMA balancing causes corruption with
    his Gaudi accelerator test load:
    
     "All the details are in the bug, but the bottom line is that somehow,
      this patch causes corruption when the numa balancing feature is
      enabled AND we don't use process affinity AND we use GUP to pin pages
      so our accelerator can DMA to/from system memory.
    
      Either disabling numa balancing, using process affinity to bind to
      specific numa-node or reverting this patch causes the bug to
      disappear"
    
    and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page()
    simplification").
    
    Now, the NUMA balancing shouldn't actually be changing the writability
    of a page, and as such shouldn't matter for COW.  But it appears it
    does.  Suspicious.
    
    However, regardless of that, the condition for enabling NUMA faults in
    change_pte_range() is nonsensical.  It uses "page_mapcount(page)" to
    decide if a COW page should be NUMA-protected or not, and that makes
    absolutely no sense.
    
    The number of mappings a page has is irrelevant: not only does GUP get a
    reference to a page as in Oded's case, but the other mappings migth be
    paged out and the only reference to them would be in the page count.
    
    Since we should never try to NUMA-balance a page that we can't move
    anyway due to other references, just fix the code to use 'page_count()'.
    Oded confirms that that fixes his issue.
    
    Now, this does imply that something in NUMA balancing ends up changing
    page protections (other than the obvious one of making the page
    inaccessible to get the NUMA faulting information).  Otherwise the COW
    simplification wouldn't matter - since doing the GUP on the page would
    make sure it's writable.
    
    The cause of that permission change would be good to figure out too,
    since it clearly results in spurious COW events - but fixing the
    nonsensical test that just happened to work before is obviously the
    CorrectThing(tm) to do regardless.
    
    Fixes: 09854ba94c6a ("mm: do_wp_page() simplification")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215616
    Link: https://lore.kernel.org/all/CAFCwf10eNmwq2wD71xjUhqkvv5+_pJMR1nPug2RqNDcFT4H86Q@mail.gmail.com/
    Reported-and-tested-by: Oded Gabbay <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Peter Xu <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm: io_uring: allow oom-killer from io_uring_setup [+ + +]
Author: Shakeel Butt <[email protected]>
Date:   Mon Jan 24 21:17:36 2022 -0800

    mm: io_uring: allow oom-killer from io_uring_setup
    
    [ Upstream commit 0a3f1e0beacf6cc8ae5f846b0641c1df476e83d6 ]
    
    On an overcommitted system which is running multiple workloads of
    varying priorities, it is preferred to trigger an oom-killer to kill a
    low priority workload than to let the high priority workload receiving
    ENOMEMs. On our memory overcommitted systems, we are seeing a lot of
    ENOMEMs instead of oom-kills because io_uring_setup callchain is using
    __GFP_NORETRY gfp flag which avoids the oom-killer. Let's remove it and
    allow the oom-killer to kill a lower priority job.
    
    Signed-off-by: Shakeel Butt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mmc: block: fix read single on recovery logic [+ + +]
Author: Christian Löhle <[email protected]>
Date:   Fri Feb 4 15:11:37 2022 +0000

    mmc: block: fix read single on recovery logic
    
    commit 54309fde1a352ad2674ebba004a79f7d20b9f037 upstream.
    
    On reads with MMC_READ_MULTIPLE_BLOCK that fail,
    the recovery handler will use MMC_READ_SINGLE_BLOCK for
    each of the blocks, up to MMC_READ_SINGLE_RETRIES times each.
    The logic for this is fixed to never report unsuccessful reads
    as success to the block layer.
    
    On command error with retries remaining, blk_update_request was
    called with whatever value error was set last to.
    In case it was last set to BLK_STS_OK (default), the read will be
    reported as success, even though there was no data read from the device.
    This could happen on a CRC mismatch for the response,
    a card rejecting the command (e.g. again due to a CRC mismatch).
    In case it was last set to BLK_STS_IOERR, the error is reported correctly,
    but no retries will be attempted.
    
    Fixes: 81196976ed946c ("mmc: block: Add blk-mq support")
    Cc: [email protected]
    Signed-off-by: Christian Loehle <[email protected]>
    Reviewed-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]>

 
mtd: parsers: qcom: Fix kernel panic on skipped partition [+ + +]
Author: Ansuel Smith <[email protected]>
Date:   Sun Jan 16 04:22:10 2022 +0100

    mtd: parsers: qcom: Fix kernel panic on skipped partition
    
    commit 65d003cca335cabc0160d3cd7daa689eaa9dd3cd upstream.
    
    In the event of a skipped partition (case when the entry name is empty)
    the kernel panics in the cleanup function as the name entry is NULL.
    Rework the parser logic by first checking the real partition number and
    then allocate the space and set the data for the valid partitions.
    
    The logic was also fundamentally wrong as with a skipped partition, the
    parts number returned was incorrect by not decreasing it for the skipped
    partitions.
    
    Fixes: 803eb124e1a6 ("mtd: parsers: Add Qcom SMEM parser")
    Signed-off-by: Ansuel Smith <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtd: parsers: qcom: Fix missing free for pparts in cleanup [+ + +]
Author: Ansuel Smith <[email protected]>
Date:   Sun Jan 16 04:22:11 2022 +0100

    mtd: parsers: qcom: Fix missing free for pparts in cleanup
    
    commit 3dd8ba961b9356c4113b96541c752c73d98fef70 upstream.
    
    Mtdpart doesn't free pparts when a cleanup function is declared.
    Add missing free for pparts in cleanup function for smem to fix the
    leak.
    
    Fixes: 10f3b4d79958 ("mtd: parsers: qcom: Fix leaking of partition name")
    Signed-off-by: Ansuel Smith <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtd: phram: Prevent divide by zero bug in phram_setup() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Jan 21 14:55:05 2022 +0300

    mtd: phram: Prevent divide by zero bug in phram_setup()
    
    commit 3e3765875b1b8864898603768fd5c93eeb552211 upstream.
    
    The problem is that "erasesize" is a uint64_t type so it might be
    non-zero but the lower 32 bits are zero so when it's truncated,
    "(uint32_t)erasesize", then that value is zero. This leads to a
    divide by zero bug.
    
    Avoid the bug by delaying the divide until after we have validated
    that "erasesize" is non-zero and within the uint32_t range.
    
    Fixes: dc2b3e5cbc80 ("mtd: phram: use div_u64_rem to stop overwrite len in phram_setup")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/20220121115505.GI1978@kadam
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status [+ + +]
Author: david regan <[email protected]>
Date:   Wed Jan 26 23:43:44 2022 +0100

    mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status
    
    commit 36415a7964711822e63695ea67fede63979054d9 upstream.
    
    The brcmnand driver contains a bug in which if a page (example 2k byte)
    is read from the parallel/ONFI NAND and within that page a subpage (512
    byte) has correctable errors which is followed by a subpage with
    uncorrectable errors, the page read will return the wrong status of
    correctable (as opposed to the actual status of uncorrectable.)
    
    The bug is in function brcmnand_read_by_pio where there is a check for
    uncorrectable bits which will be preempted if a previous status for
    correctable bits is detected.
    
    The fix is to stop checking for bad bits only if we already have a bad
    bits status.
    
    Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
    Signed-off-by: david regan <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/trinity-478e0c09-9134-40e8-8f8c-31c371225eda-1643237024774@3c-app-mailcom-lxa02
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtd: rawnand: gpmi: don't leak PM reference in error path [+ + +]
Author: Christian Eggers <[email protected]>
Date:   Tue Jan 25 09:16:19 2022 +0100

    mtd: rawnand: gpmi: don't leak PM reference in error path
    
    commit 9161f365c91614e5a3f5c6dcc44c3b1b33bc59c0 upstream.
    
    If gpmi_nfc_apply_timings() fails, the PM runtime usage counter must be
    dropped.
    
    Reported-by: Pavel Machek <[email protected]>
    Fixes: f53d4c109a66 ("mtd: rawnand: gpmi: Add ERR007117 protection for nfc_apply_timings")
    Signed-off-by: Christian Eggers <[email protected]>
    Cc: [email protected]
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtd: rawnand: ingenic: Fix missing put_device in ingenic_ecc_get [+ + +]
Author: Miaoqian Lin <[email protected]>
Date:   Thu Dec 30 07:27:51 2021 +0000

    mtd: rawnand: ingenic: Fix missing put_device in ingenic_ecc_get
    
    [ Upstream commit ba1b71b008e97fd747845ff3a818420b11bbe830 ]
    
    If of_find_device_by_node() succeeds, ingenic_ecc_get() doesn't have
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling.
    
    Fixes: 15de8c6efd0e ("mtd: rawnand: ingenic: Separate top-level and SoC specific code")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Paul Cercueil <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: qcom: Fix clock sequencing in qcom_nandc_probe() [+ + +]
Author: Bryan O'Donoghue <[email protected]>
Date:   Mon Jan 3 03:03:15 2022 +0000

    mtd: rawnand: qcom: Fix clock sequencing in qcom_nandc_probe()
    
    commit 5c23b3f965bc9ee696bf2ed4bdc54d339dd9a455 upstream.
    
    Interacting with a NAND chip on an IPQ6018 I found that the qcomsmem NAND
    partition parser was returning -EPROBE_DEFER waiting for the main smem
    driver to load.
    
    This caused the board to reset. Playing about with the probe() function
    shows that the problem lies in the core clock being switched off before the
    nandc_unalloc() routine has completed.
    
    If we look at how qcom_nandc_remove() tears down allocated resources we see
    the expected order is
    
    qcom_nandc_unalloc(nandc);
    
    clk_disable_unprepare(nandc->aon_clk);
    clk_disable_unprepare(nandc->core_clk);
    
    dma_unmap_resource(&pdev->dev, nandc->base_dma, resource_size(res),
                       DMA_BIDIRECTIONAL, 0);
    
    Tweaking probe() to both bring up and tear-down in that order removes the
    reset if we end up deferring elsewhere.
    
    Fixes: c76b78d8ec05 ("mtd: nand: Qualcomm NAND controller driver")
    Signed-off-by: Bryan O'Donoghue <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/smc: Avoid overwriting the copies of clcsock callback functions [+ + +]
Author: Wen Gu <[email protected]>
Date:   Wed Feb 9 22:10:53 2022 +0800

    net/smc: Avoid overwriting the copies of clcsock callback functions
    
    commit 1de9770d121ee9294794cca0e0be8fbfa0134ee8 upstream.
    
    The callback functions of clcsock will be saved and replaced during
    the fallback. But if the fallback happens more than once, then the
    copies of these callback functions will be overwritten incorrectly,
    resulting in a loop call issue:
    
    clcsk->sk_error_report
     |- smc_fback_error_report() <------------------------------|
         |- smc_fback_forward_wakeup()                          | (loop)
             |- clcsock_callback()  (incorrectly overwritten)   |
                 |- smc->clcsk_error_report() ------------------|
    
    So this patch fixes the issue by saving these function pointers only
    once in the fallback and avoiding overwriting.
    
    Reported-by: [email protected]
    Fixes: 341adeec9ada ("net/smc: Forward wakeup to smc socket waitqueue after fallback")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wen Gu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net: bridge: multicast: notify switchdev driver whenever MC processing gets disabled [+ + +]
Author: Oleksandr Mazur <[email protected]>
Date:   Tue Feb 15 18:53:03 2022 +0200

    net: bridge: multicast: notify switchdev driver whenever MC processing gets disabled
    
    commit c832962ac972082b3a1f89775c9d4274c8cb5670 upstream.
    
    Whenever bridge driver hits the max capacity of MDBs, it disables
    the MC processing (by setting corresponding bridge option), but never
    notifies switchdev about such change (the notifiers are called only upon
    explicit setting of this option, through the registered netlink interface).
    
    This could lead to situation when Software MDB processing gets disabled,
    but this event never gets offloaded to the underlying Hardware.
    
    Fix this by adding a notify message in such case.
    
    Fixes: 147c1e9b902c ("switchdev: bridge: Offload multicast disabled")
    Signed-off-by: Oleksandr Mazur <[email protected]>
    Acked-by: Nikolay Aleksandrov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: lan9303: add VLAN IDs to master device [+ + +]
Author: Mans Rullgard <[email protected]>
Date:   Wed Feb 16 20:48:18 2022 +0000

    net: dsa: lan9303: add VLAN IDs to master device
    
    commit 430065e2671905ac675f97b7af240cc255964e93 upstream.
    
    If the master device does VLAN filtering, the IDs used by the switch
    must be added for any frames to be received.  Do this in the
    port_enable() function, and remove them in port_disable().
    
    Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
    Signed-off-by: Mans Rullgard <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: lan9303: fix reset on probe [+ + +]
Author: Mans Rullgard <[email protected]>
Date:   Wed Feb 9 14:54:54 2022 +0000

    net: dsa: lan9303: fix reset on probe
    
    commit 6bb9681a43f34f2cab4aad6e2a02da4ce54d13c5 upstream.
    
    The reset input to the LAN9303 chip is active low, and devicetree
    gpio handles reflect this.  Therefore, the gpio should be requested
    with an initial state of high in order for the reset signal to be
    asserted.  Other uses of the gpio already use the correct polarity.
    
    Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
    Signed-off-by: Mans Rullgard <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Reviewed-by: Florian Fianelil <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: lan9303: handle hwaccel VLAN tags [+ + +]
Author: Mans Rullgard <[email protected]>
Date:   Wed Feb 16 12:46:34 2022 +0000

    net: dsa: lan9303: handle hwaccel VLAN tags
    
    commit 017b355bbdc6620fd8fe05fe297f553ce9d855ee upstream.
    
    Check for a hwaccel VLAN tag on rx and use it if present.  Otherwise,
    use __skb_vlan_pop() like the other tag parsers do.  This fixes the case
    where the VLAN tag has already been consumed by the master.
    
    Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
    Signed-off-by: Mans Rullgard <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: lantiq_gswip: fix use after free in gswip_remove() [+ + +]
Author: Alexey Khoroshilov <[email protected]>
Date:   Tue Feb 15 13:42:48 2022 +0300

    net: dsa: lantiq_gswip: fix use after free in gswip_remove()
    
    commit 8c6ae46150a453f8ae9a6cd49b45f354f478587d upstream.
    
    of_node_put(priv->ds->slave_mii_bus->dev.of_node) should be
    done before mdiobus_free(priv->ds->slave_mii_bus).
    
    Signed-off-by: Alexey Khoroshilov <[email protected]>
    Fixes: 0d120dfb5d67 ("net: dsa: lantiq_gswip: don't use devres for mdiobus")
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Fri Feb 11 19:45:06 2022 +0200

    net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN
    
    commit a2614140dc0f467a83aa3bb4b6ee2d6480a76202 upstream.
    
    mv88e6xxx is special among DSA drivers in that it requires the VTU to
    contain the VID of the FDB entry it modifies in
    mv88e6xxx_port_db_load_purge(), otherwise it will return -EOPNOTSUPP.
    
    Sometimes due to races this is not always satisfied even if external
    code does everything right (first deletes the FDB entries, then the
    VLAN), because DSA commits to hardware FDB entries asynchronously since
    commit c9eb3e0f8701 ("net: dsa: Add support for learning FDB through
    notification").
    
    Therefore, the mv88e6xxx driver must close this race condition by
    itself, by asking DSA to flush the switchdev workqueue of any FDB
    deletions in progress, prior to exiting a VLAN.
    
    Fixes: c9eb3e0f8701 ("net: dsa: Add support for learning FDB through notification")
    Reported-by: Rafael Richter <[email protected]>
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: ieee802154: at86rf230: Stop leaking skb's [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Tue Jan 25 13:14:23 2022 +0100

    net: ieee802154: at86rf230: Stop leaking skb's
    
    [ Upstream commit e5ce576d45bf72fd0e3dc37eff897bfcc488f6a9 ]
    
    Upon error the ieee802154_xmit_complete() helper is not called. Only
    ieee802154_wake_queue() is called manually. In the Tx case we then leak
    the skb structure.
    
    Free the skb structure upon error before returning when appropriate.
    
    As the 'is_tx = 0' cannot be moved in the complete handler because of a
    possible race between the delay in switching to STATE_RX_AACK_ON and a
    new interrupt, we introduce an intermediate 'was_tx' boolean just for
    this purpose.
    
    There is no Fixes tag applying here, many changes have been made on this
    area and the issue kind of always existed.
    
    Suggested-by: Alexander Aring <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Acked-by: Alexander Aring <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stefan Schmidt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ieee802154: ca8210: Fix lifs/sifs periods [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Tue Feb 1 19:06:26 2022 +0100

    net: ieee802154: ca8210: Fix lifs/sifs periods
    
    commit bdc120a2bcd834e571ce4115aaddf71ab34495de upstream.
    
    These periods are expressed in time units (microseconds) while 40 and 12
    are the number of symbol durations these periods will last. We need to
    multiply them both with the symbol_duration in order to get these
    values in microseconds.
    
    Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stefan Schmidt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: macb: Align the dma and coherent dma masks [+ + +]
Author: Marc St-Amand <[email protected]>
Date:   Wed Feb 9 15:13:25 2022 +0530

    net: macb: Align the dma and coherent dma masks
    
    [ Upstream commit 37f7860602b5b2d99fc7465f6407f403f5941988 ]
    
    Single page and coherent memory blocks can use different DMA masks
    when the macb accesses physical memory directly. The kernel is clever
    enough to allocate pages that fit into the requested address width.
    
    When using the ARM SMMU, the DMA mask must be the same for single
    pages and big coherent memory blocks. Otherwise the translation
    tables turn into one big mess.
    
      [   74.959909] macb ff0e0000.ethernet eth0: DMA bus error: HRESP not OK
      [   74.959989] arm-smmu fd800000.smmu: Unhandled context fault: fsr=0x402, iova=0x3165687460, fsynr=0x20001, cbfrsynra=0x877, cb=1
      [   75.173939] macb ff0e0000.ethernet eth0: DMA bus error: HRESP not OK
      [   75.173955] arm-smmu fd800000.smmu: Unhandled context fault: fsr=0x402, iova=0x3165687460, fsynr=0x20001, cbfrsynra=0x877, cb=1
    
    Since using the same DMA mask does not hurt direct 1:1 physical
    memory mappings, this commit always aligns DMA and coherent masks.
    
    Signed-off-by: Marc St-Amand <[email protected]>
    Signed-off-by: Harini Katakam <[email protected]>
    Acked-by: Nicolas Ferre <[email protected]>
    Tested-by: Conor Dooley <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: mediatek: remove PHY mode check on MT7531 [+ + +]
Author: DENG Qingfang <[email protected]>
Date:   Wed Feb 9 22:39:47 2022 +0800

    net: phy: mediatek: remove PHY mode check on MT7531
    
    commit 525b108e6d95b643eccbd84fb10aa9aa101b18dd upstream.
    
    The function mt7531_phy_mode_supported in the DSA driver set supported
    mode to PHY_INTERFACE_MODE_GMII instead of PHY_INTERFACE_MODE_INTERNAL
    for the internal PHY, so this check breaks the PHY initialization:
    
    mt7530 mdio-bus:00 wan (uninitialized): failed to connect to PHY: -EINVAL
    
    Remove the check to make it work again.
    
    Reported-by: Hauke Mehrtens <[email protected]>
    Fixes: e40d2cca0189 ("net: phy: add MediaTek Gigabit Ethernet PHY driver")
    Signed-off-by: DENG Qingfang <[email protected]>
    Acked-by: Arınç ÜNAL <[email protected]>
    Tested-by: Hauke Mehrtens <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: sched: limit TC_ACT_REPEAT loops [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Feb 15 15:53:05 2022 -0800

    net: sched: limit TC_ACT_REPEAT loops
    
    commit 5740d068909676d4bdb5c9c00c37a83df7728909 upstream.
    
    We have been living dangerously, at the mercy of malicious users,
    abusing TC_ACT_REPEAT, as shown by this syzpot report [1].
    
    Add an arbitrary limit (32) to the number of times an action can
    return TC_ACT_REPEAT.
    
    v2: switch the limit to 32 instead of 10.
        Use net_warn_ratelimited() instead of pr_err_once().
    
    [1] (C repro available on demand)
    
    rcu: INFO: rcu_preempt self-detected stall on CPU
    rcu:    1-...!: (10500 ticks this GP) idle=021/1/0x4000000000000000 softirq=5592/5592 fqs=0
            (t=10502 jiffies g=5305 q=190)
    rcu: rcu_preempt kthread timer wakeup didn't happen for 10502 jiffies! g5305 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
    rcu:    Possible timer handling issue on cpu=0 timer-softirq=3527
    rcu: rcu_preempt kthread starved for 10505 jiffies! g5305 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
    rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
    rcu: RCU grace-period kthread stack dump:
    task:rcu_preempt     state:I stack:29344 pid:   14 ppid:     2 flags:0x00004000
    Call Trace:
     <TASK>
     context_switch kernel/sched/core.c:4986 [inline]
     __schedule+0xab2/0x4db0 kernel/sched/core.c:6295
     schedule+0xd2/0x260 kernel/sched/core.c:6368
     schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881
     rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1963
     rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2136
     kthread+0x2e9/0x3a0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
     </TASK>
    rcu: Stack dump where RCU GP kthread last ran:
    Sending NMI from CPU 1 to CPUs 0:
    NMI backtrace for cpu 0
    CPU: 0 PID: 3646 Comm: syz-executor358 Not tainted 5.17.0-rc3-syzkaller-00149-gbf8e59fd315f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:rep_nop arch/x86/include/asm/vdso/processor.h:13 [inline]
    RIP: 0010:cpu_relax arch/x86/include/asm/vdso/processor.h:18 [inline]
    RIP: 0010:pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:437 [inline]
    RIP: 0010:__pv_queued_spin_lock_slowpath+0x3b8/0xb40 kernel/locking/qspinlock.c:508
    Code: 48 89 eb c6 45 01 01 41 bc 00 80 00 00 48 c1 e9 03 83 e3 07 41 be 01 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8d 2c 01 eb 0c <f3> 90 41 83 ec 01 0f 84 72 04 00 00 41 0f b6 45 00 38 d8 7f 08 84
    RSP: 0018:ffffc9000283f1b0 EFLAGS: 00000206
    RAX: 0000000000000003 RBX: 0000000000000000 RCX: 1ffff1100fc0071e
    RDX: 0000000000000001 RSI: 0000000000000201 RDI: 0000000000000000
    RBP: ffff88807e0038f0 R08: 0000000000000001 R09: ffffffff8ffbf9ff
    R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000004c1e
    R13: ffffed100fc0071e R14: 0000000000000001 R15: ffff8880b9c3aa80
    FS:  00005555562bf300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffdbfef12b8 CR3: 00000000723c2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:591 [inline]
     queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline]
     queued_spin_lock include/asm-generic/qspinlock.h:85 [inline]
     do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:115
     spin_lock_bh include/linux/spinlock.h:354 [inline]
     sch_tree_lock include/net/sch_generic.h:610 [inline]
     sch_tree_lock include/net/sch_generic.h:605 [inline]
     prio_tune+0x3b9/0xb50 net/sched/sch_prio.c:211
     prio_init+0x5c/0x80 net/sched/sch_prio.c:244
     qdisc_create.constprop.0+0x44a/0x10f0 net/sched/sch_api.c:1253
     tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660
     rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5594
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:725
     ____sys_sendmsg+0x6e8/0x810 net/socket.c:2413
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
     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+0x44/0xae
    RIP: 0033:0x7f7ee98aae99
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 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:00007ffdbfef12d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007ffdbfef1300 RCX: 00007f7ee98aae99
    RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000003
    RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d
    R10: 000000000000000d R11: 0000000000000246 R12: 00007ffdbfef12f0
    R13: 00000000000f4240 R14: 000000000004ca47 R15: 00007ffdbfef12e4
     </TASK>
    INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.293 msecs
    NMI backtrace for cpu 1
    CPU: 1 PID: 3260 Comm: kworker/1:3 Not tainted 5.17.0-rc3-syzkaller-00149-gbf8e59fd315f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: mld mld_ifc_work
    Call Trace:
     <IRQ>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111
     nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62
     trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
     rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343
     print_cpu_stall kernel/rcu/tree_stall.h:604 [inline]
     check_cpu_stall kernel/rcu/tree_stall.h:688 [inline]
     rcu_pending kernel/rcu/tree.c:3919 [inline]
     rcu_sched_clock_irq.cold+0x5c/0x759 kernel/rcu/tree.c:2617
     update_process_times+0x16d/0x200 kernel/time/timer.c:1785
     tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226
     tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428
     __run_hrtimer kernel/time/hrtimer.c:1685 [inline]
     __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749
     hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811
     local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline]
     __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103
     sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097
     </IRQ>
     <TASK>
     asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638
    RIP: 0010:__sanitizer_cov_trace_const_cmp4+0xc/0x70 kernel/kcov.c:286
    Code: 00 00 00 48 89 7c 30 e8 48 89 4c 30 f0 4c 89 54 d8 20 48 89 10 5b c3 0f 1f 80 00 00 00 00 41 89 f8 bf 03 00 00 00 4c 8b 14 24 <89> f1 65 48 8b 34 25 00 70 02 00 e8 14 f9 ff ff 84 c0 74 4b 48 8b
    RSP: 0018:ffffc90002c5eea8 EFLAGS: 00000246
    RAX: 0000000000000007 RBX: ffff88801c625800 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
    RBP: ffff8880137d3100 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffffff874fcd88 R11: 0000000000000000 R12: ffff88801d692dc0
    R13: ffff8880137d3104 R14: 0000000000000000 R15: ffff88801d692de8
     tcf_police_act+0x358/0x11d0 net/sched/act_police.c:256
     tcf_action_exec net/sched/act_api.c:1049 [inline]
     tcf_action_exec+0x1a6/0x530 net/sched/act_api.c:1026
     tcf_exts_exec include/net/pkt_cls.h:326 [inline]
     route4_classify+0xef0/0x1400 net/sched/cls_route.c:179
     __tcf_classify net/sched/cls_api.c:1549 [inline]
     tcf_classify+0x3e8/0x9d0 net/sched/cls_api.c:1615
     prio_classify net/sched/sch_prio.c:42 [inline]
     prio_enqueue+0x3a7/0x790 net/sched/sch_prio.c:75
     dev_qdisc_enqueue+0x40/0x300 net/core/dev.c:3668
     __dev_xmit_skb net/core/dev.c:3756 [inline]
     __dev_queue_xmit+0x1f61/0x3660 net/core/dev.c:4081
     neigh_hh_output include/net/neighbour.h:533 [inline]
     neigh_output include/net/neighbour.h:547 [inline]
     ip_finish_output2+0x14dc/0x2170 net/ipv4/ip_output.c:228
     __ip_finish_output net/ipv4/ip_output.c:306 [inline]
     __ip_finish_output+0x396/0x650 net/ipv4/ip_output.c:288
     ip_finish_output+0x32/0x200 net/ipv4/ip_output.c:316
     NF_HOOK_COND include/linux/netfilter.h:296 [inline]
     ip_output+0x196/0x310 net/ipv4/ip_output.c:430
     dst_output include/net/dst.h:451 [inline]
     ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:126
     iptunnel_xmit+0x628/0xa50 net/ipv4/ip_tunnel_core.c:82
     geneve_xmit_skb drivers/net/geneve.c:966 [inline]
     geneve_xmit+0x10c8/0x3530 drivers/net/geneve.c:1077
     __netdev_start_xmit include/linux/netdevice.h:4683 [inline]
     netdev_start_xmit include/linux/netdevice.h:4697 [inline]
     xmit_one net/core/dev.c:3473 [inline]
     dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3489
     __dev_queue_xmit+0x2985/0x3660 net/core/dev.c:4116
     neigh_hh_output include/net/neighbour.h:533 [inline]
     neigh_output include/net/neighbour.h:547 [inline]
     ip6_finish_output2+0xf7a/0x14f0 net/ipv6/ip6_output.c:126
     __ip6_finish_output net/ipv6/ip6_output.c:191 [inline]
     __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170
     ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201
     NF_HOOK_COND include/linux/netfilter.h:296 [inline]
     ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224
     dst_output include/net/dst.h:451 [inline]
     NF_HOOK include/linux/netfilter.h:307 [inline]
     NF_HOOK include/linux/netfilter.h:301 [inline]
     mld_sendpack+0x9a3/0xe40 net/ipv6/mcast.c:1826
     mld_send_cr net/ipv6/mcast.c:2127 [inline]
     mld_ifc_work+0x71c/0xdc0 net/ipv6/mcast.c:2659
     process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307
     worker_thread+0x657/0x1110 kernel/workqueue.c:2454
     kthread+0x2e9/0x3a0 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
     </TASK>
    ----------------
    Code disassembly (best guess):
       0:   48 89 eb                mov    %rbp,%rbx
       3:   c6 45 01 01             movb   $0x1,0x1(%rbp)
       7:   41 bc 00 80 00 00       mov    $0x8000,%r12d
       d:   48 c1 e9 03             shr    $0x3,%rcx
      11:   83 e3 07                and    $0x7,%ebx
      14:   41 be 01 00 00 00       mov    $0x1,%r14d
      1a:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
      21:   fc ff df
      24:   4c 8d 2c 01             lea    (%rcx,%rax,1),%r13
      28:   eb 0c                   jmp    0x36
    * 2a:   f3 90                   pause <-- trapping instruction
      2c:   41 83 ec 01             sub    $0x1,%r12d
      30:   0f 84 72 04 00 00       je     0x4a8
      36:   41 0f b6 45 00          movzbl 0x0(%r13),%eax
      3b:   38 d8                   cmp    %bl,%al
      3d:   7f 08                   jg     0x47
      3f:   84                      .byte 0x84
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Cc: Cong Wang <[email protected]>
    Cc: Jiri Pirko <[email protected]>
    Reported-by: syzbot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: sparx5: do not refer to skb after passing it on [+ + +]
Author: Steen Hegelund <[email protected]>
Date:   Wed Feb 2 09:30:39 2022 +0100

    net: sparx5: do not refer to skb after passing it on
    
    [ Upstream commit 81eb8b0b18789e647e65579303529fd52d861cc2 ]
    
    Do not try to use any SKB fields after the packet has been passed up in the
    receive stack.
    
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Steen Hegelund <[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: usb: qmi_wwan: Add support for Dell DW5829e [+ + +]
Author: Slark Xiao <[email protected]>
Date:   Wed Feb 9 10:47:17 2022 +0800

    net: usb: qmi_wwan: Add support for Dell DW5829e
    
    [ Upstream commit 8ecbb179286cbc91810c16caeb3396e06305cd0c ]
    
    Dell DW5829e same as DW5821e except the CAT level.
    DW5821e supports CAT16 but DW5829e supports CAT9.
    Also, DW5829e includes normal and eSIM type.
    Please see below test evidence:
    
    T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
    D:  Ver= 3.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=413c ProdID=81e6 Rev=03.18
    S:  Manufacturer=Dell Inc.
    S:  Product=DW5829e Snapdragon X20 LTE
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    
    T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  7 Spd=5000 MxCh= 0
    D:  Ver= 3.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=413c ProdID=81e4 Rev=03.18
    S:  Manufacturer=Dell Inc.
    S:  Product=DW5829e-eSIM Snapdragon X20 LTE
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    
    Signed-off-by: Slark Xiao <[email protected]>
    Acked-by: Bjørn Mork <[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_sched: add __rcu annotation to netdev->qdisc [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Feb 11 12:06:23 2022 -0800

    net_sched: add __rcu annotation to netdev->qdisc
    
    commit 5891cd5ec46c2c2eb6427cb54d214b149635dd0e upstream.
    
    syzbot found a data-race [1] which lead me to add __rcu
    annotations to netdev->qdisc, and proper accessors
    to get LOCKDEP support.
    
    [1]
    BUG: KCSAN: data-race in dev_activate / qdisc_lookup_rcu
    
    write to 0xffff888168ad6410 of 8 bytes by task 13559 on cpu 1:
     attach_default_qdiscs net/sched/sch_generic.c:1167 [inline]
     dev_activate+0x2ed/0x8f0 net/sched/sch_generic.c:1221
     __dev_open+0x2e9/0x3a0 net/core/dev.c:1416
     __dev_change_flags+0x167/0x3f0 net/core/dev.c:8139
     rtnl_configure_link+0xc2/0x150 net/core/rtnetlink.c:3150
     __rtnl_newlink net/core/rtnetlink.c:3489 [inline]
     rtnl_newlink+0xf4d/0x13e0 net/core/rtnetlink.c:3529
     rtnetlink_rcv_msg+0x745/0x7e0 net/core/rtnetlink.c:5594
     netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2494
     rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5612
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x602/0x6d0 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x728/0x850 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg net/socket.c:725 [inline]
     ____sys_sendmsg+0x39a/0x510 net/socket.c:2413
     ___sys_sendmsg net/socket.c:2467 [inline]
     __sys_sendmsg+0x195/0x230 net/socket.c:2496
     __do_sys_sendmsg net/socket.c:2505 [inline]
     __se_sys_sendmsg net/socket.c:2503 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2503
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff888168ad6410 of 8 bytes by task 13560 on cpu 0:
     qdisc_lookup_rcu+0x30/0x2e0 net/sched/sch_api.c:323
     __tcf_qdisc_find+0x74/0x3a0 net/sched/cls_api.c:1050
     tc_del_tfilter+0x1c7/0x1350 net/sched/cls_api.c:2211
     rtnetlink_rcv_msg+0x5ba/0x7e0 net/core/rtnetlink.c:5585
     netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2494
     rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5612
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x602/0x6d0 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0x728/0x850 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg net/socket.c:725 [inline]
     ____sys_sendmsg+0x39a/0x510 net/socket.c:2413
     ___sys_sendmsg net/socket.c:2467 [inline]
     __sys_sendmsg+0x195/0x230 net/socket.c:2496
     __do_sys_sendmsg net/socket.c:2505 [inline]
     __se_sys_sendmsg net/socket.c:2503 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2503
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0xffffffff85dee080 -> 0xffff88815d96ec00
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 13560 Comm: syz-executor.2 Not tainted 5.17.0-rc3-syzkaller-00116-gf1baf68e1383-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 470502de5bdb ("net: sched: unlock rules update API")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Vlad Buslov <[email protected]>
    Reported-by: syzbot <[email protected]>
    Cc: Jamal Hadi Salim <[email protected]>
    Cc: Cong Wang <[email protected]>
    Cc: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
netfilter: conntrack: don't refresh sctp entries in closed state [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Fri Jan 28 13:13:32 2022 +0100

    netfilter: conntrack: don't refresh sctp entries in closed state
    
    [ Upstream commit 77b337196a9d87f3d6bb9b07c0436ecafbffda1e ]
    
    Vivek Thrivikraman reported:
     An SCTP server application which is accessed continuously by client
     application.
     When the session disconnects the client retries to establish a connection.
     After restart of SCTP server application the session is not established
     because of stale conntrack entry with connection state CLOSED as below.
    
     (removing this entry manually established new connection):
    
     sctp 9 CLOSED src=10.141.189.233 [..]  [ASSURED]
    
    Just skip timeout update of closed entries, we don't want them to
    stay around forever.
    
    Reported-and-tested-by: Vivek Thrivikraman <[email protected]>
    Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1579
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_synproxy: unregister hooks on init error path [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Thu Feb 10 10:06:42 2022 +0100

    netfilter: nft_synproxy: unregister hooks on init error path
    
    commit 2b4e5fb4d3776c391e40fb33673ba946dd96012d upstream.
    
    Disable the IPv4 hooks if the IPv6 hooks fail to be registered.
    
    Fixes: ad49d86e07a4 ("netfilter: nf_tables: Add synproxy support")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
NFS: Do not report writeback errors in nfs_getattr() [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Tue Feb 15 18:05:18 2022 -0500

    NFS: Do not report writeback errors in nfs_getattr()
    
    commit d19e0183a88306acda07f4a01fedeeffe2a2a06b upstream.
    
    The result of the writeback, whether it is an ENOSPC or an EIO, or
    anything else, does not inhibit the NFS client from reporting the
    correct file timestamps.
    
    Fixes: 79566ef018f5 ("NFS: Getattr doesn't require data sync semantics")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

NFS: LOOKUP_DIRECTORY is also ok with symlinks [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Tue Feb 8 13:38:23 2022 -0500

    NFS: LOOKUP_DIRECTORY is also ok with symlinks
    
    commit e0caaf75d443e02e55e146fd75fe2efc8aed5540 upstream.
    
    Commit ac795161c936 (NFSv4: Handle case where the lookup of a directory
    fails) [1], part of Linux since 5.17-rc2, introduced a regression, where
    a symbolic link on an NFS mount to a directory on another NFS does not
    resolve(?) the first time it is accessed:
    
    Reported-by: Paul Menzel <[email protected]>
    Fixes: ac795161c936 ("NFSv4: Handle case where the lookup of a directory fails")
    Signed-off-by: Trond Myklebust <[email protected]>
    Tested-by: Donald Buczek <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

NFS: Remove an incorrect revalidation in nfs4_update_changeattr_locked() [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Tue Feb 8 12:14:44 2022 -0500

    NFS: Remove an incorrect revalidation in nfs4_update_changeattr_locked()
    
    commit 9d047bf68fe8cdb4086deaf4edd119731a9481ed upstream.
    
    In nfs4_update_changeattr_locked(), we don't need to set the
    NFS_INO_REVAL_PAGECACHE flag, because we already know the value of the
    change attribute, and we're already flagging the size. In fact, this
    forces us to revalidate the change attribute a second time for no good
    reason.
    This extra flag appears to have been introduced as part of the xattr
    feature, when update_changeattr_locked() was converted for use by the
    xattr code.
    
    Fixes: 1b523ca972ed ("nfs: modify update_changeattr to deal with regular files")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvme-rdma: fix possible use-after-free in transport error_recovery work [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Tue Feb 1 14:54:21 2022 +0200

    nvme-rdma: fix possible use-after-free in transport error_recovery work
    
    [ Upstream commit b6bb1722f34bbdbabed27acdceaf585d300c5fd2 ]
    
    While nvme_rdma_submit_async_event_work is checking the ctrl and queue
    state before preparing the AER command and scheduling io_work, in order
    to fully prevent a race where this check is not reliable the error
    recovery work must flush async_event_work before continuing to destroy
    the admin queue after setting the ctrl state to RESETTING such that
    there is no race .submit_async_event and the error recovery handler
    itself changing the ctrl state.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme-tcp: fix possible use-after-free in transport error_recovery work [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Tue Feb 1 14:54:20 2022 +0200

    nvme-tcp: fix possible use-after-free in transport error_recovery work
    
    [ Upstream commit ff9fc7ebf5c06de1ef72a69f9b1ab40af8b07f9e ]
    
    While nvme_tcp_submit_async_event_work is checking the ctrl and queue
    state before preparing the AER command and scheduling io_work, in order
    to fully prevent a race where this check is not reliable the error
    recovery work must flush async_event_work before continuing to destroy
    the admin queue after setting the ctrl state to RESETTING such that
    there is no race .submit_async_event and the error recovery handler
    itself changing the ctrl state.
    
    Tested-by: Chris Leech <[email protected]>
    Signed-off-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: fix a possible use-after-free in controller reset during load [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Tue Feb 1 14:54:19 2022 +0200

    nvme: fix a possible use-after-free in controller reset during load
    
    [ Upstream commit 0fa0f99fc84e41057cbdd2efbfe91c6b2f47dd9d ]
    
    Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl
    readiness for AER submission. This may lead to a use-after-free
    condition that was observed with nvme-tcp.
    
    The race condition may happen in the following scenario:
    1. driver executes its reset_ctrl_work
    2. -> nvme_stop_ctrl - flushes ctrl async_event_work
    3. ctrl sends AEN which is received by the host, which in turn
       schedules AEN handling
    4. teardown admin queue (which releases the queue socket)
    5. AEN processed, submits another AER, calling the driver to submit
    6. driver attempts to send the cmd
    ==> use-after-free
    
    In order to fix that, add ctrl state check to validate the ctrl
    is actually able to accept the AER submission.
    
    This addresses the above race in controller resets because the driver
    during teardown should:
    1. change ctrl state to RESETTING
    2. flush async_event_work (as well as other async work elements)
    
    So after 1,2, any other AER command will find the
    ctrl state to be RESETTING and bail out without submitting the AER.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc: Add ioread64_lo_hi() and iowrite64_lo_hi() [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Mon Feb 7 17:16:39 2022 +0200

    parisc: Add ioread64_lo_hi() and iowrite64_lo_hi()
    
    commit 18a1d5e1945385d9b5adc3fe11427ce4a9d2826e upstream.
    
    It's a followup to the previous commit f15309d7ad5d ("parisc: Add
    ioread64_hi_lo() and iowrite64_hi_lo()") which does only half of
    the job. Add the rest, so we won't get a new kernel test robot
    reports.
    
    Fixes: f15309d7ad5d ("parisc: Add ioread64_hi_lo() and iowrite64_hi_lo()")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Drop __init from map_pages declaration [+ + +]
Author: John David Anglin <[email protected]>
Date:   Sat Jan 22 18:19:49 2022 +0000

    parisc: Drop __init from map_pages declaration
    
    commit 9129886b88185962538180625ca8051362b01327 upstream.
    
    With huge kernel pages, we randomly eat a SPARC in map_pages(). This
    is fixed by dropping __init from the declaration.
    
    However, map_pages references the __init routine memblock_alloc_try_nid
    via memblock_alloc.  Thus, it needs to be marked with __ref.
    
    memblock_alloc is only called before the kernel text is set to readonly.
    
    The __ref on free_initmem is no longer needed.
    
    Comment regarding map_pages being in the init section is removed.
    
    Signed-off-by: John David Anglin <[email protected]>
    Cc: [email protected] # v5.4+
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Fix data TLB miss in sba_unmap_sg [+ + +]
Author: John David Anglin <[email protected]>
Date:   Wed Jan 26 20:39:05 2022 +0000

    parisc: Fix data TLB miss in sba_unmap_sg
    
    commit b7d6f44a0fa716a82969725516dc0b16bc7cd514 upstream.
    
    Rolf Eike Beer reported the following bug:
    
    [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018
    [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4
    [1274934.746891] Hardware name: 9000/785/C8000
    [1274934.746891]
    [1274934.746891]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
    [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted
    [1274934.746891] r00-03  000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000
    [1274934.746891] r04-07  0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001
    [1274934.746891] r08-11  0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001
    [1274934.746891] r12-15  0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0
    [1274934.746891] r16-19  0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007
    [1274934.746891] r20-23  0000000000000006 000000004a368950 0000000000000000 0000000000000001
    [1274934.746891] r24-27  0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0
    [1274934.746891] r28-31  0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118
    [1274934.746891] sr00-03  00000000066e5800 0000000000000000 0000000000000000 00000000066e5800
    [1274934.746891] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [1274934.746891]
    [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec
    [1274934.746891]  IIR: 48780030    ISR: 0000000000000000  IOR: 0000004140000018
    [1274934.746891]  CPU:        3   CR30: 00000040e3a9c000 CR31: ffffffffffffffff
    [1274934.746891]  ORIG_R28: 0000000040acdd58
    [1274934.746891]  IAOQ[0]: sba_unmap_sg+0xb0/0x118
    [1274934.746891]  IAOQ[1]: sba_unmap_sg+0xb4/0x118
    [1274934.746891]  RP(r2): sba_unmap_sg+0xac/0x118
    [1274934.746891] Backtrace:
    [1274934.746891]  [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70
    [1274934.746891]  [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60
    [1274934.746891]  [<00000000407a3488>] mptscsih_io_done+0x150/0xd70
    [1274934.746891]  [<0000000040798600>] mpt_interrupt+0x168/0xa68
    [1274934.746891]  [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278
    [1274934.746891]  [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8
    [1274934.746891]  [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0
    [1274934.746891]  [<00000000402548e0>] generic_handle_irq+0x50/0x70
    [1274934.746891]  [<000000004019a254>] call_on_stack+0x18/0x24
    [1274934.746891]
    [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)
    
    The bug is caused by overrunning the sglist and incorrectly testing
    sg_dma_len(sglist) before nents. Normally this doesn't cause a crash,
    but in this case sglist crossed a page boundary. This occurs in the
    following code:
    
            while (sg_dma_len(sglist) && nents--) {
    
    The fix is simply to test nents first and move the decrement of nents
    into the loop.
    
    Reported-by: Rolf Eike Beer <[email protected]>
    Signed-off-by: John David Anglin <[email protected]>
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Fix sglist access in ccio-dma.c [+ + +]
Author: John David Anglin <[email protected]>
Date:   Thu Jan 27 22:33:41 2022 +0000

    parisc: Fix sglist access in ccio-dma.c
    
    commit d7da660cab47183cded65e11b64497d0f56c6edf upstream.
    
    This patch implements the same bug fix to ccio-dma.c as to sba_iommu.c.
    It ensures that only the allocated entries of the sglist are accessed.
    
    Signed-off-by: John David Anglin <[email protected]>
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Show error if wrong 32/64-bit compiler is being used [+ + +]
Author: Helge Deller <[email protected]>
Date:   Sun Feb 13 22:29:25 2022 +0100

    parisc: Show error if wrong 32/64-bit compiler is being used
    
    commit b160628e9ebcdc85d0db9d7f423c26b3c7c179d0 upstream.
    
    It happens quite often that people use the wrong compiler to build the
    kernel:
    
    make ARCH=parisc   -> builds the 32-bit kernel
    make ARCH=parisc64 -> builds the 64-bit kernel
    
    This patch adds a sanity check which errors out with an instruction how
    use the correct ARCH= option.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected] # v5.15+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: hv: Fix NUMA node assignment when kernel boots with custom NUMA topology [+ + +]
Author: Long Li <[email protected]>
Date:   Wed Jan 26 17:43:34 2022 -0800

    PCI: hv: Fix NUMA node assignment when kernel boots with custom NUMA topology
    
    commit 3149efcdf2c6314420c418dfc94de53bfd076b1f upstream.
    
    When kernel boots with a NUMA topology with some NUMA nodes offline, the PCI
    driver should only set an online NUMA node on the device. This can happen
    during KDUMP where some NUMA nodes are not made online by the KDUMP kernel.
    
    This patch also fixes the case where kernel is booting with "numa=off".
    
    Fixes: 999dd956d838 ("PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2")
    Signed-off-by: Long Li <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Tested-by: Purna Pavan Chandra Aekkaladevi <[email protected]>
    Acked-by: Lorenzo Pieralisi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf bpf: Defer freeing string after possible strlen() on it [+ + +]
Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Wed Feb 16 16:01:00 2022 -0300

    perf bpf: Defer freeing string after possible strlen() on it
    
    commit 31ded1535e3182778a1d0e5c32711f55da3bc512 upstream.
    
    This was detected by the gcc in Fedora Rawhide's gcc:
    
      50    11.01 fedora:rawhide                : FAIL gcc version 12.0.1 20220205 (Red Hat 12.0.1-0) (GCC)
            inlined from 'bpf__config_obj' at util/bpf-loader.c:1242:9:
        util/bpf-loader.c:1225:34: error: pointer 'map_opt' may be used after 'free' [-Werror=use-after-free]
         1225 |                 *key_scan_pos += strlen(map_opt);
              |                                  ^~~~~~~~~~~~~~~
        util/bpf-loader.c:1223:9: note: call to 'free' here
         1223 |         free(map_name);
              |         ^~~~~~~~~~~~~~
        cc1: all warnings being treated as errors
    
    So do the calculations on the pointer before freeing it.
    
    Fixes: 04f9bf2bac72480c ("perf bpf-loader: Add missing '*' for key_scan_pos")
    Cc: Adrian Hunter <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Wang ShaoBo <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
phy: phy-mtk-tphy: Fix duplicated argument in phy-mtk-tphy [+ + +]
Author: Wan Jiabing <[email protected]>
Date:   Fri Jan 7 10:50:50 2022 +0800

    phy: phy-mtk-tphy: Fix duplicated argument in phy-mtk-tphy
    
    [ Upstream commit 46e994717807f4b935c44d81dde9dd8bcd9a4f5d ]
    
    Fix following coccicheck warning:
    ./drivers/phy/mediatek/phy-mtk-tphy.c:994:6-29: duplicated argument
    to && or ||
    
    The efuse_rx_imp is duplicate. Here should be efuse_tx_imp.
    
    Signed-off-by: Wan Jiabing <[email protected]>
    Acked-by: Chunfeng Yun <[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: usb: Leave some clocks running during suspend [+ + +]
Author: Al Cooper <[email protected]>
Date:   Wed Dec 1 13:06:51 2021 -0500

    phy: usb: Leave some clocks running during suspend
    
    [ Upstream commit 42fed57046fc74586d7058bd51a1c10ac9c690cb ]
    
    The PHY client driver does a phy_exit() call on suspend or rmmod and
    the PHY driver needs to know the difference because some clocks need
    to be kept running for suspend but can be shutdown on unbind/rmmod
    (or if there are no PHY clients at all).
    
    The fix is to use a PM notifier so the driver can tell if a PHY
    client is calling exit() because of a system suspend or a driver
    unbind/rmmod.
    
    Signed-off-by: Al Cooper <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pidfd: fix test failure due to stack overflow on some arches [+ + +]
Author: Axel Rasmussen <[email protected]>
Date:   Thu Jan 27 13:29:51 2022 -0800

    pidfd: fix test failure due to stack overflow on some arches
    
    [ Upstream commit 4cbd93c3c110447adc66cb67c08af21f939ae2d7 ]
    
    When running the pidfd_fdinfo_test on arm64, it fails for me. After some
    digging, the reason is that the child exits due to SIGBUS, because it
    overflows the 1024 byte stack we've reserved for it.
    
    To fix the issue, increase the stack size to 8192 bytes (this number is
    somewhat arbitrary, and was arrived at through experimentation -- I kept
    doubling until the failure no longer occurred).
    
    Also, let's make the issue easier to debug. wait_for_pid() returns an
    ambiguous value: it may return -1 in all of these cases:
    
    1. waitpid() itself returned -1
    2. waitpid() returned success, but we found !WIFEXITED(status).
    3. The child process exited, but it did so with a -1 exit code.
    
    There's no way for the caller to tell the difference. So, at least log
    which occurred, so the test runner can debug things.
    
    While debugging this, I found that we had !WIFEXITED(), because the
    child exited due to a signal. This seems like a reasonably common case,
    so also print out whether or not we have WIFSIGNALED(), and the
    associated WTERMSIG() (if any). This lets us see the SIGBUS I'm fixing
    clearly when it occurs.
    
    Finally, I'm suspicious of allocating the child's stack on our stack.
    man clone(2) suggests that the correct way to do this is with mmap(),
    and in particular by setting MAP_STACK. So, switch to doing it that way
    instead.
    
    Signed-off-by: Axel Rasmussen <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pinctrl: bcm63xx: fix unmet dependency on REGMAP for GPIO_REGMAP [+ + +]
Author: Julian Braha <[email protected]>
Date:   Mon Jan 17 01:25:57 2022 -0500

    pinctrl: bcm63xx: fix unmet dependency on REGMAP for GPIO_REGMAP
    
    [ Upstream commit 3a5286955bf5febc3d151bcb2c5e272e383b64aa ]
    
    When PINCTRL_BCM63XX is selected,
    and REGMAP is not selected,
    Kbuild gives the following warning:
    
    WARNING: unmet direct dependencies detected for GPIO_REGMAP
      Depends on [n]: GPIOLIB [=y] && REGMAP [=n]
      Selected by [y]:
      - PINCTRL_BCM63XX [=y] && PINCTRL [=y]
    
    This is because PINCTRL_BCM63XX
    selects GPIO_REGMAP without selecting or depending on
    REGMAP, despite GPIO_REGMAP depending on REGMAP.
    
    This unmet dependency bug was detected by Kismet,
    a static analysis tool for Kconfig. Please advise
    if this is not the appropriate solution.
    
    Signed-off-by: Julian Braha <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ping: fix the dif and sdif check in ping_lookup [+ + +]
Author: Xin Long <[email protected]>
Date:   Wed Feb 16 00:20:52 2022 -0500

    ping: fix the dif and sdif check in ping_lookup
    
    commit 35a79e64de29e8d57a5989aac57611c0cd29e13e upstream.
    
    When 'ping' changes to use PING socket instead of RAW socket by:
    
       # sysctl -w net.ipv4.ping_group_range="0 100"
    
    There is another regression caused when matching sk_bound_dev_if
    and dif, RAW socket is using inet_iif() while PING socket lookup
    is using skb->dev->ifindex, the cmd below fails due to this:
    
      # ip link add dummy0 type dummy
      # ip link set dummy0 up
      # ip addr add 192.168.111.1/24 dev dummy0
      # ping -I dummy0 192.168.111.1 -c1
    
    The issue was also reported on:
    
      https://github.com/iputils/iputils/issues/104
    
    But fixed in iputils in a wrong way by not binding to device when
    destination IP is on device, and it will cause some of kselftests
    to fail, as Jianlin noticed.
    
    This patch is to use inet(6)_iif and inet(6)_sdif to get dif and
    sdif for PING socket, and keep consistent with RAW socket.
    
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Reported-by: Jianlin Shi <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
platform/x86: ISST: Fix possible circular locking dependency detected [+ + +]
Author: Srinivas Pandruvada <[email protected]>
Date:   Tue Jan 11 18:25:21 2022 -0800

    platform/x86: ISST: Fix possible circular locking dependency detected
    
    [ Upstream commit 17da2d5f93692086dd096a975225ffd5622d0bf8 ]
    
    As reported:
    
    [  256.104522] ======================================================
    [  256.113783] WARNING: possible circular locking dependency detected
    [  256.120093] 5.16.0-rc6-yocto-standard+ #99 Not tainted
    [  256.125362] ------------------------------------------------------
    [  256.131673] intel-speed-sel/844 is trying to acquire lock:
    [  256.137290] ffffffffc036f0d0 (punit_misc_dev_lock){+.+.}-{3:3}, at: isst_if_open+0x18/0x90 [isst_if_common]
    [  256.147171]
    [  256.147171] but task is already holding lock:
    [  256.153135] ffffffff8ee7cb50 (misc_mtx){+.+.}-{3:3}, at: misc_open+0x2a/0x170
    [  256.160407]
    [  256.160407] which lock already depends on the new lock.
    [  256.160407]
    [  256.168712]
    [  256.168712] the existing dependency chain (in reverse order) is:
    [  256.176327]
    [  256.176327] -> #1 (misc_mtx){+.+.}-{3:3}:
    [  256.181946]        lock_acquire+0x1e6/0x330
    [  256.186265]        __mutex_lock+0x9b/0x9b0
    [  256.190497]        mutex_lock_nested+0x1b/0x20
    [  256.195075]        misc_register+0x32/0x1a0
    [  256.199390]        isst_if_cdev_register+0x65/0x180 [isst_if_common]
    [  256.205878]        isst_if_probe+0x144/0x16e [isst_if_mmio]
    ...
    [  256.241976]
    [  256.241976] -> #0 (punit_misc_dev_lock){+.+.}-{3:3}:
    [  256.248552]        validate_chain+0xbc6/0x1750
    [  256.253131]        __lock_acquire+0x88c/0xc10
    [  256.257618]        lock_acquire+0x1e6/0x330
    [  256.261933]        __mutex_lock+0x9b/0x9b0
    [  256.266165]        mutex_lock_nested+0x1b/0x20
    [  256.270739]        isst_if_open+0x18/0x90 [isst_if_common]
    [  256.276356]        misc_open+0x100/0x170
    [  256.280409]        chrdev_open+0xa5/0x1e0
    ...
    
    The call sequence suggested that misc_device /dev file can be opened
    before misc device is yet to be registered, which is done only once.
    
    Here punit_misc_dev_lock was used as common lock, to protect the
    registration by multiple ISST HW drivers, one time setup, prevent
    duplicate registry of misc device and prevent load/unload when device
    is open.
    
    We can split into locks:
    - One which just prevent duplicate call to misc_register() and one
    time setup. Also never call again if the misc_register() failed or
    required one time setup is failed. This lock is not shared with
    any misc device callbacks.
    
    - The other lock protects registry, load and unload of HW drivers.
    
    Sequence in isst_if_cdev_register()
    - Register callbacks under punit_misc_dev_open_lock
    - Call isst_misc_reg() which registers misc_device on the first
    registry which is under punit_misc_dev_reg_lock, which is not
    shared with callbacks.
    
    Sequence in isst_if_cdev_unregister
    Just opposite of isst_if_cdev_register
    
    Reported-and-tested-by: Liwei Song <[email protected]>
    Signed-off-by: Srinivas Pandruvada <[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]>

platform/x86: touchscreen_dmi: Add info for the RWC NANOTE P8 AY07J 2-in-1 [+ + +]
Author: Yuka Kawajiri <[email protected]>
Date:   Wed Jan 12 00:40:21 2022 +0900

    platform/x86: touchscreen_dmi: Add info for the RWC NANOTE P8 AY07J 2-in-1
    
    [ Upstream commit 512eb73cfd1208898cf10cb06094e0ee0bb53b58 ]
    
    Add touchscreen info for RWC NANOTE P8 (AY07J) 2-in-1.
    
    Signed-off-by: Yuka Kawajiri <[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]>

 
powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Tue Dec 7 06:10:05 2021 +0000

    powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE
    
    commit 9bb162fa26ed76031ed0e7dbc77ccea0bf977758 upstream.
    
    Allthough kernel text is always mapped with BATs, we still have
    inittext mapped with pages, so TLB miss handling is required
    when CONFIG_DEBUG_PAGEALLOC or CONFIG_KFENCE is set.
    
    The final solution should be to set a BAT that also maps inittext
    but that BAT then needs to be cleared at end of init, and it will
    require more changes to be able to do it properly.
    
    As DEBUG_PAGEALLOC or KFENCE are debugging, performance is not a big
    deal so let's fix it simply for now to enable easy stable application.
    
    Fixes: 035b19a15a98 ("powerpc/32s: Always map kernel text and rodata with BATs")
    Cc: [email protected] # v5.11+
    Reported-by: Maxime Bizon <[email protected]>
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/aea33b4813a26bdb9378b5f273f00bd5d4abe240.1638857364.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc/lib/sstep: fix 'ptesync' build error [+ + +]
Author: Anders Roxell <[email protected]>
Date:   Fri Feb 11 01:51:13 2022 +0100

    powerpc/lib/sstep: fix 'ptesync' build error
    
    commit fe663df7825811358531dc2e8a52d9eaa5e3515e upstream.
    
    Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian
    2.37.90.20220207) the following build error shows up:
    
      {standard input}: Assembler messages:
      {standard input}:2088: Error: unrecognized opcode: `ptesync'
      make[3]: *** [/builds/linux/scripts/Makefile.build:287: arch/powerpc/lib/sstep.o] Error 1
    
    Add the 'ifdef CONFIG_PPC64' around the 'ptesync' in function
    'emulate_update_regs()' to like it is in 'analyse_instr()'. Since it looks like
    it got dropped inadvertently by commit 3cdfcbfd32b9 ("powerpc: Change
    analyse_instr so it doesn't modify *regs").
    
    A key detail is that analyse_instr() will never recognise lwsync or
    ptesync on 32-bit (because of the existing ifdef), and as a result
    emulate_update_regs() should never be called with an op specifying
    either of those on 32-bit. So removing them from emulate_update_regs()
    should be a nop in terms of runtime behaviour.
    
    Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
    Cc: [email protected] # v4.14+
    Suggested-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Anders Roxell <[email protected]>
    [mpe: Add last paragraph of change log mentioning analyse_instr() details]
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
quota: make dquot_quota_sync return errors from ->sync_fs [+ + +]
Author: Darrick J. Wong <[email protected]>
Date:   Sun Jan 30 08:53:16 2022 -0800

    quota: make dquot_quota_sync return errors from ->sync_fs
    
    [ Upstream commit dd5532a4994bfda0386eb2286ec00758cee08444 ]
    
    Strangely, dquot_quota_sync ignores the return code from the ->sync_fs
    call, which means that quotacalls like Q_SYNC never see the error.  This
    doesn't seem right, so fix that.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
random: wake up /dev/random writers after zap [+ + +]
Author: Jason A. Donenfeld <[email protected]>
Date:   Fri Jan 28 23:44:03 2022 +0100

    random: wake up /dev/random writers after zap
    
    [ Upstream commit 042e293e16e3aa9794ce60c29f5b7b0c8170f933 ]
    
    When account() is called, and the amount of entropy dips below
    random_write_wakeup_bits, we wake up the random writers, so that they
    can write some more in. However, the RNDZAPENTCNT/RNDCLEARPOOL ioctl
    sets the entropy count to zero -- a potential reduction just like
    account() -- but does not unblock writers. This commit adds the missing
    logic to that ioctl to unblock waiting writers.
    
    Reviewed-by: Dominik Brodowski <[email protected]>
    Signed-off-by: Jason A. Donenfeld <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "module, async: async_synchronize_full() on module init iff async is used" [+ + +]
Author: Igor Pylypiv <[email protected]>
Date:   Thu Jan 27 15:39:53 2022 -0800

    Revert "module, async: async_synchronize_full() on module init iff async is used"
    
    [ Upstream commit 67d6212afda218d564890d1674bab28e8612170f ]
    
    This reverts commit 774a1221e862b343388347bac9b318767336b20b.
    
    We need to finish all async code before the module init sequence is
    done.  In the reverted commit the PF_USED_ASYNC flag was added to mark a
    thread that called async_schedule().  Then the PF_USED_ASYNC flag was
    used to determine whether or not async_synchronize_full() needs to be
    invoked.  This works when modprobe thread is calling async_schedule(),
    but it does not work if module dispatches init code to a worker thread
    which then calls async_schedule().
    
    For example, PCI driver probing is invoked from a worker thread based on
    a node where device is attached:
    
            if (cpu < nr_cpu_ids)
                    error = work_on_cpu(cpu, local_pci_probe, &ddi);
            else
                    error = local_pci_probe(&ddi);
    
    We end up in a situation where a worker thread gets the PF_USED_ASYNC
    flag set instead of the modprobe thread.  As a result,
    async_synchronize_full() is not invoked and modprobe completes without
    waiting for the async code to finish.
    
    The issue was discovered while loading the pm80xx driver:
    (scsi_mod.scan=async)
    
    modprobe pm80xx                      worker
    ...
      do_init_module()
      ...
        pci_call_probe()
          work_on_cpu(local_pci_probe)
                                         local_pci_probe()
                                           pm8001_pci_probe()
                                             scsi_scan_host()
                                               async_schedule()
                                               worker->flags |= PF_USED_ASYNC;
                                         ...
          < return from worker >
      ...
      if (current->flags & PF_USED_ASYNC) <--- false
            async_synchronize_full();
    
    Commit 21c3c5d28007 ("block: don't request module during elevator init")
    fixed the deadlock issue which the reverted commit 774a1221e862
    ("module, async: async_synchronize_full() on module init iff async is
    used") tried to fix.
    
    Since commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
    request_module() from async workers") synchronous module loading from
    async is not allowed.
    
    Given that the original deadlock issue is fixed and it is no longer
    allowed to call synchronous request_module() from async we can remove
    PF_USED_ASYNC flag to make module init consistently invoke
    async_synchronize_full() unless async module probe is requested.
    
    Signed-off-by: Igor Pylypiv <[email protected]>
    Reviewed-by: Changyuan Lyu <[email protected]>
    Reviewed-by: Luis Chamberlain <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "net: ethernet: bgmac: Use devm_platform_ioremap_resource_byname" [+ + +]
Author: Jonas Gorski <[email protected]>
Date:   Wed Feb 16 10:46:34 2022 -0800

    Revert "net: ethernet: bgmac: Use devm_platform_ioremap_resource_byname"
    
    commit 6aba04ee3263669b335458c4cf4c7d97d6940229 upstream.
    
    This reverts commit 3710e80952cf2dc48257ac9f145b117b5f74e0a5.
    
    Since idm_base and nicpm_base are still optional resources not present
    on all platforms, this breaks the driver for everything except Northstar
    2 (which has both).
    
    The same change was already reverted once with 755f5738ff98 ("net:
    broadcom: fix a mistake about ioremap resource").
    
    So let's do it again.
    
    Fixes: 3710e80952cf ("net: ethernet: bgmac: Use devm_platform_ioremap_resource_byname")
    Signed-off-by: Jonas Gorski <[email protected]>
    [florian: Added comments to explain the resources are optional]
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "svm: Add warning message for AVIC IPI invalid target" [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Feb 4 21:41:55 2022 +0000

    Revert "svm: Add warning message for AVIC IPI invalid target"
    
    commit dd4589eee99db8f61f7b8f7df1531cad3f74a64d upstream.
    
    Remove a WARN on an "AVIC IPI invalid target" exit, the WARN is trivial
    to trigger from guest as it will fail on any destination APIC ID that
    doesn't exist from the guest's perspective.
    
    Don't bother recording anything in the kernel log, the common tracepoint
    for kvm_avic_incomplete_ipi() is sufficient for debugging.
    
    This reverts commit 37ef0c4414c9743ba7f1af4392f0a27a99649f2a.
    
    Cc: [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]>

 
rlimit: Fix RLIMIT_NPROC enforcement failure caused by capability calls in set_user [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Fri Feb 11 13:57:44 2022 -0600

    rlimit: Fix RLIMIT_NPROC enforcement failure caused by capability calls in set_user
    
    commit c16bdeb5a39ffa3f32b32f812831a2092d2a3061 upstream.
    
    Solar Designer <[email protected]> wrote:
    > I'm not aware of anyone actually running into this issue and reporting
    > it.  The systems that I personally know use suexec along with rlimits
    > still run older/distro kernels, so would not yet be affected.
    >
    > So my mention was based on my understanding of how suexec works, and
    > code review.  Specifically, Apache httpd has the setting RLimitNPROC,
    > which makes it set RLIMIT_NPROC:
    >
    > https://httpd.apache.org/docs/2.4/mod/core.html#rlimitnproc
    >
    > The above documentation for it includes:
    >
    > "This applies to processes forked from Apache httpd children servicing
    > requests, not the Apache httpd children themselves. This includes CGI
    > scripts and SSI exec commands, but not any processes forked from the
    > Apache httpd parent, such as piped logs."
    >
    > In code, there are:
    >
    > ./modules/generators/mod_cgid.c:        ( (cgid_req.limits.limit_nproc_set) && ((rc = apr_procattr_limit_set(procattr, APR_LIMIT_NPROC,
    > ./modules/generators/mod_cgi.c:        ((rc = apr_procattr_limit_set(procattr, APR_LIMIT_NPROC,
    > ./modules/filters/mod_ext_filter.c:    rv = apr_procattr_limit_set(procattr, APR_LIMIT_NPROC, conf->limit_nproc);
    >
    > For example, in mod_cgi.c this is in run_cgi_child().
    >
    > I think this means an httpd child sets RLIMIT_NPROC shortly before it
    > execs suexec, which is a SUID root program.  suexec then switches to the
    > target user and execs the CGI script.
    >
    > Before 2863643fb8b9, the setuid() in suexec would set the flag, and the
    > target user's process count would be checked against RLIMIT_NPROC on
    > execve().  After 2863643fb8b9, the setuid() in suexec wouldn't set the
    > flag because setuid() is (naturally) called when the process is still
    > running as root (thus, has those limits bypass capabilities), and
    > accordingly execve() would not check the target user's process count
    > against RLIMIT_NPROC.
    
    In commit 2863643fb8b9 ("set_user: add capability check when
    rlimit(RLIMIT_NPROC) exceeds") capable calls were added to set_user to
    make it more consistent with fork.  Unfortunately because of call site
    differences those capable calls were checking the credentials of the
    user before set*id() instead of after set*id().
    
    This breaks enforcement of RLIMIT_NPROC for applications that set the
    rlimit and then call set*id() while holding a full set of
    capabilities.  The capabilities are only changed in the new credential
    in security_task_fix_setuid().
    
    The code in apache suexec appears to follow this pattern.
    
    Commit 909cc4ae86f3 ("[PATCH] Fix two bugs with process limits
    (RLIMIT_NPROC)") where this check was added describes the targes of this
    capability check as:
    
      2/ When a root-owned process (e.g. cgiwrap) sets up process limits and then
          calls setuid, the setuid should fail if the user would then be running
          more than rlim_cur[RLIMIT_NPROC] processes, but it doesn't.  This patch
          adds an appropriate test.  With this patch, and per-user process limit
          imposed in cgiwrap really works.
    
    So the original use case of this check also appears to match the broken
    pattern.
    
    Restore the enforcement of RLIMIT_NPROC by removing the bad capable
    checks added in set_user.  This unfortunately restores the
    inconsistent state the code has been in for the last 11 years, but
    dealing with the inconsistencies looks like a larger problem.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 2863643fb8b9 ("set_user: add capability check when rlimit(RLIMIT_NPROC) exceeds")
    History-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    Reviewed-by: Solar Designer <[email protected]>
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: core: Reallocate device's budget map on queue depth change [+ + +]
Author: Ming Lei <[email protected]>
Date:   Thu Jan 27 23:37:33 2022 +0800

    scsi: core: Reallocate device's budget map on queue depth change
    
    [ Upstream commit edb854a3680bacc9ef9b91ec0c5ff6105886f6f3 ]
    
    We currently use ->cmd_per_lun as initial queue depth for setting up the
    budget_map. Martin Wilck reported that it is common for the queue_depth to
    be subsequently updated in slave_configure() based on detected hardware
    characteristics.
    
    As a result, for some drivers, the static host template settings for
    cmd_per_lun and can_queue won't actually get used in practice. And if the
    default values are used to allocate the budget_map, memory may be consumed
    unnecessarily.
    
    Fix the issue by reallocating the budget_map after ->slave_configure()
    returns. At that time the device queue_depth should accurately reflect what
    the hardware needs.
    
    Link: https://lore.kernel.org/r/[email protected]
    Cc: Bart Van Assche <[email protected]>
    Reported-by: Martin Wilck <[email protected]>
    Suggested-by: Martin Wilck <[email protected]>
    Tested-by: Martin Wilck <[email protected]>
    Reviewed-by: Martin Wilck <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: lpfc: Fix mailbox command failure during driver initialization [+ + +]
Author: James Smart <[email protected]>
Date:   Tue Sep 21 07:30:08 2021 -0700

    scsi: lpfc: Fix mailbox command failure during driver initialization
    
    commit efe1dc571a5b808baa26682eef16561be2e356fd upstream.
    
    Contention for the mailbox interface may occur during driver initialization
    (immediately after a function reset), between mailbox commands initiated
    via ioctl (bsg) and those driver requested by the driver.
    
    After setting SLI_ACTIVE flag for a port, there is a window in which the
    driver will allow an ioctl to be initiated while the adapter is
    initializing and issuing mailbox commands via polling. The polling logic
    then gets confused.
    
    Correct by having thread setting SLI_ACTIVE spot an active mailbox command
    and allow it complete before proceeding.
    
    Link: https://lore.kernel.org/r/[email protected]
    Co-developed-by: Nigel Kirkland <[email protected]>
    Signed-off-by: Nigel Kirkland <[email protected]>
    Signed-off-by: James Smart <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: lpfc: Fix pt2pt NVMe PRLI reject LOGO loop [+ + +]
Author: James Smart <[email protected]>
Date:   Sat Feb 12 08:31:20 2022 -0800

    scsi: lpfc: Fix pt2pt NVMe PRLI reject LOGO loop
    
    commit 7f4c5a26f735dea4bbc0eb8eb9da99cda95a8563 upstream.
    
    When connected point to point, the driver does not know the FC4's supported
    by the other end. In Fabrics, it can query the nameserver.  Thus the driver
    must send PRLIs for the FC4s it supports and enable support based on the
    acc(ept) or rej(ect) of the respective FC4 PRLI.  Currently the driver
    supports SCSI and NVMe PRLIs.
    
    Unfortunately, although the behavior is per standard, many devices have
    come to expect only SCSI PRLIs. In this particular example, the NVMe PRLI
    is properly RJT'd but the target decided that it must LOGO after seeing the
    unexpected NVMe PRLI. The LOGO causes the sequence to restart and login is
    now in an infinite failure loop.
    
    Fix the problem by having the driver, on a pt2pt link, remember NVMe PRLI
    accept or reject status across logout as long as the link stays "up".  When
    retrying login, if the prior NVMe PRLI was rejected, it will not be sent on
    the next login.
    
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]> # v5.4+
    Reviewed-by: Ewan D. Milne <[email protected]>
    Signed-off-by: James Smart <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task [+ + +]
Author: John Garry <[email protected]>
Date:   Thu Jan 27 21:12:52 2022 +0800

    scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task
    
    [ Upstream commit df7abcaa1246e2537ab4016077b5443bb3c09378 ]
    
    Currently a use-after-free may occur if a sas_task is aborted by the upper
    layer before we handle the I/O completion in mpi_ssp_completion() or
    mpi_sata_completion().
    
    In this case, the following are the two steps in handling those I/O
    completions:
    
     - Call complete() to inform the upper layer handler of completion of
       the I/O.
    
     - Release driver resources associated with the sas_task in
       pm8001_ccb_task_free() call.
    
    When complete() is called, the upper layer may free the sas_task. As such,
    we should not touch the associated sas_task afterwards, but we do so in the
    pm8001_ccb_task_free() call.
    
    Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.
    
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Acked-by: Jack Wang <[email protected]>
    Signed-off-by: John Garry <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm8001: Fix use-after-free for aborted TMF sas_task [+ + +]
Author: John Garry <[email protected]>
Date:   Thu Jan 27 21:12:51 2022 +0800

    scsi: pm8001: Fix use-after-free for aborted TMF sas_task
    
    [ Upstream commit 61f162aa4381845acbdc7f2be4dfb694d027c018 ]
    
    Currently a use-after-free may occur if a TMF sas_task is aborted before we
    handle the IO completion in mpi_ssp_completion(). The abort occurs due to
    timeout.
    
    When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the
    sas_task is freed in pm8001_exec_internal_tmf_task().
    
    However, if the I/O completion occurs later, the I/O completion still
    thinks that the sas_task is available. Fix this by clearing the ccb->task
    if the TMF times out - the I/O completion handler does nothing if this
    pointer is cleared.
    
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Damien Le Moal <[email protected]>
    Acked-by: Jack Wang <[email protected]>
    Signed-off-by: John Garry <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: pm80xx: Fix double completion for SATA devices [+ + +]
Author: Ajish Koshy <[email protected]>
Date:   Mon Jan 24 13:52:55 2022 +0530

    scsi: pm80xx: Fix double completion for SATA devices
    
    [ Upstream commit c26b85ea16365079be8d206b20556a60a0c69ad4 ]
    
    Current code handles completions for SATA devices in mpi_sata_completion()
    and mpi_sata_event().
    
    However, at the time when any SATA event happens, for almost all the event
    types, the command is still in the target. It is therefore incorrect to
    complete the task in sata_event().
    
    There are some events for which we get sata_completions, some need recovery
    procedure and others abort. All the tasks must be completed via
    sata_completion() path.
    
    Removed the task done related code from sata_events().  For tasks where we
    don't get completions, let top layer call abort() to abort the command post
    timeout.
    
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Jack Wang <[email protected]>
    Co-developed-by: Viswas G <[email protected]>
    Signed-off-by: Viswas G <[email protected]>
    Signed-off-by: Ajish Koshy <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qedi: Fix ABBA deadlock in qedi_process_tmf_resp() and qedi_process_cmd_cleanup_resp() [+ + +]
Author: Mike Christie <[email protected]>
Date:   Tue Feb 8 12:54:48 2022 -0600

    scsi: qedi: Fix ABBA deadlock in qedi_process_tmf_resp() and qedi_process_cmd_cleanup_resp()
    
    commit f10f582d28220f50099d3f561116256267821429 upstream.
    
    This fixes a deadlock added with commit b40f3894e39e ("scsi: qedi: Complete
    TMF works before disconnect")
    
    Bug description from Jia-Ju Bai:
    
    qedi_process_tmf_resp()
      spin_lock(&session->back_lock); --> Line 201 (Lock A)
      spin_lock(&qedi_conn->tmf_work_lock); --> Line 230 (Lock B)
    
    qedi_process_cmd_cleanup_resp()
      spin_lock_bh(&qedi_conn->tmf_work_lock); --> Line 752 (Lock B)
      spin_lock_bh(&conn->session->back_lock); --> Line 784 (Lock A)
    
    When qedi_process_tmf_resp() and qedi_process_cmd_cleanup_resp() are
    concurrently executed, the deadlock can occur.
    
    This patch fixes the deadlock by not holding the tmf_work_lock in
    qedi_process_cmd_cleanup_resp while holding the back_lock. The
    tmf_work_lock is only needed while we remove the tmf_work from the
    work_list.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: b40f3894e39e ("scsi: qedi: Complete TMF works before disconnect")
    Cc: Manish Rangankar <[email protected]>
    Cc: Nilesh Javali <[email protected]>
    Reported-by: TOTE Robot <[email protected]>
    Reported-by: Jia-Ju Bai <[email protected]>
    Signed-off-by: Mike Christie <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: Fix a deadlock in the error handler [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Fri Dec 3 15:19:42 2021 -0800

    scsi: ufs: Fix a deadlock in the error handler
    
    commit 945c3cca05d78351bba29fa65d93834cb7934c7b upstream.
    
    The following deadlock has been observed on a test setup:
    
     - All tags allocated
    
     - The SCSI error handler calls ufshcd_eh_host_reset_handler()
    
     - ufshcd_eh_host_reset_handler() queues work that calls
       ufshcd_err_handler()
    
     - ufshcd_err_handler() locks up as follows:
    
    Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
    Call trace:
     __switch_to+0x298/0x5d8
     __schedule+0x6cc/0xa94
     schedule+0x12c/0x298
     blk_mq_get_tag+0x210/0x480
     __blk_mq_alloc_request+0x1c8/0x284
     blk_get_request+0x74/0x134
     ufshcd_exec_dev_cmd+0x68/0x640
     ufshcd_verify_dev_init+0x68/0x35c
     ufshcd_probe_hba+0x12c/0x1cb8
     ufshcd_host_reset_and_restore+0x88/0x254
     ufshcd_reset_and_restore+0xd0/0x354
     ufshcd_err_handler+0x408/0xc58
     process_one_work+0x24c/0x66c
     worker_thread+0x3e8/0xa4c
     kthread+0x150/0x1b4
     ret_from_fork+0x10/0x30
    
    Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
    request.
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Bean Huo <[email protected]>
    Reviewed-by: Adrian Hunter <[email protected]>
    Reviewed-by: Bean Huo <[email protected]>
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: Remove dead code [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Fri Dec 3 15:19:38 2021 -0800

    scsi: ufs: Remove dead code
    
    commit d77ea8226b3be23b0b45aa42851243b62a27bda1 upstream.
    
    Commit 7252a3603015 ("scsi: ufs: Avoid busy-waiting by eliminating tag
    conflicts") guarantees that 'tag' is not in use by any SCSI command.
    Remove the check that returns early if a conflict occurs.
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Bean Huo <[email protected]>
    Reviewed-by: Bean Huo <[email protected]>
    Acked-by: Avri Altman <[email protected]>
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/exec: Add non-regular to TEST_GEN_PROGS [+ + +]
Author: Muhammad Usama Anjum <[email protected]>
Date:   Thu Feb 10 22:13:23 2022 +0500

    selftests/exec: Add non-regular to TEST_GEN_PROGS
    
    commit a7e793a867ae312cecdeb6f06cceff98263e75dd upstream.
    
    non-regular file needs to be compiled and then copied to the output
    directory. Remove it from TEST_PROGS and add it to TEST_GEN_PROGS. This
    removes error thrown by rsync when non-regular object isn't found:
    
    rsync: [sender] link_stat "/linux/tools/testing/selftests/exec/non-regular" failed: No such file or directory (2)
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1333) [sender=3.2.3]
    
    Fixes: 0f71241a8e32 ("selftests/exec: add file type errno tests")
    Reported-by: "kernelci.org bot" <[email protected]>
    Signed-off-by: Muhammad Usama Anjum <[email protected]>
    Reviewed-by: Shuah Khan <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/zram01.sh: Fix compression ratio calculation [+ + +]
Author: Yang Xu <[email protected]>
Date:   Thu Jan 27 17:11:36 2022 +0800

    selftests/zram01.sh: Fix compression ratio calculation
    
    [ Upstream commit d18da7ec3719559d6e74937266d0416e6c7e0b31 ]
    
    zram01 uses `free -m` to measure zram memory usage. The results are no
    sense because they are polluted by all running processes on the system.
    
    We Should only calculate the free memory delta for the current process.
    So use the third field of /sys/block/zram<id>/mm_stat to measure memory
    usage instead. The file is available since kernel 4.1.
    
    orig_data_size(first): uncompressed size of data stored in this disk.
    compr_data_size(second): compressed size of data stored in this disk
    mem_used_total(third): the amount of memory allocated for this disk
    
    Also remove useless zram cleanup call in zram_fill_fs and so we don't
    need to cleanup zram twice if fails.
    
    Signed-off-by: Yang Xu <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/zram: Adapt the situation that /dev/zram0 is being used [+ + +]
Author: Yang Xu <[email protected]>
Date:   Thu Jan 27 17:11:37 2022 +0800

    selftests/zram: Adapt the situation that /dev/zram0 is being used
    
    [ Upstream commit 01dabed20573804750af5c7bf8d1598a6bf7bf6e ]
    
    If zram-generator package is installed and works, then we can not remove
    zram module because zram swap is being used. This case needs a clean zram
    environment, change this test by using hot_add/hot_remove interface. So
    even zram device is being used, we still can add zram device and remove
    them in cleanup.
    
    The two interface was introduced since kernel commit 6566d1a32bf7("zram:
    add dynamic device add/remove functionality") in v4.2-rc1. If kernel
    supports these two interface, we use hot_add/hot_remove to slove this
    problem, if not, just check whether zram is being used or built in, then
    skip it on old kernel.
    
    Signed-off-by: Yang Xu <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/zram: Skip max_comp_streams interface on newer kernel [+ + +]
Author: Yang Xu <[email protected]>
Date:   Thu Jan 27 17:11:35 2022 +0800

    selftests/zram: Skip max_comp_streams interface on newer kernel
    
    [ Upstream commit fc4eb486a59d70bd35cf1209f0e68c2d8b979193 ]
    
    Since commit 43209ea2d17a ("zram: remove max_comp_streams internals"), zram
    has switched to per-cpu streams. Even kernel still keep this interface for
    some reasons, but writing to max_comp_stream doesn't take any effect. So
    skip it on newer kernel ie 4.7.
    
    The code that comparing kernel version is from xfstests testsuite ext4/053.
    
    Signed-off-by: Yang Xu <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: fixup build warnings in pidfd / clone3 tests [+ + +]
Author: Axel Rasmussen <[email protected]>
Date:   Thu Jan 27 14:11:15 2022 -0800

    selftests: fixup build warnings in pidfd / clone3 tests
    
    [ Upstream commit e2aa5e650b07693477dff554053605976789fd68 ]
    
    These are some trivial fixups, which were needed to build the tests with
    clang and -Werror. The following issues are fixed:
    
    - Remove various unused variables.
    - In child_poll_leader_exit_test, clang isn't smart enough to realize
      syscall(SYS_exit, 0) won't return, so it complains we never return
      from a non-void function. Add an extra exit(0) to appease it.
    - In test_pidfd_poll_leader_exit, ret may be branched on despite being
      uninitialized, if we have !use_waitpid. Initialize it to zero to get
      the right behavior in that case.
    
    Signed-off-by: Axel Rasmussen <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: netfilter: disable rp_filter on router [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Thu Feb 10 17:50:56 2022 +0800

    selftests: netfilter: disable rp_filter on router
    
    commit bbe4c0896d25009a7c86285d2ab024eed4374eea upstream.
    
    Some distros may enable rp_filter by default. After ns1 change addr to
    10.0.2.99 and set default router to 10.0.2.1, while the connected router
    address is still 10.0.1.1. The router will not reply the arp request
    from ns1. Fix it by setting the router's veth0 rp_filter to 0.
    
    Before the fix:
      # ./nft_fib.sh
      PASS: fib expression did not cause unwanted packet drops
      Netns nsrouter-HQkDORO2 fib counter doesn't match expected packet count of 1 for 1.1.1.1
      table inet filter {
              chain prerouting {
                      type filter hook prerouting priority filter; policy accept;
                      ip daddr 1.1.1.1 fib saddr . iif oif missing counter packets 0 bytes 0 drop
                      ip6 daddr 1c3::c01d fib saddr . iif oif missing counter packets 0 bytes 0 drop
              }
      }
    
    After the fix:
      # ./nft_fib.sh
      PASS: fib expression did not cause unwanted packet drops
      PASS: fib expression did drop packets for 1.1.1.1
      PASS: fib expression did drop packets for 1c3::c01d
    
    Fixes: 82944421243e ("selftests: netfilter: add fib test case")
    Signed-off-by: Yi Chen <[email protected]>
    Signed-off-by: Hangbin Liu <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests: netfilter: fix exit value for nft_concat_range [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Wed Feb 9 16:25:51 2022 +0800

    selftests: netfilter: fix exit value for nft_concat_range
    
    commit 2e71ec1a725a794a16e3862791ed43fe5ba6a06b upstream.
    
    When the nft_concat_range test failed, it exit 1 in the code
    specifically.
    
    But when part of, or all of the test passed, it will failed the
    [ ${passed} -eq 0 ] check and thus exit with 1, which is the same
    exit value with failure result. Fix it by exit 0 when passed is not 0.
    
    Fixes: 611973c1e06f ("selftests: netfilter: Introduce tests for sets with range concatenation")
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Stefano Brivio <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests: openat2: Add missing dependency in Makefile [+ + +]
Author: Cristian Marussi <[email protected]>
Date:   Wed Jan 26 10:27:22 2022 +0000

    selftests: openat2: Add missing dependency in Makefile
    
    [ Upstream commit ea3396725aa143dd42fe388cb67e44c90d2fb719 ]
    
    Add a dependency on header helpers.h to the main target; while at that add
    to helpers.h also a missing include for bool types.
    
    Cc: Aleksa Sarai <[email protected]>
    Signed-off-by: Cristian Marussi <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: openat2: Print also errno in failure messages [+ + +]
Author: Cristian Marussi <[email protected]>
Date:   Wed Jan 26 10:27:21 2022 +0000

    selftests: openat2: Print also errno in failure messages
    
    [ Upstream commit e051cdf655fa016692008a446a060eff06222bb5 ]
    
    In E_func() macro, on error, print also errno in order to aid debugging.
    
    Cc: Aleksa Sarai <[email protected]>
    Signed-off-by: Cristian Marussi <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: openat2: Skip testcases that fail with EOPNOTSUPP [+ + +]
Author: Cristian Marussi <[email protected]>
Date:   Wed Jan 26 10:27:23 2022 +0000

    selftests: openat2: Skip testcases that fail with EOPNOTSUPP
    
    [ Upstream commit ac9e0a250bb155078601a5b999aab05f2a04d1ab ]
    
    Skip testcases that fail since the requested valid flags combination is not
    supported by the underlying filesystem.
    
    Cc: Aleksa Sarai <[email protected]>
    Signed-off-by: Cristian Marussi <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: rtc: Increase test timeout so that all tests run [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Wed Jan 12 14:41:42 2022 -0500

    selftests: rtc: Increase test timeout so that all tests run
    
    [ Upstream commit f034cc1301e7d83d4ec428dd6b8ffb57ca446efb ]
    
    The timeout setting for the rtc kselftest is currently 90 seconds. This
    setting is used by the kselftest runner to stop running a test if it
    takes longer than the assigned value.
    
    However, two of the test cases inside rtc set alarms. These alarms are
    set to the next beginning of the minute, so each of these test cases may
    take up to, in the worst case, 60 seconds.
    
    In order to allow for all test cases in rtc to run, even in the worst
    case, when using the kselftest runner, the timeout value should be
    increased to at least 120. Set it to 180, so there's some additional
    slack.
    
    Correct operation can be tested by running the following command right
    after the start of a minute (low second count), and checking that all
    test cases run:
    
            ./run_kselftest.sh -c rtc
    
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Acked-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: skip mincore.check_file_mmap when fs lacks needed support [+ + +]
Author: Cristian Marussi <[email protected]>
Date:   Wed Jan 26 10:27:19 2022 +0000

    selftests: skip mincore.check_file_mmap when fs lacks needed support
    
    [ Upstream commit dae1d8ac31896988e7313384c0370176a75e9b45 ]
    
    Report mincore.check_file_mmap as SKIP instead of FAIL if the underlying
    filesystem lacks support of O_TMPFILE or fallocate since such failures
    are not really related to mincore functionality.
    
    Cc: Ricardo Cañuelo <[email protected]>
    Signed-off-by: Cristian Marussi <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: parisc: GSC: fix build when IOSAPIC is not set [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Mon Feb 14 10:00:19 2022 -0800

    serial: parisc: GSC: fix build when IOSAPIC is not set
    
    commit 6e8793674bb0d1135ca0e5c9f7e16fecbf815926 upstream.
    
    There is a build error when using a kernel .config file from
    'kernel test robot' for a different build problem:
    
    hppa64-linux-ld: drivers/tty/serial/8250/8250_gsc.o: in function `.LC3':
    (.data.rel.ro+0x18): undefined reference to `iosapic_serial_irq'
    
    when:
      CONFIG_GSC=y
      CONFIG_SERIO_GSCPS2=y
      CONFIG_SERIAL_8250_GSC=y
      CONFIG_PCI is not set
        and hence PCI_LBA is not set.
      IOSAPIC depends on PCI_LBA, so IOSAPIC is not set/enabled.
    
    Make the use of iosapic_serial_irq() conditional to fix the build error.
    
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: [email protected]
    Cc: Jiri Slaby <[email protected]>
    Cc: Johan Hovold <[email protected]>
    Suggested-by: Helge Deller <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
smb3: fix snapshot mount option [+ + +]
Author: Steve French <[email protected]>
Date:   Sat Feb 12 01:54:14 2022 -0600

    smb3: fix snapshot mount option
    
    commit 9405b5f8b20c2bfa6523a555279a0379640dc136 upstream.
    
    The conversion to the new API broke the snapshot mount option
    due to 32 vs. 64 bit type mismatch
    
    Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api")
    Cc: [email protected] # 5.11+
    Reported-by: <[email protected]>
    Acked-by: Ronnie Sahlberg <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
soc: aspeed: lpc-ctrl: Block error printing on probe defer cases [+ + +]
Author: Jae Hyun Yoo <[email protected]>
Date:   Tue Feb 1 17:31:18 2022 +1030

    soc: aspeed: lpc-ctrl: Block error printing on probe defer cases
    
    [ Upstream commit 301a5d3ad2432d7829f59432ca0a93a6defbb9a1 ]
    
    Add a checking code when it gets -EPROBE_DEFER while getting a clock
    resource. In this case, it doesn't need to print out an error message
    because the probing will be re-visited.
    
    Signed-off-by: Jae Hyun Yoo <[email protected]>
    Signed-off-by: Joel Stanley <[email protected]>
    Reviewed-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Iwona Winiarska <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]'
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: vc04_services: Fix RCU dereference check [+ + +]
Author: Padmanabha Srinivasaiah <[email protected]>
Date:   Fri Dec 31 20:54:03 2021 +0100

    staging: vc04_services: Fix RCU dereference check
    
    [ Upstream commit 0cea730cac824edf78ffd3302938ed5fe2b9d50d ]
    
    In service_callback path RCU dereferenced pointer struct vchiq_service
    need to be accessed inside rcu read-critical section.
    
    Also userdata/user_service part of vchiq_service is accessed around
    different synchronization mechanism, getting an extra reference to a
    pointer keeps sematics simpler and avoids prolonged graceperiod.
    
    Accessing vchiq_service with rcu_read_[lock/unlock] fixes below issue.
    
    [   32.201659] =============================
    [   32.201664] WARNING: suspicious RCU usage
    [   32.201670] 5.15.11-rt24-v8+ #3 Not tainted
    [   32.201680] -----------------------------
    [   32.201685] drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h:529 suspicious rcu_dereference_check() usage!
    [   32.201695]
    [   32.201695] other info that might help us debug this:
    [   32.201695]
    [   32.201700]
    [   32.201700] rcu_scheduler_active = 2, debug_locks = 1
    [   32.201708] no locks held by vchiq-slot/0/98.
    [   32.201715]
    [   32.201715] stack backtrace:
    [   32.201723] CPU: 1 PID: 98 Comm: vchiq-slot/0 Not tainted 5.15.11-rt24-v8+ #3
    [   32.201733] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
    [   32.201739] Call trace:
    [   32.201742]  dump_backtrace+0x0/0x1b8
    [   32.201772]  show_stack+0x20/0x30
    [   32.201784]  dump_stack_lvl+0x8c/0xb8
    [   32.201799]  dump_stack+0x18/0x34
    [   32.201808]  lockdep_rcu_suspicious+0xe4/0xf8
    [   32.201817]  service_callback+0x124/0x400
    [   32.201830]  slot_handler_func+0xf60/0x1e20
    [   32.201839]  kthread+0x19c/0x1a8
    [   32.201849]  ret_from_fork+0x10/0x20
    
    Tested-by: Stefan Wahren <[email protected]>
    Signed-off-by: Padmanabha Srinivasaiah <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tests: fix idmapped mount_setattr test [+ + +]
Author: Christian Brauner <[email protected]>
Date:   Thu Feb 3 14:14:05 2022 +0100

    tests: fix idmapped mount_setattr test
    
    commit d1c56bfdaca465bd1d0e913053a9c5cafe8b6a6c upstream.
    
    The test treated zero as a successful run when it really should treat
    non-zero as a successful run. A mount's idmapping can't change once it
    has been attached to the filesystem.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 01eadc8dd96d ("tests: add mount_setattr() selftests")
    Cc: Seth Forshee <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: [email protected]
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tipc: fix wrong notification node addresses [+ + +]
Author: Jon Maloy <[email protected]>
Date:   Tue Feb 15 21:00:09 2022 -0500

    tipc: fix wrong notification node addresses
    
    commit c08e58438d4a709fb451b6d7d33432cc9907a2a8 upstream.
    
    The previous bug fix had an unfortunate side effect that broke
    distribution of binding table entries between nodes. The updated
    tipc_sock_addr struct is also used further down in the same
    function, and there the old value is still the correct one.
    
    Fixes: 032062f363b4 ("tipc: fix wrong publisher node address in link publications")
    Signed-off-by: Jon Maloy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tipc: fix wrong publisher node address in link publications [+ + +]
Author: Jon Maloy <[email protected]>
Date:   Sun Feb 13 20:38:52 2022 -0500

    tipc: fix wrong publisher node address in link publications
    
    commit 032062f363b4bf02b1d547f329aa5d97b6a17410 upstream.
    
    When a link comes up we add its presence to the name table to make it
    possible for users to subscribe for link up/down events. However, after
    a previous call signature change the binding is wrongly published with
    the peer node as publishing node, instead of the own node as it should
    be. This has the effect that the command 'tipc name table show' will
    list the link binding (service type 2) with node scope and a peer node
    as originator, something that obviously is impossible.
    
    We correct this bug here.
    
    Fixes: 50a3499ab853 ("tipc: simplify signature of tipc_namtbl_publish()")
    Signed-off-by: Jon Maloy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tracing: Fix tp_printk option related with tp_printk_stop_on_boot [+ + +]
Author: JaeSang Yoo <[email protected]>
Date:   Wed Feb 9 04:54:22 2022 +0900

    tracing: Fix tp_printk option related with tp_printk_stop_on_boot
    
    [ Upstream commit 3203ce39ac0b2a57a84382ec184c7d4a0bede175 ]
    
    The kernel parameter "tp_printk_stop_on_boot" starts with "tp_printk" which is
    the same as another kernel parameter "tp_printk". If "tp_printk" setup is
    called before the "tp_printk_stop_on_boot", it will override the latter
    and keep it from being set.
    
    This is similar to other kernel parameter issues, such as:
      Commit 745a600cf1a6 ("um: console: Ignore console= option")
    or init/do_mounts.c:45 (setup function of "ro" kernel param)
    
    Fix it by checking for a "_" right after the "tp_printk" and if that
    exists do not process the parameter.
    
    Link: https://lkml.kernel.org/r/[email protected]
    
    Signed-off-by: JaeSang Yoo <[email protected]>
    [ Fixed up change log and added space after if condition ]
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: n_tty: do not look ahead for EOL character past the end of the buffer [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Tue Feb 15 15:28:00 2022 -0800

    tty: n_tty: do not look ahead for EOL character past the end of the buffer
    
    commit 3593030761630e09200072a4bd06468892c27be3 upstream.
    
    Daniel Gibson reports that the n_tty code gets line termination wrong in
    very specific cases:
    
     "If you feed a line with exactly 64 chars + terminating newline, and
      directly afterwards (without reading) another line into a pseudo
      terminal, the the first read() on the other side will return the 64
      char line *without* terminating newline, and the next read() will
      return the missing terminating newline AND the complete next line (if
      it fits in the buffer)"
    
    and bisected the behavior to commit 3b830a9c34d5 ("tty: convert
    tty_ldisc_ops 'read()' function to take a kernel pointer").
    
    Now, digging deeper, it turns out that the behavior isn't exactly new:
    what changed in commit 3b830a9c34d5 was that the tty line discipline
    .read() function is now passed an intermediate kernel buffer rather than
    the final user space buffer.
    
    And that intermediate kernel buffer is 64 bytes in size - thus that
    special case with exactly 64 bytes plus terminating newline.
    
    The same problem did exist before, but historically the boundary was not
    the 64-byte chunk, but the user-supplied buffer size, which is obviously
    generally bigger (and potentially bigger than N_TTY_BUF_SIZE, which
    would hide the issue entirely).
    
    The reason is that the n_tty canon_copy_from_read_buf() code would look
    ahead for the EOL character one byte further than it would actually
    copy.  It would then decide that it had found the terminator, and unmark
    it as an EOL character - which in turn explains why the next read
    wouldn't then be terminated by it.
    
    Now, the reason it did all this in the first place is related to some
    historical and pretty obscure EOF behavior, see commit ac8f3bf8832a
    ("n_tty: Fix poll() after buffer-limited eof push read") and commit
    40d5e0905a03 ("n_tty: Fix EOF push handling").
    
    And the reason for the EOL confusion is that we treat EOF as a special
    EOL condition, with the EOL character being NUL (aka "__DISABLED_CHAR"
    in the kernel sources).
    
    So that EOF look-ahead also affects the normal EOL handling.
    
    This patch just removes the look-ahead that causes problems, because EOL
    is much more critical than the historical "EOF in the middle of a line
    that coincides with the end of the buffer" handling ever was.
    
    Now, it is possible that we should indeed re-introduce the "look at next
    character to see if it's a EOF" behavior, but if so, that should be done
    not at the kernel buffer chunk boundary in canon_copy_from_read_buf(),
    but at a higher level, when we run out of the user buffer.
    
    In particular, the place to do that would be at the top of
    'n_tty_read()', where we check if it's a continuation of a previously
    started read, and there is no more buffer space left, we could decide to
    just eat the __DISABLED_CHAR at that point.
    
    But that would be a separate patch, because I suspect nobody actually
    cares, and I'd like to get a report about it before bothering.
    
    Fixes: 3b830a9c34d5 ("tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer")
    Fixes: ac8f3bf8832a ("n_tty: Fix  poll() after buffer-limited eof push read")
    Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215611
    Reported-and-tested-by: Daniel Gibson <[email protected]>
    Cc: Peter Hurley <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Jiri Slaby <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ucounts: Base set_cred_ucounts changes on the real user [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Wed Feb 9 16:22:20 2022 -0600

    ucounts: Base set_cred_ucounts changes on the real user
    
    commit a55d07294f1e9b576093bdfa95422f8119941e83 upstream.
    
    Michal Koutný <[email protected]> wrote:
    > Tasks are associated to multiple users at once. Historically and as per
    > setrlimit(2) RLIMIT_NPROC is enforce based on real user ID.
    >
    > The commit 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
    > made the accounting structure "indexed" by euid and hence potentially
    > account tasks differently.
    >
    > The effective user ID may be different e.g. for setuid programs but
    > those are exec'd into already existing task (i.e. below limit), so
    > different accounting is moot.
    >
    > Some special setresuid(2) users may notice the difference, justifying
    > this fix.
    
    I looked at cred->ucount and it is only used for rlimit operations
    that were previously stored in cred->user.  Making the fact
    cred->ucount can refer to a different user from cred->user a bug,
    affecting all uses of cred->ulimit not just RLIMIT_NPROC.
    
    Fix set_cred_ucounts to always use the real uid not the effective uid.
    
    Further simplify set_cred_ucounts by noticing that set_cred_ucounts
    somehow retained a draft version of the check to see if alloc_ucounts
    was needed that checks the new->user and new->user_ns against the
    current_real_cred().  Remove that draft version of the check.
    
    All that matters for setting the cred->ucounts are the user_ns and uid
    fields in the cred.
    
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Reported-by: Michal Koutný <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ucounts: Enforce RLIMIT_NPROC not RLIMIT_NPROC+1 [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Wed Feb 9 20:03:19 2022 -0600

    ucounts: Enforce RLIMIT_NPROC not RLIMIT_NPROC+1
    
    commit 8f2f9c4d82f24f172ae439e5035fc1e0e4c229dd upstream.
    
    Michal Koutný <[email protected]> wrote:
    
    > It was reported that v5.14 behaves differently when enforcing
    > RLIMIT_NPROC limit, namely, it allows one more task than previously.
    > This is consequence of the commit 21d1c5e386bc ("Reimplement
    > RLIMIT_NPROC on top of ucounts") that missed the sharpness of
    > equality in the forking path.
    
    This can be fixed either by fixing the test or by moving the increment
    to be before the test.  Fix it my moving copy_creds which contains
    the increment before is_ucounts_overlimit.
    
    In the case of CLONE_NEWUSER the ucounts in the task_cred changes.
    The function is_ucounts_overlimit needs to use the final version of
    the ucounts for the new process.  Which means moving the
    is_ucounts_overlimit test after copy_creds is necessary.
    
    Both the test in fork and the test in set_user were semantically
    changed when the code moved to ucounts.  The change of the test in
    fork was bad because it was before the increment.  The test in
    set_user was wrong and the change to ucounts fixed it.  So this
    fix only restores the old behavior in one lcation not two.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Cc: [email protected]
    Reported-by: Michal Koutný <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ucounts: Handle wrapping in is_ucounts_overlimit [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Wed Feb 9 18:09:41 2022 -0600

    ucounts: Handle wrapping in is_ucounts_overlimit
    
    commit 0cbae9e24fa7d6c6e9f828562f084da82217a0c5 upstream.
    
    While examining is_ucounts_overlimit and reading the various messages
    I realized that is_ucounts_overlimit fails to deal with counts that
    may have wrapped.
    
    Being wrapped should be a transitory state for counts and they should
    never be wrapped for long, but it can happen so handle it.
    
    Cc: [email protected]
    Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
    Link: https://lkml.kernel.org/r/[email protected]
    Reviewed-by: Shuah Khan <[email protected]>
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ucounts: In set_cred_ucounts assume new->ucounts is non-NULL [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Sat Oct 16 12:51:58 2021 -0500

    ucounts: In set_cred_ucounts assume new->ucounts is non-NULL
    
    commit 99c31f9feda41d0f10d030dc04ba106c93295aa2 upstream.
    
    Any cred that is destined for use by commit_creds must have a non-NULL
    cred->ucounts field.  Only curing credential construction is a NULL
    cred->ucounts valid.  Only abort_creds, put_cred, and put_cred_rcu
    needs to deal with a cred with a NULL ucount.  As set_cred_ucounts is
    non of those case don't confuse people by handling something that can
    not happen.
    
    Link: https://lkml.kernel.org/r/871r4irzds.fsf_-_@disp2133
    Tested-by: Yu Zhao <[email protected]>
    Reviewed-by: Alexey Gladkov <[email protected]>
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ucounts: Move RLIMIT_NPROC handling after set_user [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Mon Feb 14 09:40:25 2022 -0600

    ucounts: Move RLIMIT_NPROC handling after set_user
    
    commit c923a8e7edb010da67424077cbf1a6f1396ebd2e upstream.
    
    During set*id() which cred->ucounts to charge the the current process
    to is not known until after set_cred_ucounts.  So move the
    RLIMIT_NPROC checking into a new helper flag_nproc_exceeded and call
    flag_nproc_exceeded after set_cred_ucounts.
    
    This is very much an arbitrary subset of the places where we currently
    change the RLIMIT_NPROC accounting, designed to preserve the existing
    logic.
    
    Fixing the existing logic will be the subject of another series of
    changes.
    
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vfs: make freeze_super abort when sync_filesystem returns error [+ + +]
Author: Darrick J. Wong <[email protected]>
Date:   Sun Jan 30 08:53:16 2022 -0800

    vfs: make freeze_super abort when sync_filesystem returns error
    
    [ Upstream commit 2719c7160dcfaae1f73a1c0c210ad3281c19022e ]
    
    If we fail to synchronize the filesystem while preparing to freeze the
    fs, abort the freeze.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vsock: remove vsock from connected table when connect is interrupted by a signal [+ + +]
Author: Seth Forshee <[email protected]>
Date:   Thu Feb 17 08:13:12 2022 -0600

    vsock: remove vsock from connected table when connect is interrupted by a signal
    
    commit b9208492fcaecff8f43915529ae34b3bcb03877c upstream.
    
    vsock_connect() expects that the socket could already be in the
    TCP_ESTABLISHED state when the connecting task wakes up with a signal
    pending. If this happens the socket will be in the connected table, and
    it is not removed when the socket state is reset. In this situation it's
    common for the process to retry connect(), and if the connection is
    successful the socket will be added to the connected table a second
    time, corrupting the list.
    
    Prevent this by calling vsock_remove_connected() if a signal is received
    while waiting for a connection. This is harmless if the socket is not in
    the connected table, and if it is in the table then removing it will
    prevent list corruption from a double add.
    
    Note for backporting: this patch requires d5afa82c977e ("vsock: correct
    removal of socket from the list"), which is in all current stable trees
    except 4.9.y.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Signed-off-by: Seth Forshee <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/bug: Merge annotate_reachable() into _BUG_FLAGS() asm [+ + +]
Author: Nick Desaulniers <[email protected]>
Date:   Wed Feb 2 12:55:53 2022 -0800

    x86/bug: Merge annotate_reachable() into _BUG_FLAGS() asm
    
    [ Upstream commit bfb1a7c91fb7758273b4a8d735313d9cc388b502 ]
    
    In __WARN_FLAGS(), we had two asm statements (abbreviated):
    
      asm volatile("ud2");
      asm volatile(".pushsection .discard.reachable");
    
    These pair of statements are used to trigger an exception, but then help
    objtool understand that for warnings, control flow will be restored
    immediately afterwards.
    
    The problem is that volatile is not a compiler barrier. GCC explicitly
    documents this:
    
    > Note that the compiler can move even volatile asm instructions
    > relative to other code, including across jump instructions.
    
    Also, no clobbers are specified to prevent instructions from subsequent
    statements from being scheduled by compiler before the second asm
    statement. This can lead to instructions from subsequent statements
    being emitted by the compiler before the second asm statement.
    
    Providing a scheduling model such as via -march= options enables the
    compiler to better schedule instructions with known latencies to hide
    latencies from data hazards compared to inline asm statements in which
    latencies are not estimated.
    
    If an instruction gets scheduled by the compiler between the two asm
    statements, then objtool will think that it is not reachable, producing
    a warning.
    
    To prevent instructions from being scheduled in between the two asm
    statements, merge them.
    
    Also remove an unnecessary unreachable() asm annotation from BUG() in
    favor of __builtin_unreachable(). objtool is able to track that the ud2
    from BUG() terminates control flow within the function.
    
    Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile
    Link: https://github.com/ClangBuiltLinux/linux/issues/1483
    Signed-off-by: Nick Desaulniers <[email protected]>
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/Xen: streamline (and fix) PV CPU enumeration [+ + +]
Author: Jan Beulich <[email protected]>
Date:   Tue Feb 1 11:57:16 2022 +0100

    x86/Xen: streamline (and fix) PV CPU enumeration
    
    [ Upstream commit e25a8d959992f61b64a58fc62fb7951dc6f31d1f ]
    
    This started out with me noticing that "dom0_max_vcpus=<N>" with <N>
    larger than the number of physical CPUs reported through ACPI tables
    would not bring up the "excess" vCPU-s. Addressing this is the primary
    purpose of the change; CPU maps handling is being tidied only as far as
    is necessary for the change here (with the effect of also avoiding the
    setting up of too much per-CPU infrastructure, i.e. for CPUs which can
    never come online).
    
    Noticing that xen_fill_possible_map() is called way too early, whereas
    xen_filter_cpu_maps() is called too late (after per-CPU areas were
    already set up), and further observing that each of the functions serves
    only one of Dom0 or DomU, it looked like it was better to simplify this.
    Use the .get_smp_config hook instead, uniformly for Dom0 and DomU.
    xen_fill_possible_map() can be dropped altogether, while
    xen_filter_cpu_maps() is re-purposed but not otherwise changed.
    
    Signed-off-by: Jan Beulich <[email protected]>
    Reviewed-by: Boris Ostrovsky <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create [+ + +]
Author: Dan Aloni <[email protected]>
Date:   Tue Jan 25 22:06:46 2022 +0200

    xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create
    
    [ Upstream commit a9c10b5b3b67b3750a10c8b089b2e05f5e176e33 ]
    
    If there are failures then we must not leave the non-NULL pointers with
    the error value, otherwise `rpcrdma_ep_destroy` gets confused and tries
    free them, resulting in an Oops.
    
    Signed-off-by: Dan Aloni <[email protected]>
    Acked-by: Chuck Lever <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>