óĐÉÓÏË ÉÚÍĆÎĆÎÉÊ Ś Linux 5.17.7

 
ALSA: fireworks: fix wrong return count shorter than expected by 4 bytes [+ + +]
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sun Apr 24 19:24:28 2022 +0900

    ALSA: fireworks: fix wrong return count shorter than expected by 4 bytes
    
    commit eb9d84b0ffe39893cb23b0b6712bbe3637fa25fa upstream.
    
    ALSA fireworks driver has a bug in its initial state to return count
    shorter than expected by 4 bytes to userspace applications when handling
    response frame for Echo Audio Fireworks transaction. It's due to missing
    addition of the size for the type of event in ALSA firewire stack.
    
    Fixes: 555e8a8f7f14 ("ALSA: fireworks: Add command/response functionality into hwdep interface")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20220424102428.21109-1-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for Yoga Duet 7 13ITL6 speakers [+ + +]
Author: Zihao Wang <wzhd@ustc.edu>
Date:   Sun Apr 24 16:41:20 2022 +0800

    ALSA: hda/realtek: Add quirk for Yoga Duet 7 13ITL6 speakers
    
    commit 3b79954fd00d540677c97a560622b73f3a1f4e28 upstream.
    
    Lenovo Yoga Duet 7 13ITL6 has Realtek ALC287 and built-in
    speakers do not work out of the box. The fix developed for
    Yoga 7i 14ITL5 also enables speaker output for this model.
    
    Signed-off-by: Zihao Wang <wzhd@ustc.edu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220424084120.74125-1-wzhd@ustc.edu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix mute led issue on thinkpad with cs35l41 s-codec [+ + +]
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Apr 22 15:39:37 2022 +0800

    ALSA: hda/realtek: Fix mute led issue on thinkpad with cs35l41 s-codec
    
    commit a6ac60b36dade525c13c5bb0838589619533efb7 upstream.
    
    The quirk ALC287_FIXUP_CS35L41_I2C_2 needs to chain the quirk
    ALC269_FIXUP_THINKPAD_ACPI, otherwise the mute led will not work if a
    thinkpad machine applies that quirk.
    
    And it will be safe if non-thinkpad machines apply that quirk since
    hda_fixup_thinkpad_acpi() will check and return in this case.
    
    Fixes: ae7abe36e352e ("ALSA: hda/realtek: Add CS35L41 support for Thinkpad laptops")
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20220422073937.10073-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: da7219: Fix change notifications for tone generator frequency [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Wed Apr 20 14:34:37 2022 +0100

    ASoC: da7219: Fix change notifications for tone generator frequency
    
    commit 08ef48404965cfef99343d6bbbcf75b88c74aa0e upstream.
    
    The tone generator frequency control just returns 0 on successful write,
    not a boolean value indicating if there was a change or not.  Compare
    what was written with the value that was there previously so that
    notifications are generated appropriately when the value changes.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220420133437.569229-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: dmaengine: Restore NULL prepare_slave_config() callback [+ + +]
Author: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Date:   Thu Apr 21 15:54:02 2022 +0300

    ASoC: dmaengine: Restore NULL prepare_slave_config() callback
    
    commit 660564fc9a92a893a14f255be434f7ea0b967901 upstream.
    
    As pointed out by Sascha Hauer, this patch changes:
    if (pmc->config && !pcm->config->prepare_slave_config)
            <do nothing>
    to:
    if (pmc->config && !pcm->config->prepare_slave_config)
            snd_dmaengine_pcm_prepare_slave_config()
    
    This breaks the drivers that do not need a call to
    dmaengine_slave_config(). Drivers that still need to call
    snd_dmaengine_pcm_prepare_slave_config(), but have a NULL
    pcm->config->prepare_slave_config should use
    snd_dmaengine_pcm_prepare_slave_config() as their prepare_slave_config
    callback.
    
    Fixes: 9a1e13440a4f ("ASoC: dmaengine: do not use a NULL prepare_slave_config() callback")
    Reported-by: Sascha Hauer <sha@pengutronix.de>
    Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Link: https://lore.kernel.org/r/20220421125403.2180824-1-codrin.ciubotariu@microchip.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: meson: axg-card: Fix nonatomic links [+ + +]
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Thu Apr 21 17:57:25 2022 +0200

    ASoC: meson: axg-card: Fix nonatomic links
    
    commit 0c9b152c72e53016e96593bdbb8cffe2176694b9 upstream.
    
    This commit e138233e56e9829e65b6293887063a1a3ccb2d68 causes the
    following system crash when using audio on G12A/G12B & SM1 systems:
    
     BUG: sleeping function called from invalid context at kernel/locking/mutex.c:282
      in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0
     preempt_count: 10001, expected: 0
     RCU nest depth: 0, expected: 0
     Preemption disabled at:
     schedule_preempt_disabled+0x20/0x2c
    
     mutex_lock+0x24/0x60
     _snd_pcm_stream_lock_irqsave+0x20/0x3c
     snd_pcm_period_elapsed+0x24/0xa4
     axg_fifo_pcm_irq_block+0x64/0xdc
     __handle_irq_event_percpu+0x104/0x264
     handle_irq_event+0x48/0xb4
     ...
     start_kernel+0x3f0/0x484
     __primary_switched+0xc0/0xc8
    
    Revert this commit until the crash is fixed.
    
    Fixes: e138233e56e9829e65b6 ("ASoC: meson: axg-card: make links nonatomic")
    Reported-by: Dmitry Shmidt <dimitrysh@google.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Acked-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20220421155725.2589089-2-narmstrong@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: meson: axg-tdm-interface: Fix formatters in trigger" [+ + +]
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Thu Apr 21 17:57:24 2022 +0200

    ASoC: meson: axg-tdm-interface: Fix formatters in trigger"
    
    commit c26830b6c5c534d273ce007eb33d5a2d2ad4e969 upstream.
    
    This reverts commit bf5e4887eeddb48480568466536aa08ec7f179a5 because
    the following and required commit e138233e56e9829e65b6293887063a1a3ccb2d68
    causes the following system crash when using audio:
     BUG: sleeping function called from invalid context at kernel/locking/mutex.c:282
    
    Fixes: bf5e4887eeddb4848056846 ("ASoC: meson: axg-tdm-interface: manage formatters in trigger")
    Reported-by: Dmitry Shmidt <dimitrysh@google.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Acked-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20220421155725.2589089-1-narmstrong@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: meson: Fix event generation for AUI ACODEC mux [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Apr 21 13:38:01 2022 +0100

    ASoC: meson: Fix event generation for AUI ACODEC mux
    
    commit 2e3a0d1bfa95b54333f7add3e50e288769373873 upstream.
    
    The AIU ACODEC has a custom put() operation which returns 0 when the value
    of the mux changes, meaning that events are not generated for userspace.
    Change to return 1 in this case, the function returns early in the case
    where there is no change.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20220421123803.292063-2-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: meson: Fix event generation for AUI CODEC mux [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Apr 21 13:38:02 2022 +0100

    ASoC: meson: Fix event generation for AUI CODEC mux
    
    commit fce49921a22262736cdc3cc74fa67915b75e9363 upstream.
    
    The AIU CODEC has a custom put() operation which returns 0 when the value
    of the mux changes, meaning that events are not generated for userspace.
    Change to return 1 in this case, the function returns early in the case
    where there is no change.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20220421123803.292063-3-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: meson: Fix event generation for G12A tohdmi mux [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Apr 21 13:38:03 2022 +0100

    ASoC: meson: Fix event generation for G12A tohdmi mux
    
    commit 12131008fc13ff7f7690d170b7a8f72d24fd7d1e upstream.
    
    The G12A tohdmi has a custom put() operation which returns 0 when the value
    of the mux changes, meaning that events are not generated for userspace.
    Change to return 1 in this case, the function returns early in the case
    where there is no change.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20220421123803.292063-4-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: rt9120: Correct the reg 0x09 size to one byte [+ + +]
Author: ChiYuan Huang <cy_huang@richtek.com>
Date:   Fri Apr 22 14:26:50 2022 +0800

    ASoC: rt9120: Correct the reg 0x09 size to one byte
    
    commit 87c18514bb8477563a61f50b4285da156296edc4 upstream.
    
    Correct the reg 0x09 size to one byte.
    
    Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1650608810-3829-1-git-send-email-u0084500@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: soc-ops: fix error handling [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Apr 21 11:23:28 2022 -0500

    ASoC: soc-ops: fix error handling
    
    commit eb5773201b1c5d603424bd21f161c8c2d1075b42 upstream.
    
    cppcheck throws the following warning:
    
    sound/soc/soc-ops.c:461:8: style: Variable 'ret' is assigned a value
    that is never used. [unreadVariable]
       ret = err;
           ^
    
    This seems to be a missing change in the return value.
    
    Fixes: 7f3d90a351968 ("ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: PĂ©ter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20220421162328.302017-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: wm8958: Fix change notifications for DSP controls [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Sat Apr 16 13:54:08 2022 +0100

    ASoC: wm8958: Fix change notifications for DSP controls
    
    commit b4f5c6b2e52b27462c0599e64e96e53b58438de1 upstream.
    
    The WM8958 DSP controls all return 0 on successful write, not a boolean
    value indicating if the write changed the value of the control. Fix this
    by returning 1 after a change, there is already a check at the start of
    each put() that skips the function in the case that there is no change.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220416125408.197440-1-broonie@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bnxt_en: Fix possible bnxt_open() failure caused by wrong RFS flag [+ + +]
Author: Somnath Kotur <somnath.kotur@broadcom.com>
Date:   Mon May 2 21:13:10 2022 -0400

    bnxt_en: Fix possible bnxt_open() failure caused by wrong RFS flag
    
    commit 13ba794397e45e52893cfc21d7a69cb5f341b407 upstream.
    
    bnxt_open() can fail in this code path, especially on a VF when
    it fails to reserve default rings:
    
    bnxt_open()
      __bnxt_open_nic()
        bnxt_clear_int_mode()
        bnxt_init_dflt_ring_mode()
    
    RX rings would be set to 0 when we hit this error path.
    
    It is possible for a subsequent bnxt_open() call to potentially succeed
    with a code path like this:
    
    bnxt_open()
      bnxt_hwrm_if_change()
        bnxt_fw_init_one()
          bnxt_fw_init_one_p3()
            bnxt_set_dflt_rfs()
              bnxt_rfs_capable()
                bnxt_hwrm_reserve_rings()
    
    On older chips, RFS is capable if we can reserve the number of vnics that
    is equal to RX rings + 1.  But since RX rings is still set to 0 in this
    code path, we may mistakenly think that RFS is supported for 0 RX rings.
    
    Later, when the default RX rings are reserved and we try to enable
    RFS, it would fail and cause bnxt_open() to fail unnecessarily.
    
    We fix this in 2 places.  bnxt_rfs_capable() will always return false if
    RX rings is not yet set.  bnxt_init_dflt_ring_mode() will call
    bnxt_set_dflt_rfs() which will always clear the RFS flags if RFS is not
    supported.
    
    Fixes: 20d7d1c5c9b1 ("bnxt_en: reliably allocate IRQ table on reset to avoid crash")
    Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bnxt_en: Fix unnecessary dropping of RX packets [+ + +]
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Mon May 2 21:13:12 2022 -0400

    bnxt_en: Fix unnecessary dropping of RX packets
    
    commit 195af57914d15229186658ed26dab24b9ada4122 upstream.
    
    In bnxt_poll_p5(), we first check cpr->has_more_work.  If it is true,
    we are in NAPI polling mode and we will call __bnxt_poll_cqs() to
    continue polling.  It is possible to exhanust the budget again when
    __bnxt_poll_cqs() returns.
    
    We then enter the main while loop to check for new entries in the NQ.
    If we had previously exhausted the NAPI budget, we may call
    __bnxt_poll_work() to process an RX entry with zero budget.  This will
    cause packets to be dropped unnecessarily, thinking that we are in the
    netpoll path.  Fix it by breaking out of the while loop if we need
    to process an RX NQ entry with no budget left.  We will then exit
    NAPI and stay in polling mode.
    
    Fixes: 389a877a3b20 ("bnxt_en: Process the NQ under NAPI continuous polling.")
    Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: always log symlinks in full mode [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Apr 21 10:56:39 2022 +0100

    btrfs: always log symlinks in full mode
    
    commit d0e64a981fd841cb0f28fcd6afcac55e6f1e6994 upstream.
    
    On Linux, empty symlinks are invalid, and attempting to create one with
    the system call symlink(2) results in an -ENOENT error and this is
    explicitly documented in the man page.
    
    If we rename a symlink that was created in the current transaction and its
    parent directory was logged before, we actually end up logging the symlink
    without logging its content, which is stored in an inline extent. That
    means that after a power failure we can end up with an empty symlink,
    having no content and an i_size of 0 bytes.
    
    It can be easily reproduced like this:
    
      $ mkfs.btrfs -f /dev/sdc
      $ mount /dev/sdc /mnt
    
      $ mkdir /mnt/testdir
      $ sync
    
      # Create a file inside the directory and fsync the directory.
      $ touch /mnt/testdir/foo
      $ xfs_io -c "fsync" /mnt/testdir
    
      # Create a symlink inside the directory and then rename the symlink.
      $ ln -s /mnt/testdir/foo /mnt/testdir/bar
      $ mv /mnt/testdir/bar /mnt/testdir/baz
    
      # Now fsync again the directory, this persist the log tree.
      $ xfs_io -c "fsync" /mnt/testdir
    
      <power failure>
    
      $ mount /dev/sdc /mnt
      $ stat -c %s /mnt/testdir/baz
      0
      $ readlink /mnt/testdir/baz
      $
    
    Fix this by always logging symlinks in full mode (LOG_INODE_ALL), so that
    their content is also logged.
    
    A test case for fstests will follow.
    
    CC: stable@vger.kernel.org # 4.9+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: do not allow compression on nodatacow files [+ + +]
Author: Chung-Chiang Cheng <cccheng@synology.com>
Date:   Fri Apr 15 16:04:06 2022 +0800

    btrfs: do not allow compression on nodatacow files
    
    commit 0e852ab8974cd2b5946766b2d9baf82c78ace03d upstream.
    
    Compression and nodatacow are mutually exclusive. A similar issue was
    fixed by commit f37c563bab429 ("btrfs: add missing check for nocow and
    compression inode flags"). Besides ioctl, there is another way to
    enable/disable/reset compression directly via xattr. The following
    steps will result in a invalid combination.
    
      $ touch bar
      $ chattr +C bar
      $ lsattr bar
      ---------------C-- bar
      $ setfattr -n btrfs.compression -v zstd bar
      $ lsattr bar
      --------c------C-- bar
    
    To align with the logic in check_fsflags, nocompress will also be
    unacceptable after this patch, to prevent mix any compression-related
    options with nodatacow.
    
      $ touch bar
      $ chattr +C bar
      $ lsattr bar
      ---------------C-- bar
      $ setfattr -n btrfs.compression -v zstd bar
      setfattr: bar: Invalid argument
      $ setfattr -n btrfs.compression -v no bar
      setfattr: bar: Invalid argument
    
    When both compression and nodatacow are enabled, then
    btrfs_run_delalloc_range prefers nodatacow and no compression happens.
    
    Reported-by: Jayce Lin <jaycelin@synology.com>
    CC: stable@vger.kernel.org # 5.10.x: e6f9d6964802: btrfs: export a helper for compression hard check
    CC: stable@vger.kernel.org # 5.10.x
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: do not BUG_ON() on failure to update inode when setting xattr [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Apr 21 11:03:09 2022 +0100

    btrfs: do not BUG_ON() on failure to update inode when setting xattr
    
    commit 193b4e83986d7ee6caa8ceefb5ee9f58240fbee0 upstream.
    
    We are doing a BUG_ON() if we fail to update an inode after setting (or
    clearing) a xattr, but there's really no reason to not instead simply
    abort the transaction and return the error to the caller. This should be
    a rare error because we have previously reserved enough metadata space to
    update the inode and the delayed inode should have already been setup, so
    an -ENOSPC or -ENOMEM, which are the possible errors, are very unlikely to
    happen.
    
    So replace the BUG_ON()s with a transaction abort.
    
    CC: stable@vger.kernel.org # 4.9+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: export a helper for compression hard check [+ + +]
Author: Chung-Chiang Cheng <cccheng@synology.com>
Date:   Fri Apr 15 16:04:05 2022 +0800

    btrfs: export a helper for compression hard check
    
    commit e6f9d69648029e48b8f97db09368d419b5e2614a upstream.
    
    inode_can_compress will be used outside of inode.c to check the
    availability of setting compression flag by xattr. This patch moves
    this function as an internal helper and renames it to
    btrfs_inode_can_compress.
    
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: force v2 space cache usage for subpage mount [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Fri Apr 1 15:29:37 2022 +0800

    btrfs: force v2 space cache usage for subpage mount
    
    commit 9f73f1aef98b2fa7252c0a89be64840271ce8ea0 upstream.
    
    [BUG]
    For a 4K sector sized btrfs with v1 cache enabled and only mounted on
    systems with 4K page size, if it's mounted on subpage (64K page size)
    systems, it can cause the following warning on v1 space cache:
    
     BTRFS error (device dm-1): csum mismatch on free space cache
     BTRFS warning (device dm-1): failed to load free space cache for block group 84082688, rebuilding it now
    
    Although not a big deal, as kernel can rebuild it without problem, such
    warning will bother end users, especially if they want to switch the
    same btrfs seamlessly between different page sized systems.
    
    [CAUSE]
    V1 free space cache is still using fixed PAGE_SIZE for various bitmap,
    like BITS_PER_BITMAP.
    
    Such hard-coded PAGE_SIZE usage will cause various mismatch, from v1
    cache size to checksum.
    
    Thus kernel will always reject v1 cache with a different PAGE_SIZE with
    csum mismatch.
    
    [FIX]
    Although we should fix v1 cache, it's already going to be marked
    deprecated soon.
    
    And we have v2 cache based on metadata (which is already fully subpage
    compatible), and it has almost everything superior than v1 cache.
    
    So just force subpage mount to use v2 cache on mount.
    
    Reported-by: Matt Corallo <blnxfsl@bluematt.me>
    CC: stable@vger.kernel.org # 5.15+
    Link: https://lore.kernel.org/linux-btrfs/61aa27d1-30fc-c1a9-f0f4-9df544395ec3@bluematt.me/
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: skip compression property for anything other than files and dirs [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Apr 21 11:01:22 2022 +0100

    btrfs: skip compression property for anything other than files and dirs
    
    commit 4b73c55fdebd8939f0f6000921075f7f6fa41397 upstream.
    
    The compression property only has effect on regular files and directories
    (so that it's propagated to files and subdirectories created inside a
    directory). For any other inode type (symlink, fifo, device, socket),
    it's pointless to set the compression property because it does nothing
    and ends up unnecessarily wasting leaf space due to the pointless xattr
    (75 or 76 bytes, depending on the compression value). Symlinks in
    particular are very common (for example, I have almost 10k symlinks under
    /etc, /usr and /var alone) and therefore it's worth to avoid wasting
    leaf space with the compression xattr.
    
    For example, the compression property can end up on a symlink or character
    device implicitly, through inheritance from a parent directory
    
      $ mkdir /mnt/testdir
      $ btrfs property set /mnt/testdir compression lzo
    
      $ ln -s yadayada /mnt/testdir/lnk
      $ mknod /mnt/testdir/dev c 0 0
    
    Or explicitly like this:
    
      $ ln -s yadayda /mnt/lnk
      $ setfattr -h -n btrfs.compression -v lzo /mnt/lnk
    
    So skip the compression property on inodes that are neither a regular
    file nor a directory.
    
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: sysfs: export the balance paused state of exclusive operation [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue May 3 17:35:25 2022 +0200

    btrfs: sysfs: export the balance paused state of exclusive operation
    
    commit 3e1ad196385c65c1454aceab1226d9a4baca27d5 upstream.
    
    The new state allowing device addition with paused balance is not
    exported to user space so it can't recognize it and actually start the
    operation.
    
    Fixes: efc0e69c2fea ("btrfs: introduce exclusive operation BALANCE_PAUSED state")
    CC: stable@vger.kernel.org # 5.17
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
can: grcan: grcan_close(): fix deadlock [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Mon Apr 25 12:24:00 2022 +0800

    can: grcan: grcan_close(): fix deadlock
    
    commit 47f070a63e735bcc8d481de31be1b5a1aa62b31c upstream.
    
    There are deadlocks caused by del_timer_sync(&priv->hang_timer) and
    del_timer_sync(&priv->rr_timer) in grcan_close(), one of the deadlocks
    are shown below:
    
       (Thread 1)              |      (Thread 2)
                               | grcan_reset_timer()
    grcan_close()              |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | grcan_initiate_running_reset()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold priv->lock in position (1) of thread 1 and use
    del_timer_sync() to wait timer to stop, but timer handler also need
    priv->lock in position (2) of thread 2. As a result, grcan_close()
    will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irqsave(), which could let timer handler to obtain the
    needed lock.
    
    Link: https://lore.kernel.org/all/20220425042400.66517-1-duoming@zju.edu.cn
    Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores")
    Cc: stable@vger.kernel.org
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: grcan: grcan_probe(): fix broken system id check for errata workaround needs [+ + +]
Author: Andreas Larsson <andreas@gaisler.com>
Date:   Fri Apr 29 10:46:55 2022 +0200

    can: grcan: grcan_probe(): fix broken system id check for errata workaround needs
    
    commit 1e93ed26acf03fe6c97c6d573a10178596aadd43 upstream.
    
    The systemid property was checked for in the wrong place of the device
    tree and compared to the wrong value.
    
    Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores")
    Link: https://lore.kernel.org/all/20220429084656.29788-3-andreas@gaisler.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: grcan: only use the NAPI poll budget for RX [+ + +]
Author: Andreas Larsson <andreas@gaisler.com>
Date:   Fri Apr 29 10:46:56 2022 +0200

    can: grcan: only use the NAPI poll budget for RX
    
    commit 2873d4d52f7c52d60b316ba6c47bd7122b5a9861 upstream.
    
    The previous split budget between TX and RX made it return not using
    the entire budget but at the same time not having calling called
    napi_complete. This sometimes led to the poll to not be called, and at
    the same time having TX and RX interrupts disabled resulting in the
    driver getting stuck.
    
    Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores")
    Link: https://lore.kernel.org/all/20220429084656.29788-4-andreas@gaisler.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: grcan: use ofdev->dev when allocating DMA memory [+ + +]
Author: Daniel Hellstrom <daniel@gaisler.com>
Date:   Fri Apr 29 10:46:54 2022 +0200

    can: grcan: use ofdev->dev when allocating DMA memory
    
    commit 101da4268626b00d16356a6bf284d66e44c46ff9 upstream.
    
    Use the device of the device tree node should be rather than the
    device of the struct net_device when allocating DMA buffers.
    
    The driver got away with it on sparc32 until commit 53b7670e5735
    ("sparc: factor the dma coherent mapping into helper") after which the
    driver oopses.
    
    Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores")
    Link: https://lore.kernel.org/all/20220429084656.29788-2-andreas@gaisler.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: isotp: remove re-binding of bound socket [+ + +]
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Fri Apr 22 10:23:37 2022 +0200

    can: isotp: remove re-binding of bound socket
    
    commit 72ed3ee9fa0b461ad086403a8b5336154bd82234 upstream.
    
    As a carry over from the CAN_RAW socket (which allows to change the CAN
    interface while mantaining the filter setup) the re-binding of the
    CAN_ISOTP socket needs to take care about CAN ID address information and
    subscriptions. It turned out that this feature is so limited (e.g. the
    sockopts remain fix) that it finally has never been needed/used.
    
    In opposite to the stateless CAN_RAW socket the switching of the CAN ID
    subscriptions might additionally lead to an interrupted ongoing PDU
    reception. So better remove this unneeded complexity.
    
    Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
    Link: https://lore.kernel.org/all/20220422082337.1676-1-socketcan@hartkopp.net
    Cc: stable@vger.kernel.org
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Avoid reading audio pattern past AUDIO_CHANNELS_COUNT [+ + +]
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Tue Apr 19 13:03:12 2022 -0400

    drm/amd/display: Avoid reading audio pattern past AUDIO_CHANNELS_COUNT
    
    commit 3dfe85fa87b2a26bdbd292b66653bba065cf9941 upstream.
    
    A faulty receiver might report an erroneous channel count. We
    should guard against reading beyond AUDIO_CHANNELS_COUNT as
    that would overflow the dpcd_pattern_period array.
    
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: do not use passthrough mode in Xen dom0 [+ + +]
Author: Marek Marczykowski-GĂłrecki <marmarek@invisiblethingslab.com>
Date:   Wed Apr 27 01:57:15 2022 +0200

    drm/amdgpu: do not use passthrough mode in Xen dom0
    
    commit 19965d8259fdabc6806da92adda49684f5bcbec5 upstream.
    
    While technically Xen dom0 is a virtual machine too, it does have
    access to most of the hardware so it doesn't need to be considered a
    "passthrough". Commit b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for
    APUs in passthrough") changed how FB is accessed based on passthrough
    mode. This breaks amdgpu in Xen dom0 with message like this:
    
        [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3
    
    While the reason for this failure is unclear, the passthrough mode is
    not really necessary in Xen dom0 anyway. So, to unbreak booting affected
    kernels, disable passthrough mode in this case.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1985
    Fixes: b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough")
    Signed-off-by: Marek Marczykowski-GĂłrecki <marmarek@invisiblethingslab.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm/dp: remove fail safe mode related code [+ + +]
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Tue Apr 26 14:12:14 2022 -0700

    drm/msm/dp: remove fail safe mode related code
    
    commit 3f65b1e2f424f44585bd701024a3bfd0b1e0ade2 upstream.
    
    Current DP driver implementation has adding safe mode done at
    dp_hpd_plug_handle() which is expected to be executed under event
    thread context.
    
    However there is possible circular locking happen (see blow stack trace)
    after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
    is executed under drm_thread context.
    
    After review all possibilities methods and as discussed on
    https://patchwork.freedesktop.org/patch/483155/, supporting EDID
    compliance tests in the driver is quite hacky. As seen with other
    vendor drivers, supporting these will be much easier with IGT. Hence
    removing all the related fail safe code for it so that no possibility
    of circular lock will happen.
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    
    ======================================================
     WARNING: possible circular locking dependency detected
     5.15.35-lockdep #6 Tainted: G        W
     ------------------------------------------------------
     frecon/429 is trying to acquire lock:
     ffffff808dc3c4e8 (&dev->mode_config.mutex){+.+.}-{3:3}, at:
    dp_panel_add_fail_safe_mode+0x4c/0xa0
    
     but task is already holding lock:
     ffffff808dc441e0 (&kms->commit_lock[i]){+.+.}-{3:3}, at: lock_crtcs+0xb4/0x124
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #3 (&kms->commit_lock[i]){+.+.}-{3:3}:
            __mutex_lock_common+0x174/0x1a64
            mutex_lock_nested+0x98/0xac
            lock_crtcs+0xb4/0x124
            msm_atomic_commit_tail+0x330/0x748
            commit_tail+0x19c/0x278
            drm_atomic_helper_commit+0x1dc/0x1f0
            drm_atomic_commit+0xc0/0xd8
            drm_atomic_helper_set_config+0xb4/0x134
            drm_mode_setcrtc+0x688/0x1248
            drm_ioctl_kernel+0x1e4/0x338
            drm_ioctl+0x3a4/0x684
            __arm64_sys_ioctl+0x118/0x154
            invoke_syscall+0x78/0x224
            el0_svc_common+0x178/0x200
            do_el0_svc+0x94/0x13c
            el0_svc+0x5c/0xec
            el0t_64_sync_handler+0x78/0x108
            el0t_64_sync+0x1a4/0x1a8
    
     -> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
            __mutex_lock_common+0x174/0x1a64
            ww_mutex_lock+0xb8/0x278
            modeset_lock+0x304/0x4ac
            drm_modeset_lock+0x4c/0x7c
            drmm_mode_config_init+0x4a8/0xc50
            msm_drm_init+0x274/0xac0
            msm_drm_bind+0x20/0x2c
            try_to_bring_up_master+0x3dc/0x470
            __component_add+0x18c/0x3c0
            component_add+0x1c/0x28
            dp_display_probe+0x954/0xa98
            platform_probe+0x124/0x15c
            really_probe+0x1b0/0x5f8
            __driver_probe_device+0x174/0x20c
            driver_probe_device+0x70/0x134
            __device_attach_driver+0x130/0x1d0
            bus_for_each_drv+0xfc/0x14c
            __device_attach+0x1bc/0x2bc
            device_initial_probe+0x1c/0x28
            bus_probe_device+0x94/0x178
            deferred_probe_work_func+0x1a4/0x1f0
            process_one_work+0x5d4/0x9dc
            worker_thread+0x898/0xccc
            kthread+0x2d4/0x3d4
            ret_from_fork+0x10/0x20
    
     -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
            ww_acquire_init+0x1c4/0x2c8
            drm_modeset_acquire_init+0x44/0xc8
            drm_helper_probe_single_connector_modes+0xb0/0x12dc
            drm_mode_getconnector+0x5dc/0xfe8
            drm_ioctl_kernel+0x1e4/0x338
            drm_ioctl+0x3a4/0x684
            __arm64_sys_ioctl+0x118/0x154
            invoke_syscall+0x78/0x224
            el0_svc_common+0x178/0x200
            do_el0_svc+0x94/0x13c
            el0_svc+0x5c/0xec
            el0t_64_sync_handler+0x78/0x108
            el0t_64_sync+0x1a4/0x1a8
    
     -> #0 (&dev->mode_config.mutex){+.+.}-{3:3}:
            __lock_acquire+0x2650/0x672c
            lock_acquire+0x1b4/0x4ac
            __mutex_lock_common+0x174/0x1a64
            mutex_lock_nested+0x98/0xac
            dp_panel_add_fail_safe_mode+0x4c/0xa0
            dp_hpd_plug_handle+0x1f0/0x280
            dp_bridge_enable+0x94/0x2b8
            drm_atomic_bridge_chain_enable+0x11c/0x168
            drm_atomic_helper_commit_modeset_enables+0x500/0x740
            msm_atomic_commit_tail+0x3e4/0x748
            commit_tail+0x19c/0x278
            drm_atomic_helper_commit+0x1dc/0x1f0
            drm_atomic_commit+0xc0/0xd8
            drm_atomic_helper_set_config+0xb4/0x134
            drm_mode_setcrtc+0x688/0x1248
            drm_ioctl_kernel+0x1e4/0x338
            drm_ioctl+0x3a4/0x684
            __arm64_sys_ioctl+0x118/0x154
            invoke_syscall+0x78/0x224
            el0_svc_common+0x178/0x200
            do_el0_svc+0x94/0x13c
            el0_svc+0x5c/0xec
            el0t_64_sync_handler+0x78/0x108
            el0t_64_sync+0x1a4/0x1a8
    
    Changes in v2:
    -- re text commit title
    -- remove all fail safe mode
    
    Changes in v3:
    -- remove dp_panel_add_fail_safe_mode() from dp_panel.h
    -- add Fixes
    
    Changes in v5:
    --  to=dianders@chromium.org
    
    Changes in v6:
    --  fix Fixes commit ID
    
    Fixes: 8b2c181e3dcf ("drm/msm/dp: add fail safe mode outside of event_mutex context")
    Reported-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Link: https://lore.kernel.org/r/1651007534-31842-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dt-bindings: pci: apple,pcie: Drop max-link-speed from example [+ + +]
Author: Hector Martin <marcan@marcan.st>
Date:   Mon May 2 18:13:08 2022 +0900

    dt-bindings: pci: apple,pcie: Drop max-link-speed from example
    
    commit 5dc4630426511f641b7ac44fc550b8e21eafb237 upstream.
    
    We no longer use these since 111659c2a570 (and they never worked
    anyway); drop them from the example to avoid confusion.
    
    Fixes: 111659c2a570 ("arm64: dts: apple: t8103: Remove PCIe max-link-speed properties")
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220502091308.28233-1-marcan@marcan.st
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbdev: Make fb_release() return -ENODEV if fbdev was unregistered [+ + +]
Author: Javier Martinez Canillas <javierm@redhat.com>
Date:   Mon May 2 15:50:14 2022 +0200

    fbdev: Make fb_release() return -ENODEV if fbdev was unregistered
    
    [ Upstream commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a ]
    
    A reference to the framebuffer device struct fb_info is stored in the file
    private data, but this reference could no longer be valid and must not be
    accessed directly. Instead, the file_fb_info() accessor function must be
    used since it does sanity checking to make sure that the fb_info is valid.
    
    This can happen for example if the registered framebuffer device is for a
    driver that just uses a framebuffer provided by the system firmware. In
    that case, the fbdev core would unregister the framebuffer device when a
    real video driver is probed and ask to remove conflicting framebuffers.
    
    The bug has been present for a long time but commit 27599aacbaef ("fbdev:
    Hot-unplug firmware fb devices on forced removal") unmasked it since the
    fbdev core started unregistering the framebuffers' devices associated.
    
    Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
    Reported-by: Maxime Ripard <maxime@cerno.tech>
    Reported-by: Junxiao Chang <junxiao.chang@intel.com>
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220502135014.377945-1-javierm@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firewire: core: extend card->lock in fw_core_handle_bus_reset [+ + +]
Author: Niels Dossche <dossche.niels@gmail.com>
Date:   Sat Apr 9 13:12:43 2022 +0900

    firewire: core: extend card->lock in fw_core_handle_bus_reset
    
    commit a7ecbe92b9243edbe94772f6f2c854e4142a3345 upstream.
    
    card->local_node and card->bm_retries are both always accessed under
    card->lock.
    fw_core_handle_bus_reset has a check whose condition depends on
    card->local_node and whose body writes to card->bm_retries.
    Both of these accesses are not under card->lock. Move the lock acquiring
    of card->lock to before this check such that these accesses do happen
    when card->lock is held.
    fw_destroy_nodes is called inside the check.
    Since fw_destroy_nodes already acquires card->lock inside its function
    body, move this out to the callsites of fw_destroy_nodes.
    Also add a comment to indicate which locking is necessary when calling
    fw_destroy_nodes.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20220409041243.603210-4-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firewire: fix potential uaf in outbound_phy_packet_callback() [+ + +]
Author: Chengfeng Ye <cyeaa@connect.ust.hk>
Date:   Sat Apr 9 13:12:41 2022 +0900

    firewire: fix potential uaf in outbound_phy_packet_callback()
    
    commit b7c81f80246fac44077166f3e07103affe6db8ff upstream.
    
    &e->event and e point to the same address, and &e->event could
    be freed in queue_event. So there is a potential uaf issue if
    we dereference e after calling queue_event(). Fix this by adding
    a temporary variable to maintain e->client in advance, this can
    avoid the potential uaf issue.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20220409041243.603210-2-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firewire: remove check of list iterator against head past the loop body [+ + +]
Author: Jakob Koschel <jakobkoschel@gmail.com>
Date:   Sat Apr 9 13:12:42 2022 +0900

    firewire: remove check of list iterator against head past the loop body
    
    commit 9423973869bd4632ffe669f950510c49296656e0 upstream.
    
    When list_for_each_entry() completes the iteration over the whole list
    without breaking the loop, the iterator value will be a bogus pointer
    computed based on the head element.
    
    While it is safe to use the pointer to determine if it was computed
    based on the head element, either with list_entry_is_head() or
    &pos->member == head, using the iterator variable after the loop should
    be avoided.
    
    In preparation to limit the scope of a list iterator to the list
    traversal loop, use a dedicated pointer to point to the found element [1].
    
    Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1]
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20220409041243.603210-3-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
genirq: Synchronize interrupt thread startup [+ + +]
Author: Thomas Pfaff <tpfaff@pcs.com>
Date:   Mon May 2 13:28:29 2022 +0200

    genirq: Synchronize interrupt thread startup
    
    commit 8707898e22fd665bc1d7b18b809be4b56ce25bdd upstream.
    
    A kernel hang can be observed when running setserial in a loop on a kernel
    with force threaded interrupts. The sequence of events is:
    
       setserial
         open("/dev/ttyXXX")
           request_irq()
         do_stuff()
          -> serial interrupt
             -> wake(irq_thread)
                  desc->threads_active++;
         close()
           free_irq()
             kthread_stop(irq_thread)
         synchronize_irq() <- hangs because desc->threads_active != 0
    
    The thread is created in request_irq() and woken up, but does not get on a
    CPU to reach the actual thread function, which would handle the pending
    wake-up. kthread_stop() sets the should stop condition which makes the
    thread immediately exit, which in turn leaves the stale threads_active
    count around.
    
    This problem was introduced with commit 519cc8652b3a, which addressed a
    interrupt sharing issue in the PCIe code.
    
    Before that commit free_irq() invoked synchronize_irq(), which waits for
    the hard interrupt handler and also for associated threads to complete.
    
    To address the PCIe issue synchronize_irq() was replaced with
    __synchronize_hardirq(), which only waits for the hard interrupt handler to
    complete, but not for threaded handlers.
    
    This was done under the assumption, that the interrupt thread already
    reached the thread function and waits for a wake-up, which is guaranteed to
    be handled before acting on the stop condition. The problematic case, that
    the thread would not reach the thread function, was obviously overlooked.
    
    Make sure that the interrupt thread is really started and reaches
    thread_fn() before returning from __setup_irq().
    
    This utilizes the existing wait queue in the interrupt descriptor. The
    wait queue is unused for non-shared interrupts. For shared interrupts the
    usage might cause a spurious wake-up of a waiter in synchronize_irq() or the
    completion of a threaded handler might cause a spurious wake-up of the
    waiter for the ready flag. Both are harmless and have no functional impact.
    
    [ tglx: Amended changelog ]
    
    Fixes: 519cc8652b3a ("genirq: Synchronize only with single thread on free_irq()")
    Signed-off-by: Thomas Pfaff <tpfaff@pcs.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/552fe7b4-9224-b183-bb87-a8f36d335690@pcs.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpio: mvebu: drop pwm base assignment [+ + +]
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Mon Apr 11 09:23:40 2022 +0300

    gpio: mvebu: drop pwm base assignment
    
    [ Upstream commit e5f6e5d554ac274f9c8ba60078103d0425b93c19 ]
    
    pwmchip_add() unconditionally assigns the base ID dynamically. Commit
    f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
    dropped all base assignment from drivers under drivers/pwm/. It missed
    this driver. Fix that.
    
    Fixes: f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: pca953x: fix irq_stat not updated when irq is disabled (irq_mask not set) [+ + +]
Author: Puyou Lu <puyou.lu@gmail.com>
Date:   Fri May 6 16:06:30 2022 +0800

    gpio: pca953x: fix irq_stat not updated when irq is disabled (irq_mask not set)
    
    commit dba785798526a3282cc4d0f0ea751883715dbbb4 upstream.
    
    When one port's input state get inverted (eg. from low to hight) after
    pca953x_irq_setup but before setting irq_mask (by some other driver such as
    "gpio-keys"), the next inversion of this port (eg. from hight to low) will not
    be triggered any more (because irq_stat is not updated at the first time). Issue
    should be fixed after this commit.
    
    Fixes: 89ea8bbe9c3e ("gpio: pca953x.c: add interrupt handling capability")
    Signed-off-by: Puyou Lu <puyou.lu@gmail.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gpio: visconti: Fix fwnode of GPIO IRQ [+ + +]
Author: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Date:   Thu Apr 21 18:42:28 2022 +0900

    gpio: visconti: Fix fwnode of GPIO IRQ
    
    commit 171865dab096da1ab980a32eeea5d1b88cd7bc50 upstream.
    
    The fwnode of GPIO IRQ must be set to its own fwnode, not the fwnode of the
    parent IRQ. Therefore, this sets own fwnode instead of the parent IRQ fwnode to
    GPIO IRQ's.
    
    Fixes: 2ad74f40dacc ("gpio: visconti: Add Toshiba Visconti GPIO support")
    Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpiolib: of: fix bounds check for 'gpio-reserved-ranges' [+ + +]
Author: Andrei Lalaev <andrei.lalaev@emlid.com>
Date:   Fri Apr 15 10:07:11 2022 +0300

    gpiolib: of: fix bounds check for 'gpio-reserved-ranges'
    
    commit e75f88efac05bf4e107e4171d8db6d8c3937252d upstream.
    
    Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size"
    because it clears "size" bits starting from the "start" bit in the according
    bitmap. So it has to use "greater" instead of "greater or equal" when performs
    bounds check to make sure that GPIOs are in the available range.
    Previous implementation skipped ranges that include the last GPIO in
    the range.
    
    I wrote the mail to the maintainers
    (https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u)
    of the questioned DTSes (because I couldn't understand how the maintainers
    interpreted this property), but I haven't received a response.
    Since the questioned DTSes use "gpio-reserved-ranges = <0 4>"
    (i.e., the beginning of the range), this patch doesn't affect these DTSes at all.
    TBH this patch doesn't break any existing DTSes because none of them
    reserve gpios at the end of range.
    
    Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property")
    Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hinic: fix bug of wq out of bound access [+ + +]
Author: Qiao Ma <mqaio@linux.alibaba.com>
Date:   Thu Apr 28 20:30:16 2022 +0800

    hinic: fix bug of wq out of bound access
    
    commit 52b2abef450a78e25d485ac61e32f4ce86a87701 upstream.
    
    If wq has only one page, we need to check wqe rolling over page by
    compare end_idx and curr_idx, and then copy wqe to shadow wqe to
    avoid out of bound access.
    This work has been done in hinic_get_wqe, but missed for hinic_read_wqe.
    This patch fixes it, and removes unnecessary MASKED_WQE_IDX().
    
    Fixes: 7dd29ee12865 ("hinic: add sriov feature support")
    Signed-off-by: Qiao Ma <mqaio@linux.alibaba.com>
    Reviewed-by: Xunlei Pang <xlpang@linux.alibaba.com>
    Link: https://lore.kernel.org/r/282817b0e1ae2e28fdf3ed8271a04e77f57bf42e.1651148587.git.mqaio@linux.alibaba.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hwmon: (adt7470) Fix warning on module removal [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Thu Apr 7 12:13:12 2022 +0200

    hwmon: (adt7470) Fix warning on module removal
    
    commit 7b2666ce445c700b8dcee994da44ddcf050a0842 upstream.
    
    When removing the adt7470 module, a warning might be printed:
    
    do not call blocking ops when !TASK_RUNNING; state=1
    set at [<ffffffffa006052b>] adt7470_update_thread+0x7b/0x130 [adt7470]
    
    This happens because adt7470_update_thread() can leave the kthread in
    TASK_INTERRUPTIBLE state when the kthread is being stopped before
    the call of set_current_state(). Since kthread_exit() might sleep in
    exit_signals(), the warning is printed.
    Fix that by using schedule_timeout_interruptible() and removing
    the call of set_current_state().
    This causes TASK_INTERRUPTIBLE to be set after kthread_should_stop()
    which might cause the kthread to exit.
    
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Fixes: 93cacfd41f82 (hwmon: (adt7470) Allow faster removal)
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Tested-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/20220407101312.13331-1-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hwmon: (pmbus) delta-ahe50dc-fan: work around hardware quirk [+ + +]
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Tue Apr 26 20:51:09 2022 -0700

    hwmon: (pmbus) delta-ahe50dc-fan: work around hardware quirk
    
    commit 08da09f028043fed9653331ae75bc310411f72e6 upstream.
    
    CLEAR_FAULTS commands can apparently sometimes trigger catastrophic
    power output glitches on the ahe-50dc, so block them from being sent
    at all.
    
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220427035109.3819-1-zev@bewilderbeest.net
    Fixes: d387d88ed045 ("hwmon: (pmbus) Add Delta AHE-50DC fan control module driver")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hwmon: (pmbus) disable PEC if not enabled [+ + +]
Author: Adam Wujek <dev_public@wujek.eu>
Date:   Wed Apr 20 14:51:25 2022 +0000

    hwmon: (pmbus) disable PEC if not enabled
    
    commit 75d2b2b06bd8407d03a3f126bc8b95eb356906c7 upstream.
    
    Explicitly disable PEC when the client does not support it.
    The problematic scenario is the following. A device with enabled PEC
    support is up and running and a kernel driver is loaded.
    Then the driver is unloaded (or device unbound), the HW device
    is reconfigured externally (e.g. by i2cset) to advertise itself as not
    supporting PEC. Without a new code, at the second load of the driver
    (or bind) the "flags" variable is not updated to avoid PEC usage. As a
    consequence the further communication with the device is done with
    the PEC enabled, which is wrong and may fail.
    
    The implementation first disable the I2C_CLIENT_PEC flag, then the old
    code enable it if needed.
    
    Fixes: 4e5418f787ec ("hwmon: (pmbus_core) Check adapter PEC support")
    Signed-off-by: Adam Wujek <dev_public@wujek.eu>
    Link: https://lore.kernel.org/r/20220420145059.431061-1-dev_public@wujek.eu
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range() [+ + +]
Author: Nicolin Chen <nicolinc@nvidia.com>
Date:   Tue Apr 19 14:01:58 2022 -0700

    iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range()
    
    commit 95d4782c34a60800ccf91d9f0703137d4367a2fc upstream.
    
    The arm_smmu_mm_invalidate_range function is designed to be called
    by mm core for Shared Virtual Addressing purpose between IOMMU and
    CPU MMU. However, the ways of two subsystems defining their "end"
    addresses are slightly different. IOMMU defines its "end" address
    using the last address of an address range, while mm core defines
    that using the following address of an address range:
    
            include/linux/mm_types.h:
                    unsigned long vm_end;
                    /* The first byte after our end address ...
    
    This mismatch resulted in an incorrect calculation for size so it
    failed to be page-size aligned. Further, it caused a dead loop at
    "while (iova < end)" check in __arm_smmu_tlb_inv_range function.
    
    This patch fixes the issue by doing the calculation correctly.
    
    Fixes: 2f7e8c553e98 ("iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Link: https://lore.kernel.org/r/20220419210158.21320-1-nicolinc@nvidia.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/dart: Add missing module owner to ops structure [+ + +]
Author: Hector Martin <marcan@marcan.st>
Date:   Mon May 2 18:22:38 2022 +0900

    iommu/dart: Add missing module owner to ops structure
    
    [ Upstream commit 2ac2fab52917ae82cbca97cf6e5d2993530257ed ]
    
    This is required to make loading this as a module work.
    
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Fixes: 46d1fb072e76 ("iommu/dart: Add DART iommu driver")
    Reviewed-by: Sven Peter <sven@svenpeter.dev>
    Link: https://lore.kernel.org/r/20220502092238.30486-1-marcan@marcan.st
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/dart: check return value after calling platform_get_resource() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Apr 25 17:08:26 2022 +0800

    iommu/dart: check return value after calling platform_get_resource()
    
    commit a15932f4377062364d22096afe25bc579134a1c3 upstream.
    
    It will cause null-ptr-deref in resource_size(), if platform_get_resource()
    returns NULL, move calling resource_size() after devm_ioremap_resource() that
    will check 'res' to avoid null-ptr-deref.
    And use devm_platform_get_and_ioremap_resource() to simplify code.
    
    Fixes: 46d1fb072e76 ("iommu/dart: Add DART iommu driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Sven Peter <sven@svenpeter.dev>
    Link: https://lore.kernel.org/r/20220425090826.2532165-1-yangyingliang@huawei.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/vt-d: Calculate mask for non-aligned flushes [+ + +]
Author: David Stevens <stevensd@chromium.org>
Date:   Sun Apr 10 09:35:33 2022 +0800

    iommu/vt-d: Calculate mask for non-aligned flushes
    
    commit 59bf3557cf2f8a469a554aea1e3d2c8e72a579f7 upstream.
    
    Calculate the appropriate mask for non-size-aligned page selective
    invalidation. Since psi uses the mask value to mask out the lower order
    bits of the target address, properly flushing the iotlb requires using a
    mask value such that [pfn, pfn+pages) all lie within the flushed
    size-aligned region.  This is not normally an issue because iova.c
    always allocates iovas that are aligned to their size. However, iovas
    which come from other sources (e.g. userspace via VFIO) may not be
    aligned.
    
    To properly flush the IOTLB, both the start and end pfns need to be
    equal after applying the mask. That means that the most efficient mask
    to use is the index of the lowest bit that is equal where all higher
    bits are also equal. For example, if pfn=0x17f and pages=3, then
    end_pfn=0x181, so the smallest mask we can use is 8. Any differences
    above the highest bit of pages are due to carrying, so by xnor'ing pfn
    and end_pfn and then masking out the lower order bits based on pages, we
    get 0xffffff00, where the first set bit is the mask we want to use.
    
    Fixes: 6fe1010d6d9c ("vfio/type1: DMA unmap chunking")
    Cc: stable@vger.kernel.org
    Signed-off-by: David Stevens <stevensd@chromium.org>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20220401022430.1262215-1-stevensd@google.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20220410013533.3959168-2-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu/vt-d: Drop stop marker messages [+ + +]
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Sat Apr 23 16:23:30 2022 +0800

    iommu/vt-d: Drop stop marker messages
    
    commit da8669ff41fa31573375c9a4180f5c080677204b upstream.
    
    The page fault handling framework in the IOMMU core explicitly states
    that it doesn't handle PCI PASID Stop Marker and the IOMMU drivers must
    discard them before reporting faults. This handles Stop Marker messages
    in prq_event_thread() before reporting events to the core.
    
    The VT-d driver explicitly drains the pending page requests when a CPU
    page table (represented by a mm struct) is unbound from a PASID according
    to the procedures defined in the VT-d spec. The Stop Marker messages do
    not need a response. Hence, it is safe to drop the Stop Marker messages
    silently if any of them is found in the page request queue.
    
    Fixes: d5b9e4bfe0d88 ("iommu/vt-d: Report prq to io-pgfault framework")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20220421113558.3504874-1-baolu.lu@linux.intel.com
    Link: https://lore.kernel.org/r/20220423082330.3897867-2-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ipmi: When handling send message responses, don't process the message [+ + +]
Author: Corey Minyard <cminyard@mvista.com>
Date:   Tue Apr 19 12:08:09 2022 -0500

    ipmi: When handling send message responses, don't process the message
    
    commit 3d092ef09303e615707dc5755cf0e29b4df7555f upstream.
    
    A chunk was dropped when the code handling send messages was rewritten.
    Those messages shouldn't be processed normally, they are just an
    indication that the message was successfully sent and the timers should
    be started for the real response that should be coming later.
    
    Add back in the missing chunk to just discard the message and go on.
    
    Fixes: 059747c245f0 ("ipmi: Add support for IPMB direct messages")
    Reported-by: Joe Wiese <jwiese@rackspace.com>
    Cc: stable@vger.kernel.org # v5.16+
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Tested-by: Joe Wiese <jwiese@rackspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: ipmi:ipmi_ipmb: Fix null-ptr-deref in ipmi_unregister_smi() [+ + +]
Author: Corey Minyard <cminyard@mvista.com>
Date:   Thu Apr 21 06:49:43 2022 -0500

    ipmi:ipmi_ipmb: Fix null-ptr-deref in ipmi_unregister_smi()
    
    commit 9cc3aac42566a0021e0ab7c4e9b31667ad75b1e3 upstream.
    
    KASAN report null-ptr-deref as follows:
    
    KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    RIP: 0010:ipmi_unregister_smi+0x7d/0xd50 drivers/char/ipmi/ipmi_msghandler.c:3680
    Call Trace:
     ipmi_ipmb_remove+0x138/0x1a0 drivers/char/ipmi/ipmi_ipmb.c:443
     ipmi_ipmb_probe+0x409/0xda1 drivers/char/ipmi/ipmi_ipmb.c:548
     i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563
     really_probe+0x3f3/0xa70 drivers/base/dd.c:541
    
    In ipmi_ipmb_probe(), 'iidev->intf' is not set before
    ipmi_register_smi() success.  And in the error handling case,
    ipmi_ipmb_remove() is called to release resources, ipmi_unregister_smi()
    is called without check 'iidev->intf', this will cause KASAN
    null-ptr-deref issue.
    
    General kernel style is to allow NULL to be passed into unregister
    calls, so fix it that way.  This allows a NULL check to be removed in
    other code.
    
    Fixes: 57c9e3c9a374 ("ipmi:ipmi_ipmb: Unregister the SMI on remove")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Cc: stable@vger.kernel.org # v5.17+
    Cc: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: LAPIC: Enable timer posted-interrupt only when mwait/hlt is advertised [+ + +]
Author: Wanpeng Li <wanpengli@tencent.com>
Date:   Tue Jan 25 04:08:58 2022 -0800

    KVM: LAPIC: Enable timer posted-interrupt only when mwait/hlt is advertised
    
    [ Upstream commit 1714a4eb6fb0cb79f182873cd011a8ed60ac65e8 ]
    
    As commit 0c5f81dad46 ("KVM: LAPIC: Inject timer interrupt via posted
    interrupt") mentioned that the host admin should well tune the guest
    setup, so that vCPUs are placed on isolated pCPUs, and with several pCPUs
    surplus for *busy* housekeeping.  In this setup, it is preferrable to
    disable mwait/hlt/pause vmexits to keep the vCPUs in non-root mode.
    
    However, if only some guests isolated and others not, they would not
    have any benefit from posted timer interrupts, and at the same time lose
    VMX preemption timer fast paths because kvm_can_post_timer_interrupt()
    returns true and therefore forces kvm_can_use_hv_timer() to false.
    
    By guaranteeing that posted-interrupt timer is only used if MWAIT or
    HLT are done without vmexit, KVM can make a better choice and use the
    VMX preemption timer and the corresponding fast paths.
    
    Reported-by: Aili Yao <yaoaili@kingsoft.com>
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Cc: Aili Yao <yaoaili@kingsoft.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
    Message-Id: <1643112538-36743-1-git-send-email-wanpengli@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kvm: selftests: do not use bitfields larger than 32-bits for PTEs [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed Apr 20 06:27:27 2022 -0400

    kvm: selftests: do not use bitfields larger than 32-bits for PTEs
    
    [ Upstream commit f18b4aebe107d092e384b1ae680b1e1de7a0196d ]
    
    Red Hat's QE team reported test failure on access_tracking_perf_test:
    
    Testing guest mode: PA-bits:ANY, VA-bits:48,  4K pages
    guest physical test memory offset: 0x3fffbffff000
    
    Populating memory             : 0.684014577s
    Writing to populated memory   : 0.006230175s
    Reading from populated memory : 0.004557805s
    ==== Test Assertion Failure ====
      lib/kvm_util.c:1411: false
      pid=125806 tid=125809 errno=4 - Interrupted system call
         1  0x0000000000402f7c: addr_gpa2hva at kvm_util.c:1411
         2   (inlined by) addr_gpa2hva at kvm_util.c:1405
         3  0x0000000000401f52: lookup_pfn at access_tracking_perf_test.c:98
         4   (inlined by) mark_vcpu_memory_idle at access_tracking_perf_test.c:152
         5   (inlined by) vcpu_thread_main at access_tracking_perf_test.c:232
         6  0x00007fefe9ff81ce: ?? ??:0
         7  0x00007fefe9c64d82: ?? ??:0
      No vm physical memory at 0xffbffff000
    
    I can easily reproduce it with a Intel(R) Xeon(R) CPU E5-2630 with 46 bits
    PA.
    
    It turns out that the address translation for clearing idle page tracking
    returned a wrong result; addr_gva2gpa()'s last step, which is based on
    "pte[index[0]].pfn", did the calculation with 40 bits length and the
    high 12 bits got truncated.  In above case the GPA address to be returned
    should be 0x3fffbffff000 for GVA 0xc0000000, but it got truncated into
    0xffbffff000 and the subsequent gpa2hva lookup failed.
    
    The width of operations on bit fields greater than 32-bit is
    implementation defined, and differs between GCC (which uses the bitfield
    precision) and clang (which uses 64-bit arithmetic), so this is a
    potential minefield.  Remove the bit fields and using manual masking
    instead.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2075036
    Reported-by: Nana Liu <nanliu@redhat.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Tested-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: selftests: Silence compiler warning in the kvm_page_table_test [+ + +]
Author: Thomas Huth <thuth@redhat.com>
Date:   Thu Apr 14 12:30:31 2022 +0200

    KVM: selftests: Silence compiler warning in the kvm_page_table_test
    
    [ Upstream commit 266a19a0bc4fbfab4d981a47640ca98972a01865 ]
    
    When compiling kvm_page_table_test.c, I get this compiler warning
    with gcc 11.2:
    
    kvm_page_table_test.c: In function 'pre_init_before_test':
    ../../../../tools/include/linux/kernel.h:44:24: warning: comparison of
     distinct pointer types lacks a cast
       44 |         (void) (&_max1 == &_max2);              \
          |                        ^~
    kvm_page_table_test.c:281:21: note: in expansion of macro 'max'
      281 |         alignment = max(0x100000, alignment);
          |                     ^~~
    
    Fix it by adjusting the type of the absolute value.
    
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Message-Id: <20220414103031.565037-1-thuth@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: SEV: Mark nested locking of vcpu->lock [+ + +]
Author: Peter Gonda <pgonda@google.com>
Date:   Mon May 2 09:58:07 2022 -0700

    KVM: SEV: Mark nested locking of vcpu->lock
    
    [ Upstream commit 0c2c7c069285374fc8feacddc0498f8ab7627117 ]
    
    svm_vm_migrate_from() uses sev_lock_vcpus_for_migration() to lock all
    source and target vcpu->locks. Unfortunately there is an 8 subclass
    limit, so a new subclass cannot be used for each vCPU. Instead maintain
    ownership of the first vcpu's mutex.dep_map using a role specific
    subclass: source vs target. Release the other vcpu's mutex.dep_maps.
    
    Fixes: b56639318bb2b ("KVM: SEV: Add support for SEV intra host migration")
    Reported-by: John Sperbeck<jsperbeck@google.com>
    Suggested-by: David Rientjes <rientjes@google.com>
    Suggested-by: Sean Christopherson <seanjc@google.com>
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: kvm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Peter Gonda <pgonda@google.com>
    
    Message-Id: <20220502165807.529624-1-pgonda@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Exit to userspace if vCPU has injected exception and invalid state [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Mon May 2 22:18:50 2022 +0000

    KVM: VMX: Exit to userspace if vCPU has injected exception and invalid state
    
    [ Upstream commit 053d2290c0307e3642e75e0185ddadf084dc36c1 ]
    
    Exit to userspace with an emulation error if KVM encounters an injected
    exception with invalid guest state, in addition to the existing check of
    bailing if there's a pending exception (KVM doesn't support emulating
    exceptions except when emulating real mode via vm86).
    
    In theory, KVM should never get to such a situation as KVM is supposed to
    exit to userspace before injecting an exception with invalid guest state.
    But in practice, userspace can intervene and manually inject an exception
    and/or stuff registers to force invalid guest state while a previously
    injected exception is awaiting reinjection.
    
    Fixes: fc4fad79fc3d ("KVM: VMX: Reject KVM_RUN if emulation is required with pending exception")
    Reported-by: syzbot+cfafed3bb76d3e37581b@syzkaller.appspotmail.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220502221850.131873-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kvm: x86/cpuid: Only provide CPUID leaf 0xA if host has architectural PMU [+ + +]
Author: Sandipan Das <sandipan.das@amd.com>
Date:   Wed Apr 27 17:01:49 2022 +0530

    kvm: x86/cpuid: Only provide CPUID leaf 0xA if host has architectural PMU
    
    [ Upstream commit 5a1bde46f98b893cda6122b00e94c0c40a6ead3c ]
    
    On some x86 processors, CPUID leaf 0xA provides information
    on Architectural Performance Monitoring features. It
    advertises a PMU version which Qemu uses to determine the
    availability of additional MSRs to manage the PMCs.
    
    Upon receiving a KVM_GET_SUPPORTED_CPUID ioctl request for
    the same, the kernel constructs return values based on the
    x86_pmu_capability irrespective of the vendor.
    
    This leaf and the additional MSRs are not supported on AMD
    and Hygon processors. If AMD PerfMonV2 is detected, the PMU
    version is set to 2 and guest startup breaks because of an
    attempt to access a non-existent MSR. Return zeros to avoid
    this.
    
    Fixes: a6c06ed1a60a ("KVM: Expose the architectural performance monitoring CPUID leaf")
    Reported-by: Vasant Hegde <vasant.hegde@amd.com>
    Signed-off-by: Sandipan Das <sandipan.das@amd.com>
    Message-Id: <3fef83d9c2b2f7516e8ff50d60851f29a4bcb716.1651058600.git.sandipan.das@amd.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: x86/mmu: avoid NULL-pointer dereference on page freeing bugs [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Feb 8 19:08:33 2022 -0500

    KVM: x86/mmu: avoid NULL-pointer dereference on page freeing bugs
    
    [ Upstream commit 9191b8f0745e63edf519e4a54a4aaae1d3d46fbd ]
    
    WARN and bail if KVM attempts to free a root that isn't backed by a shadow
    page.  KVM allocates a bare page for "special" roots, e.g. when using PAE
    paging or shadowing 2/3/4-level page tables with 4/5-level, and so root_hpa
    will be valid but won't be backed by a shadow page.  It's all too easy to
    blindly call mmu_free_root_page() on root_hpa, be nice and WARN instead of
    crashing KVM and possibly the kernel.
    
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/svm: Account for family 17h event renumberings in amd_pmc_perf_hw_id [+ + +]
Author: Kyle Huey <me@kylehuey.com>
Date:   Mon May 2 22:01:36 2022 -0700

    KVM: x86/svm: Account for family 17h event renumberings in amd_pmc_perf_hw_id
    
    commit 5eb849322d7f7ae9d5c587c7bc3b4f7c6872cd2f upstream.
    
    Zen renumbered some of the performance counters that correspond to the
    well known events in perf_hw_id. This code in KVM was never updated for
    that, so guest that attempt to use counters on Zen that correspond to the
    pre-Zen perf_hw_id values will silently receive the wrong values.
    
    This has been observed in the wild with rr[0] when running in Zen 3
    guests. rr uses the retired conditional branch counter 00d1 which is
    incorrectly recognized by KVM as PERF_COUNT_HW_STALLED_CYCLES_BACKEND.
    
    [0] https://rr-project.org/
    
    Signed-off-by: Kyle Huey <me@kylehuey.com>
    Message-Id: <20220503050136.86298-1-khuey@kylehuey.com>
    Cc: stable@vger.kernel.org
    [Check guest family, not host. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Do not change ICR on write to APIC_SELF_IPI [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Feb 24 09:53:36 2022 -0500

    KVM: x86: Do not change ICR on write to APIC_SELF_IPI
    
    [ Upstream commit d22a81b304a27fca6124174a8e842e826c193466 ]
    
    Emulating writes to SELF_IPI with a write to ICR has an unwanted side effect:
    the value of ICR in vAPIC page gets changed.  The lists SELF_IPI as write-only,
    with no associated MMIO offset, so any write should have no visible side
    effect in the vAPIC page.
    
    Reported-by: Chao Gao <chao.gao@intel.com>
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.17.7 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 12 12:32:48 2022 +0200

    Linux 5.17.7
    
    Link: https://lore.kernel.org/r/20220510130741.600270947@linuxfoundation.org
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Slade Watkins <slade@sladewatkins.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Zan Aziz <zanaziz313@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Fenil Jain<fkjainco@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
MIPS: Fix CP0 counter erratum detection for R4k CPUs [+ + +]
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Sun Apr 24 12:46:23 2022 +0100

    MIPS: Fix CP0 counter erratum detection for R4k CPUs
    
    commit f0a6c68f69981214cb7858738dd2bc81475111f7 upstream.
    
    Fix the discrepancy between the two places we check for the CP0 counter
    erratum in along with the incorrect comparison of the R4400 revision
    number against 0x30 which matches none and consistently consider all
    R4000 and R4400 processors affected, as documented in processor errata
    publications[1][2][3], following the mapping between CP0 PRId register
    values and processor models:
    
      PRId   |  Processor Model
    ---------+--------------------
    00000422 | R4000 Revision 2.2
    00000430 | R4000 Revision 3.0
    00000440 | R4400 Revision 1.0
    00000450 | R4400 Revision 2.0
    00000460 | R4400 Revision 3.0
    
    No other revision of either processor has ever been spotted.
    
    Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume
    R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the
    CP0 counter as buggy does not preclude it from being used as either a
    clock event or a clock source device.  It just cannot be used as both at
    a time, because in that case clock event interrupts will be occasionally
    lost, and the use as a clock event device takes precedence.
    
    Compare against 0x4ff in `can_use_mips_counter' so that a single machine
    instruction is produced.
    
    References:
    
    [1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS
        Technologies Inc., May 10, 1994, Erratum 53, p.13
    
    [2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies
        Inc., February 9, 1994, Erratum 21, p.4
    
    [3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS
        Technologies Inc., January 24, 1995, Erratum 14, p.3
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug")
    Cc: stable@vger.kernel.org # v2.6.24+
    Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mld: respect RCU rules in ip6_mc_source() and ip6_mc_msfilter() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 29 09:20:36 2022 -0700

    mld: respect RCU rules in ip6_mc_source() and ip6_mc_msfilter()
    
    commit a9384a4c1d250cb40cebf50e41459426d160b08e upstream.
    
    Whenever RCU protected list replaces an object,
    the pointer to the new object needs to be updated
    _before_ the call to kfree_rcu() or call_rcu()
    
    Also ip6_mc_msfilter() needs to update the pointer
    before releasing the mc_lock mutex.
    
    Note that linux-5.13 was supporting kfree_rcu(NULL, rcu),
    so this fix does not need the conditional test I was
    forced to use in the equivalent patch for IPv4.
    
    Fixes: 882ba1f73c06 ("mld: convert ipv6_mc_socklist->sflist to RCU")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: core: Set HS clock speed before sending HS CMD13 [+ + +]
Author: Brian Norris <briannorris@chromium.org>
Date:   Fri Apr 22 10:08:53 2022 -0700

    mmc: core: Set HS clock speed before sending HS CMD13
    
    commit 4bc31edebde51fcf8ad0794763b8679a7ecb5ec0 upstream.
    
    Way back in commit 4f25580fb84d ("mmc: core: changes frequency to
    hs_max_dtr when selecting hs400es"), Rockchip engineers noticed that
    some eMMC don't respond to SEND_STATUS commands very reliably if they're
    still running at a low initial frequency. As mentioned in that commit,
    JESD84-B51 P49 suggests a sequence in which the host:
    1. sets HS_TIMING
    2. bumps the clock ("<= 52 MHz")
    3. sends further commands
    
    It doesn't exactly require that we don't use a lower-than-52MHz
    frequency, but in practice, these eMMC don't like it.
    
    The aforementioned commit tried to get that right for HS400ES, although
    it's unclear whether this ever truly worked as committed into mainline,
    as other changes/refactoring adjusted the sequence in conflicting ways:
    
    08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode
    switch")
    
    53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode
    for mmc")
    
    In any case, today we do step 3 before step 2. Let's fix that, and also
    apply the same logic to HS200/400, where this eMMC has problems too.
    
    Resolves errors like this seen when booting some RK3399 Gru/Scarlet
    systems:
    
    [    2.058881] mmc1: CQHCI version 5.10
    [    2.097545] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
    [    2.209804] mmc1: mmc_select_hs400es failed, error -84
    [    2.215597] mmc1: error -84 whilst initialising MMC card
    [    2.417514] mmc1: mmc_select_hs400es failed, error -110
    [    2.423373] mmc1: error -110 whilst initialising MMC card
    [    2.605052] mmc1: mmc_select_hs400es failed, error -110
    [    2.617944] mmc1: error -110 whilst initialising MMC card
    [    2.835884] mmc1: mmc_select_hs400es failed, error -110
    [    2.841751] mmc1: error -110 whilst initialising MMC card
    
    Ealier versions of this patch bumped to 200MHz/HS200 speeds too early,
    which caused issues on, e.g., qcom-msm8974-fairphone-fp2. (Thanks for
    the report Luca!) After a second look, it appears that aligns with
    JESD84 / page 45 / table 28, so we need to keep to lower (HS / 52 MHz)
    rates first.
    
    Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch")
    Fixes: 53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode for mmc")
    Fixes: 4f25580fb84d ("mmc: core: changes frequency to hs_max_dtr when selecting hs400es")
    Cc: Shawn Lin <shawn.lin@rock-chips.com>
    Link: https://lore.kernel.org/linux-mmc/11962455.O9o76ZdvQC@g550jk/
    Reported-by: Luca Weiss <luca@z3ntu.xyz>
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Tested-by: Luca Weiss <luca@z3ntu.xyz>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220422100824.v4.1.I484f4ee35609f78b932bd50feed639c29e64997e@changeid
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: rtsx: add 74 Clocks in power on flow [+ + +]
Author: Ricky WU <ricky_wu@realtek.com>
Date:   Wed Mar 2 09:43:01 2022 +0000

    mmc: rtsx: add 74 Clocks in power on flow
    
    commit 1f311c94aabdb419c28e3147bcc8ab89269f1a7e upstream.
    
    SD spec definition:
    "Host provides at least 74 Clocks before issuing first command"
    After 1ms for the voltage stable then start issuing the Clock signals
    
    if POWER STATE is
    MMC_POWER_OFF to MMC_POWER_UP to issue Clock signal to card
    MMC_POWER_UP to MMC_POWER_ON to stop issuing signal to card
    
    Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
    Link: https://lore.kernel.org/r/1badf10aba764191a1a752edcbf90389@realtek.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Cc: Christian Löhle <CLoehle@hyperstone.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC [+ + +]
Author: Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com>
Date:   Sun Apr 24 21:32:33 2022 +0530

    mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
    
    commit 3e5a8e8494a8122fe4eb3f167662f406cab753b9 upstream.
    
    Reset GCC_SDCC_BCR register before every fresh initilazation. This will
    reset whole SDHC-msm controller, clears the previous power control
    states and avoids, software reset timeout issues as below.
    
    [ 5.458061][ T262] mmc1: Reset 0x1 never completed.
    [ 5.462454][ T262] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
    [ 5.469065][ T262] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00007202
    [ 5.475688][ T262] mmc1: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
    [ 5.482315][ T262] mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
    [ 5.488927][ T262] mmc1: sdhci: Present: 0x01f800f0 | Host ctl: 0x00000000
    [ 5.495539][ T262] mmc1: sdhci: Power: 0x00000000 | Blk gap: 0x00000000
    [ 5.502162][ T262] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000003
    [ 5.508768][ T262] mmc1: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
    [ 5.515381][ T262] mmc1: sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000
    [ 5.521996][ T262] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
    [ 5.528607][ T262] mmc1: sdhci: Caps: 0x362dc8b2 | Caps_1: 0x0000808f
    [ 5.535227][ T262] mmc1: sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
    [ 5.541841][ T262] mmc1: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
    [ 5.548454][ T262] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
    [ 5.555079][ T262] mmc1: sdhci: Host ctl2: 0x00000000
    [ 5.559651][ T262] mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP-----------
    [ 5.566621][ T262] mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000
    [ 5.575465][ T262] mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00010800 | DDR cfg: 0x80040873
    [ 5.584658][ T262] mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040
    
    Fixes: 0eb0d9f4de34 ("mmc: sdhci-msm: Initial support for Qualcomm chipsets")
    Signed-off-by: Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Tested-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1650816153-23797-1-git-send-email-quic_c_sbhanu@quicinc.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sunxi-mmc: Fix DMA descriptors allocated above 32 bits [+ + +]
Author: Samuel Holland <samuel@sholland.org>
Date:   Sun Apr 24 18:17:50 2022 -0500

    mmc: sunxi-mmc: Fix DMA descriptors allocated above 32 bits
    
    commit e9f3fb523dbf476dc86beea23f5b5ca8f9687c93 upstream.
    
    Newer variants of the MMC controller support a 34-bit physical address
    space by using word addresses instead of byte addresses. However, the
    code truncates the DMA descriptor address to 32 bits before applying the
    shift. This breaks DMA for descriptors allocated above the 32-bit limit.
    
    Fixes: 3536b82e5853 ("mmc: sunxi: add support for A100 mmc controller")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220424231751.32053-1-samuel@sholland.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: Avoid double clear or set of sync reset requested [+ + +]
Author: Moshe Shemesh <moshe@nvidia.com>
Date:   Mon Apr 11 20:38:44 2022 +0300

    net/mlx5: Avoid double clear or set of sync reset requested
    
    commit fc3d3db07b35885f238e1fa06b9f04a8fa7a62d0 upstream.
    
    Double clear of reset requested state can lead to NULL pointer as it
    will try to delete the timer twice. This can happen for example on a
    race between abort from FW and pci error or reset. Avoid such case using
    test_and_clear_bit() to verify only one time reset requested state clear
    flow. Similarly use test_and_set_bit() to verify only one time reset
    requested state set flow.
    
    Fixes: 7dd6df329d4c ("net/mlx5: Handle sync reset abort event")
    Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
    Reviewed-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5: Fix deadlock in sync reset flow [+ + +]
Author: Moshe Shemesh <moshe@nvidia.com>
Date:   Mon Apr 11 21:31:06 2022 +0300

    net/mlx5: Fix deadlock in sync reset flow
    
    commit cb7786a76ea39f394f0a059787fe24fa8e340fb6 upstream.
    
    The sync reset flow can lead to the following deadlock when
    poll_sync_reset() is called by timer softirq and waiting on
    del_timer_sync() for the same timer. Fix that by moving the part of the
    flow that waits for the timer to reset_reload_work.
    
    It fixes the following kernel Trace:
    RIP: 0010:del_timer_sync+0x32/0x40
    ...
    Call Trace:
     <IRQ>
     mlx5_sync_reset_clear_reset_requested+0x26/0x50 [mlx5_core]
     poll_sync_reset.cold+0x36/0x52 [mlx5_core]
     call_timer_fn+0x32/0x130
     __run_timers.part.0+0x180/0x280
     ? tick_sched_handle+0x33/0x60
     ? tick_sched_timer+0x3d/0x80
     ? ktime_get+0x3e/0xa0
     run_timer_softirq+0x2a/0x50
     __do_softirq+0xe1/0x2d6
     ? hrtimer_interrupt+0x136/0x220
     irq_exit+0xae/0xb0
     smp_apic_timer_interrupt+0x7b/0x140
     apic_timer_interrupt+0xf/0x20
     </IRQ>
    
    Fixes: 3c5193a87b0f ("net/mlx5: Use del_timer_sync in fw reset flow of halting poll")
    Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5: Fix matching on inner TTC [+ + +]
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Sun Apr 10 11:58:05 2022 +0000

    net/mlx5: Fix matching on inner TTC
    
    commit a042d7f5bb68c47f6e0e546ca367d14e1e4b25ba upstream.
    
    The cited commits didn't use proper matching on inner TTC
    as a result distribution of encapsulated packets wasn't symmetric
    between the physical ports.
    
    Fixes: 4c71ce50d2fe ("net/mlx5: Support partial TTC rules")
    Fixes: 8e25a2bc6687 ("net/mlx5: Lag, add support to create TTC tables for LAG port selection")
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5: Fix slab-out-of-bounds while reading resource dump menu [+ + +]
Author: Aya Levin <ayal@nvidia.com>
Date:   Thu Mar 3 19:02:03 2022 +0200

    net/mlx5: Fix slab-out-of-bounds while reading resource dump menu
    
    commit 7ba2d9d8de96696c1451fee1b01da11f45bdc2b9 upstream.
    
    Resource dump menu may span over more than a single page, support it.
    Otherwise, menu read may result in a memory access violation: reading
    outside of the allocated page.
    Note that page format of the first menu page contains menu headers while
    the proceeding menu pages contain only records.
    
    The KASAN logs are as follows:
    BUG: KASAN: slab-out-of-bounds in strcmp+0x9b/0xb0
    Read of size 1 at addr ffff88812b2e1fd0 by task systemd-udevd/496
    
    CPU: 5 PID: 496 Comm: systemd-udevd Tainted: G    B  5.16.0_for_upstream_debug_2022_01_10_23_12 #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x57/0x7d
     print_address_description.constprop.0+0x1f/0x140
     ? strcmp+0x9b/0xb0
     ? strcmp+0x9b/0xb0
     kasan_report.cold+0x83/0xdf
     ? strcmp+0x9b/0xb0
     strcmp+0x9b/0xb0
     mlx5_rsc_dump_init+0x4ab/0x780 [mlx5_core]
     ? mlx5_rsc_dump_destroy+0x80/0x80 [mlx5_core]
     ? lockdep_hardirqs_on_prepare+0x286/0x400
     ? raw_spin_unlock_irqrestore+0x47/0x50
     ? aomic_notifier_chain_register+0x32/0x40
     mlx5_load+0x104/0x2e0 [mlx5_core]
     mlx5_init_one+0x41b/0x610 [mlx5_core]
     ....
    The buggy address belongs to the object at ffff88812b2e0000
     which belongs to the cache kmalloc-4k of size 4096
    The buggy address is located 4048 bytes to the right of
     4096-byte region [ffff88812b2e0000, ffff88812b2e1000)
    The buggy address belongs to the page:
    page:000000009d69807a refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88812b2e6000 pfn:0x12b2e0
    head:000000009d69807a order:3 compound_mapcount:0 compound_pincount:0
    flags: 0x8000000000010200(slab|head|zone=2)
    raw: 8000000000010200 0000000000000000 dead000000000001 ffff888100043040
    raw: ffff88812b2e6000 0000000080040000 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88812b2e1e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88812b2e1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff88812b2e1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                     ^
     ffff88812b2e2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88812b2e2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 12206b17235a ("net/mlx5: Add support for resource dump")
    Signed-off-by: Aya Levin <ayal@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5e: CT: Fix queued up restore put() executing after relevant ft release [+ + +]
Author: Paul Blakey <paulb@nvidia.com>
Date:   Tue Mar 29 17:42:46 2022 +0300

    net/mlx5e: CT: Fix queued up restore put() executing after relevant ft release
    
    commit b069e14fff46c8da9fcc79957f8acaa3e2dfdb6b upstream.
    
    __mlx5_tc_ct_entry_put() queues release of tuple related to some ct FT,
    if that is the last reference to that tuple, the actual deletion of
    the tuple can happen after the FT is already destroyed and freed.
    
    Flush the used workqueue before destroying the ct FT.
    
    Fixes: a2173131526d ("net/mlx5e: CT: manage the lifetime of the ct entry object")
    Reviewed-by: Oz Shlomo <ozsh@nvidia.com>
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Don't match double-vlan packets if cvlan is not set [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Mon Mar 28 15:54:52 2022 +0300

    net/mlx5e: Don't match double-vlan packets if cvlan is not set
    
    commit ada09af92e621ab500dd80a16d1d0299a18a1180 upstream.
    
    Currently, match VLAN rule also matches packets that have multiple VLAN
    headers. This behavior is similar to buggy flower classifier behavior that
    has recently been fixed. Fix the issue by matching on
    outer_second_cvlan_tag with value 0 which will cause the HW to verify the
    packet doesn't contain second vlan header.
    
    Fixes: 699e96ddf47f ("net/mlx5e: Support offloading tc double vlan headers match")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Fix the calling of update_buffer_lossy() API [+ + +]
Author: Mark Zhang <markzhang@nvidia.com>
Date:   Wed Apr 6 10:30:21 2022 +0300

    net/mlx5e: Fix the calling of update_buffer_lossy() API
    
    commit c4d963a588a6e7c4ef31160e80697ae8e5a47746 upstream.
    
    The arguments of update_buffer_lossy() is in a wrong order. Fix it.
    
    Fixes: 88b3d5c90e96 ("net/mlx5e: Fix port buffers cell size value")
    Signed-off-by: Mark Zhang <markzhang@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Fix trust state reset in reload [+ + +]
Author: Moshe Tal <moshet@nvidia.com>
Date:   Wed Feb 9 19:23:56 2022 +0200

    net/mlx5e: Fix trust state reset in reload
    
    commit b781bff882d16175277ca129c382886cb4c74a2c upstream.
    
    Setting dscp2prio during the driver reload can cause dcb ieee app list to
    be not empty after the reload finish and as a result to a conflict between
    the priority trust state reported by the app and the state in the device
    register.
    
    Reset the dcb ieee app list on initialization in case this is
    conflicting with the register status.
    
    Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
    Signed-off-by: Moshe Tal <moshet@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Fix wrong source vport matching on tunnel rule [+ + +]
Author: Ariel Levkovich <lariel@nvidia.com>
Date:   Tue Mar 15 18:20:48 2022 +0200

    net/mlx5e: Fix wrong source vport matching on tunnel rule
    
    commit cb0d54cbf94866b48a73e10a73a55655f808cc7c upstream.
    
    When OVS internal port is the vtep device, the first decap
    rule is matching on the internal port's vport metadata value
    and then changes the metadata to be the uplink's value.
    
    Therefore, following rules on the tunnel, in chain > 0, should
    avoid matching on internal port metadata and use the uplink
    vport metadata instead.
    
    Select the uplink's metadata value for the source vport match
    in case the rule is in chain greater than zero, even if the tunnel
    route device is internal port.
    
    Fixes: 166f431ec6be ("net/mlx5e: Add indirect tc offload of ovs internal port")
    Signed-off-by: Ariel Levkovich <lariel@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Lag, Don't skip fib events on current dst [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Mon Apr 18 17:40:37 2022 +0300

    net/mlx5e: Lag, Don't skip fib events on current dst
    
    commit 4a2a664ed87962c4ddb806a84b5c9634820bcf55 upstream.
    
    Referenced change added check to skip updating fib when new fib instance
    has same or lower priority. However, new fib instance can be an update on
    same dst address as existing one even though the structure is another
    instance that has different address. Ignoring events on such instances
    causes multipath LAG state to not be correctly updated.
    
    Track 'dst' and 'dst_len' fields of fib event fib_entry_notifier_info
    structure and don't skip events that have the same value of that fields.
    
    Fixes: ad11c4f1d8fd ("net/mlx5e: Lag, Only handle events from highest priority multipath entry")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Lag, Fix fib_info pointer assignment [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Mon Apr 18 17:32:54 2022 +0300

    net/mlx5e: Lag, Fix fib_info pointer assignment
    
    commit a6589155ec9847918e00e7279b8aa6d4c272bea7 upstream.
    
    Referenced change incorrectly sets single path fib_info even when LAG is
    not active. Fix it by moving call to mlx5_lag_fib_set() into conditional
    that verifies LAG state.
    
    Fixes: ad11c4f1d8fd ("net/mlx5e: Lag, Only handle events from highest priority multipath entry")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: Lag, Fix use-after-free in fib event handler [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Mon Apr 18 17:32:19 2022 +0300

    net/mlx5e: Lag, Fix use-after-free in fib event handler
    
    commit 27b0420fd959e38e3500e60b637d39dfab065645 upstream.
    
    Recent commit that modified fib route event handler to handle events
    according to their priority introduced use-after-free[0] in mp->mfi pointer
    usage. The pointer now is not just cached in order to be compared to
    following fib_info instances, but is also dereferenced to obtain
    fib_priority. However, since mlx5 lag code doesn't hold the reference to
    fin_info during whole mp->mfi lifetime, it could be used after fib_info
    instance has already been freed be kernel infrastructure code.
    
    Don't ever dereference mp->mfi pointer. Refactor it to be 'const void*'
    type and cache fib_info priority in dedicated integer. Group
    fib_info-related data into dedicated 'fib' structure that will be further
    extended by following patches in the series.
    
    [0]:
    
    [  203.588029] ==================================================================
    [  203.590161] BUG: KASAN: use-after-free in mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
    [  203.592386] Read of size 4 at addr ffff888144df2050 by task kworker/u20:4/138
    
    [  203.594766] CPU: 3 PID: 138 Comm: kworker/u20:4 Tainted: G    B             5.17.0-rc7+ #6
    [  203.596751] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [  203.598813] Workqueue: mlx5_lag_mp mlx5_lag_fib_update [mlx5_core]
    [  203.600053] Call Trace:
    [  203.600608]  <TASK>
    [  203.601110]  dump_stack_lvl+0x48/0x5e
    [  203.601860]  print_address_description.constprop.0+0x1f/0x160
    [  203.602950]  ? mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
    [  203.604073]  ? mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
    [  203.605177]  kasan_report.cold+0x83/0xdf
    [  203.605969]  ? mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
    [  203.607102]  mlx5_lag_fib_update+0xabd/0xd60 [mlx5_core]
    [  203.608199]  ? mlx5_lag_init_fib_work+0x1c0/0x1c0 [mlx5_core]
    [  203.609382]  ? read_word_at_a_time+0xe/0x20
    [  203.610463]  ? strscpy+0xa0/0x2a0
    [  203.611463]  process_one_work+0x722/0x1270
    [  203.612344]  worker_thread+0x540/0x11e0
    [  203.613136]  ? rescuer_thread+0xd50/0xd50
    [  203.613949]  kthread+0x26e/0x300
    [  203.614627]  ? kthread_complete_and_exit+0x20/0x20
    [  203.615542]  ret_from_fork+0x1f/0x30
    [  203.616273]  </TASK>
    
    [  203.617174] Allocated by task 3746:
    [  203.617874]  kasan_save_stack+0x1e/0x40
    [  203.618644]  __kasan_kmalloc+0x81/0xa0
    [  203.619394]  fib_create_info+0xb41/0x3c50
    [  203.620213]  fib_table_insert+0x190/0x1ff0
    [  203.621020]  fib_magic.isra.0+0x246/0x2e0
    [  203.621803]  fib_add_ifaddr+0x19f/0x670
    [  203.622563]  fib_inetaddr_event+0x13f/0x270
    [  203.623377]  blocking_notifier_call_chain+0xd4/0x130
    [  203.624355]  __inet_insert_ifa+0x641/0xb20
    [  203.625185]  inet_rtm_newaddr+0xc3d/0x16a0
    [  203.626009]  rtnetlink_rcv_msg+0x309/0x880
    [  203.626826]  netlink_rcv_skb+0x11d/0x340
    [  203.627626]  netlink_unicast+0x4cc/0x790
    [  203.628430]  netlink_sendmsg+0x762/0xc00
    [  203.629230]  sock_sendmsg+0xb2/0xe0
    [  203.629955]  ____sys_sendmsg+0x58a/0x770
    [  203.630756]  ___sys_sendmsg+0xd8/0x160
    [  203.631523]  __sys_sendmsg+0xb7/0x140
    [  203.632294]  do_syscall_64+0x35/0x80
    [  203.633045]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    [  203.634427] Freed by task 0:
    [  203.635063]  kasan_save_stack+0x1e/0x40
    [  203.635844]  kasan_set_track+0x21/0x30
    [  203.636618]  kasan_set_free_info+0x20/0x30
    [  203.637450]  __kasan_slab_free+0xfc/0x140
    [  203.638271]  kfree+0x94/0x3b0
    [  203.638903]  rcu_core+0x5e4/0x1990
    [  203.639640]  __do_softirq+0x1ba/0x5d3
    
    [  203.640828] Last potentially related work creation:
    [  203.641785]  kasan_save_stack+0x1e/0x40
    [  203.642571]  __kasan_record_aux_stack+0x9f/0xb0
    [  203.643478]  call_rcu+0x88/0x9c0
    [  203.644178]  fib_release_info+0x539/0x750
    [  203.644997]  fib_table_delete+0x659/0xb80
    [  203.645809]  fib_magic.isra.0+0x1a3/0x2e0
    [  203.646617]  fib_del_ifaddr+0x93f/0x1300
    [  203.647415]  fib_inetaddr_event+0x9f/0x270
    [  203.648251]  blocking_notifier_call_chain+0xd4/0x130
    [  203.649225]  __inet_del_ifa+0x474/0xc10
    [  203.650016]  devinet_ioctl+0x781/0x17f0
    [  203.650788]  inet_ioctl+0x1ad/0x290
    [  203.651533]  sock_do_ioctl+0xce/0x1c0
    [  203.652315]  sock_ioctl+0x27b/0x4f0
    [  203.653058]  __x64_sys_ioctl+0x124/0x190
    [  203.653850]  do_syscall_64+0x35/0x80
    [  203.654608]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    [  203.666952] The buggy address belongs to the object at ffff888144df2000
                    which belongs to the cache kmalloc-256 of size 256
    [  203.669250] The buggy address is located 80 bytes inside of
                    256-byte region [ffff888144df2000, ffff888144df2100)
    [  203.671332] The buggy address belongs to the page:
    [  203.672273] page:00000000bf6c9314 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x144df0
    [  203.674009] head:00000000bf6c9314 order:2 compound_mapcount:0 compound_pincount:0
    [  203.675422] flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff)
    [  203.676819] raw: 002ffff800010200 0000000000000000 dead000000000122 ffff888100042b40
    [  203.678384] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
    [  203.679928] page dumped because: kasan: bad access detected
    
    [  203.681455] Memory state around the buggy address:
    [  203.682421]  ffff888144df1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  203.683863]  ffff888144df1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  203.685310] >ffff888144df2000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  203.686701]                                                  ^
    [  203.687820]  ffff888144df2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  203.689226]  ffff888144df2100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  203.690620] ==================================================================
    
    Fixes: ad11c4f1d8fd ("net/mlx5e: Lag, Only handle events from highest priority multipath entry")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/mlx5e: TC, fix decap fallback to uplink when int port not supported [+ + +]
Author: Ariel Levkovich <lariel@nvidia.com>
Date:   Mon Apr 25 17:12:12 2022 +0300

    net/mlx5e: TC, fix decap fallback to uplink when int port not supported
    
    commit e3fdc71bcb6ffe1d4870a89252ba296a9558e294 upstream.
    
    When resolving the decap route device for a tunnel decap rule,
    the result may be an OVS internal port device.
    
    Prior to adding the support for internal port offload, such case
    would result in using the uplink as the default decap route device
    which allowed devices that can't support internal port offload
    to offload this decap rule.
    
    This behavior got broken by adding the internal port offload which
    will fail in case the device can't support internal port offload.
    
    To restore the old behavior, use the uplink device as the decap
    route as before when internal port offload is not supported.
    
    Fixes: b16eb3c81fe2 ("net/mlx5: Support internal port as decap route device")
    Signed-off-by: Ariel Levkovich <lariel@nvidia.com>
    Reviewed-by: Maor Dickman <maord@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: cpsw: add missing of_node_put() in cpsw_probe_dt() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Apr 29 09:53:37 2022 +0800

    net: cpsw: add missing of_node_put() in cpsw_probe_dt()
    
    commit 95098d5ac2551769807031444e55a0da5d4f0952 upstream.
    
    'tmp_node' need be put before returning from cpsw_probe_dt(),
    so add missing of_node_put() in error path.
    
    Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1 - dual-emac")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: dsa: mt7530: add missing of_node_put() in mt7530_setup() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Apr 28 17:53:17 2022 +0800

    net: dsa: mt7530: add missing of_node_put() in mt7530_setup()
    
    commit a9e9b091a1c14ecd8bd9d3214a62142a1786fe30 upstream.
    
    Add of_node_put() if of_get_phy_mode() fails in mt7530_setup()
    
    Fixes: 0c65b2b90d13 ("net: of_get_phy_mode: Change API to solve int/unit warnings")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220428095317.538829-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: emaclite: Add error handling for of_address_to_resource() [+ + +]
Author: Shravya Kumbham <shravya.kumbham@xilinx.com>
Date:   Mon May 2 12:57:50 2022 +0530

    net: emaclite: Add error handling for of_address_to_resource()
    
    commit 7a6bc33ab54923d325d9a1747ec9652c4361ebd1 upstream.
    
    check the return value of of_address_to_resource() and also add
    missing of_node_put() for np and npp nodes.
    
    Fixes: e0a3bc65448c ("net: emaclite: Support multiple phys connected to one MDIO bus")
    Addresses-Coverity: Event check_return value.
    Signed-off-by: Shravya Kumbham <shravya.kumbham@xilinx.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ethernet: mediatek: add missing of_node_put() in mtk_sgmii_init() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Apr 28 14:25:43 2022 +0800

    net: ethernet: mediatek: add missing of_node_put() in mtk_sgmii_init()
    
    commit ff5265d45345d01fefc98fcb9ae891b59633c919 upstream.
    
    The node pointer returned by of_parse_phandle() with refcount incremented,
    so add of_node_put() after using it in mtk_sgmii_init().
    
    Fixes: 9ffee4a8276c ("net: ethernet: mediatek: Extend SGMII related functions")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220428062543.64883-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: igmp: respect RCU rules in ip_mc_source() and ip_mc_msfilter() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 29 08:42:57 2022 -0700

    net: igmp: respect RCU rules in ip_mc_source() and ip_mc_msfilter()
    
    commit dba5bdd57bea587ea4f0b79b03c71135f84a7e8b upstream.
    
    syzbot reported an UAF in ip_mc_sf_allow() [1]
    
    Whenever RCU protected list replaces an object,
    the pointer to the new object needs to be updated
    _before_ the call to kfree_rcu() or call_rcu()
    
    Because kfree_rcu(ptr, rcu) got support for NULL ptr
    only recently in commit 12edff045bc6 ("rcu: Make kfree_rcu()
    ignore NULL pointers"), I chose to use the conditional
    to make sure stable backports won't miss this detail.
    
    if (psl)
        kfree_rcu(psl, rcu);
    
    net/ipv6/mcast.c has similar issues, addressed in a separate patch.
    
    [1]
    BUG: KASAN: use-after-free in ip_mc_sf_allow+0x6bb/0x6d0 net/ipv4/igmp.c:2655
    Read of size 4 at addr ffff88807d37b904 by task syz-executor.5/908
    
    CPU: 0 PID: 908 Comm: syz-executor.5 Not tainted 5.18.0-rc4-syzkaller-00064-g8f4dd16603ce #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313
     print_report mm/kasan/report.c:429 [inline]
     kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
     ip_mc_sf_allow+0x6bb/0x6d0 net/ipv4/igmp.c:2655
     raw_v4_input net/ipv4/raw.c:190 [inline]
     raw_local_deliver+0x4d1/0xbe0 net/ipv4/raw.c:218
     ip_protocol_deliver_rcu+0xcf/0xb30 net/ipv4/ip_input.c:193
     ip_local_deliver_finish+0x2ee/0x4c0 net/ipv4/ip_input.c:233
     NF_HOOK include/linux/netfilter.h:307 [inline]
     NF_HOOK include/linux/netfilter.h:301 [inline]
     ip_local_deliver+0x1b3/0x200 net/ipv4/ip_input.c:254
     dst_input include/net/dst.h:461 [inline]
     ip_rcv_finish+0x1cb/0x2f0 net/ipv4/ip_input.c:437
     NF_HOOK include/linux/netfilter.h:307 [inline]
     NF_HOOK include/linux/netfilter.h:301 [inline]
     ip_rcv+0xaa/0xd0 net/ipv4/ip_input.c:556
     __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5405
     __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5519
     netif_receive_skb_internal net/core/dev.c:5605 [inline]
     netif_receive_skb+0x13e/0x8e0 net/core/dev.c:5664
     tun_rx_batched.isra.0+0x460/0x720 drivers/net/tun.c:1534
     tun_get_user+0x28b7/0x3e30 drivers/net/tun.c:1985
     tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2015
     call_write_iter include/linux/fs.h:2050 [inline]
     new_sync_write+0x38a/0x560 fs/read_write.c:504
     vfs_write+0x7c0/0xac0 fs/read_write.c:591
     ksys_write+0x127/0x250 fs/read_write.c:644
     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:0x7f3f12c3bbff
    Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 99 fd ff ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 cc fd ff ff 48
    RSP: 002b:00007f3f13ea9130 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00007f3f12d9bf60 RCX: 00007f3f12c3bbff
    RDX: 0000000000000036 RSI: 0000000020002ac0 RDI: 00000000000000c8
    RBP: 00007f3f12ce308d R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000036 R11: 0000000000000293 R12: 0000000000000000
    R13: 00007fffb68dd79f R14: 00007f3f13ea9300 R15: 0000000000022000
     </TASK>
    
    Allocated by task 908:
     kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
     kasan_set_track mm/kasan/common.c:45 [inline]
     set_alloc_info mm/kasan/common.c:436 [inline]
     ____kasan_kmalloc mm/kasan/common.c:515 [inline]
     ____kasan_kmalloc mm/kasan/common.c:474 [inline]
     __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
     kasan_kmalloc include/linux/kasan.h:234 [inline]
     __do_kmalloc mm/slab.c:3710 [inline]
     __kmalloc+0x209/0x4d0 mm/slab.c:3719
     kmalloc include/linux/slab.h:586 [inline]
     sock_kmalloc net/core/sock.c:2501 [inline]
     sock_kmalloc+0xb5/0x100 net/core/sock.c:2492
     ip_mc_source+0xba2/0x1100 net/ipv4/igmp.c:2392
     do_ip_setsockopt net/ipv4/ip_sockglue.c:1296 [inline]
     ip_setsockopt+0x2312/0x3ab0 net/ipv4/ip_sockglue.c:1432
     raw_setsockopt+0x274/0x2c0 net/ipv4/raw.c:861
     __sys_setsockopt+0x2db/0x6a0 net/socket.c:2180
     __do_sys_setsockopt net/socket.c:2191 [inline]
     __se_sys_setsockopt net/socket.c:2188 [inline]
     __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
     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
    
    Freed by task 753:
     kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
     kasan_set_track+0x21/0x30 mm/kasan/common.c:45
     kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
     ____kasan_slab_free mm/kasan/common.c:366 [inline]
     ____kasan_slab_free+0x13d/0x180 mm/kasan/common.c:328
     kasan_slab_free include/linux/kasan.h:200 [inline]
     __cache_free mm/slab.c:3439 [inline]
     kmem_cache_free_bulk+0x69/0x460 mm/slab.c:3774
     kfree_bulk include/linux/slab.h:437 [inline]
     kfree_rcu_work+0x51c/0xa10 kernel/rcu/tree.c:3318
     process_one_work+0x996/0x1610 kernel/workqueue.c:2289
     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
     kthread+0x2e9/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
    
    Last potentially related work creation:
     kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
     __kasan_record_aux_stack+0x7e/0x90 mm/kasan/generic.c:348
     kvfree_call_rcu+0x74/0x990 kernel/rcu/tree.c:3595
     ip_mc_msfilter+0x712/0xb60 net/ipv4/igmp.c:2510
     do_ip_setsockopt net/ipv4/ip_sockglue.c:1257 [inline]
     ip_setsockopt+0x32e1/0x3ab0 net/ipv4/ip_sockglue.c:1432
     raw_setsockopt+0x274/0x2c0 net/ipv4/raw.c:861
     __sys_setsockopt+0x2db/0x6a0 net/socket.c:2180
     __do_sys_setsockopt net/socket.c:2191 [inline]
     __se_sys_setsockopt net/socket.c:2188 [inline]
     __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
     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
    
    Second to last potentially related work creation:
     kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
     __kasan_record_aux_stack+0x7e/0x90 mm/kasan/generic.c:348
     call_rcu+0x99/0x790 kernel/rcu/tree.c:3074
     mpls_dev_notify+0x552/0x8a0 net/mpls/af_mpls.c:1656
     notifier_call_chain+0xb5/0x200 kernel/notifier.c:84
     call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1938
     call_netdevice_notifiers_extack net/core/dev.c:1976 [inline]
     call_netdevice_notifiers net/core/dev.c:1990 [inline]
     unregister_netdevice_many+0x92e/0x1890 net/core/dev.c:10751
     default_device_exit_batch+0x449/0x590 net/core/dev.c:11245
     ops_exit_list+0x125/0x170 net/core/net_namespace.c:167
     cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594
     process_one_work+0x996/0x1610 kernel/workqueue.c:2289
     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
     kthread+0x2e9/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
    
    The buggy address belongs to the object at ffff88807d37b900
     which belongs to the cache kmalloc-64 of size 64
    The buggy address is located 4 bytes inside of
     64-byte region [ffff88807d37b900, ffff88807d37b940)
    
    The buggy address belongs to the physical page:
    page:ffffea0001f4dec0 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88807d37b180 pfn:0x7d37b
    flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
    raw: 00fff00000000200 ffff888010c41340 ffffea0001c795c8 ffff888010c40200
    raw: ffff88807d37b180 ffff88807d37b000 000000010000001f 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x342040(__GFP_IO|__GFP_NOWARN|__GFP_COMP|__GFP_HARDWALL|__GFP_THISNODE), pid 2963, tgid 2963 (udevd), ts 139732238007, free_ts 139730893262
     prep_new_page mm/page_alloc.c:2441 [inline]
     get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182
     __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408
     __alloc_pages_node include/linux/gfp.h:587 [inline]
     kmem_getpages mm/slab.c:1378 [inline]
     cache_grow_begin+0x75/0x350 mm/slab.c:2584
     cache_alloc_refill+0x27f/0x380 mm/slab.c:2957
     ____cache_alloc mm/slab.c:3040 [inline]
     ____cache_alloc mm/slab.c:3023 [inline]
     __do_cache_alloc mm/slab.c:3267 [inline]
     slab_alloc mm/slab.c:3309 [inline]
     __do_kmalloc mm/slab.c:3708 [inline]
     __kmalloc+0x3b3/0x4d0 mm/slab.c:3719
     kmalloc include/linux/slab.h:586 [inline]
     kzalloc include/linux/slab.h:714 [inline]
     tomoyo_encode2.part.0+0xe9/0x3a0 security/tomoyo/realpath.c:45
     tomoyo_encode2 security/tomoyo/realpath.c:31 [inline]
     tomoyo_encode+0x28/0x50 security/tomoyo/realpath.c:80
     tomoyo_realpath_from_path+0x186/0x620 security/tomoyo/realpath.c:288
     tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
     tomoyo_path_perm+0x21b/0x400 security/tomoyo/file.c:822
     security_inode_getattr+0xcf/0x140 security/security.c:1350
     vfs_getattr fs/stat.c:157 [inline]
     vfs_statx+0x16a/0x390 fs/stat.c:232
     vfs_fstatat+0x8c/0xb0 fs/stat.c:255
     __do_sys_newfstatat+0x91/0x110 fs/stat.c:425
     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
    page last free stack trace:
     reset_page_owner include/linux/page_owner.h:24 [inline]
     free_pages_prepare mm/page_alloc.c:1356 [inline]
     free_pcp_prepare+0x549/0xd20 mm/page_alloc.c:1406
     free_unref_page_prepare mm/page_alloc.c:3328 [inline]
     free_unref_page+0x19/0x6a0 mm/page_alloc.c:3423
     __vunmap+0x85d/0xd30 mm/vmalloc.c:2667
     __vfree+0x3c/0xd0 mm/vmalloc.c:2715
     vfree+0x5a/0x90 mm/vmalloc.c:2746
     __do_replace+0x16b/0x890 net/ipv6/netfilter/ip6_tables.c:1117
     do_replace net/ipv6/netfilter/ip6_tables.c:1157 [inline]
     do_ip6t_set_ctl+0x90d/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
     nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
     ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1026
     tcp_setsockopt+0x136/0x2520 net/ipv4/tcp.c:3696
     __sys_setsockopt+0x2db/0x6a0 net/socket.c:2180
     __do_sys_setsockopt net/socket.c:2191 [inline]
     __se_sys_setsockopt net/socket.c:2188 [inline]
     __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
     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
    
    Memory state around the buggy address:
     ffff88807d37b800: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
     ffff88807d37b880: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
    >ffff88807d37b900: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
                       ^
     ffff88807d37b980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
     ffff88807d37ba00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
    
    Fixes: c85bb41e9318 ("igmp: fix ip_mc_sf_allow race [v5]")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Flavio Leitner <fbl@sysclose.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: mdio: Fix ENOMEM return value in BCM6368 mux bus controller [+ + +]
Author: Niels Dossche <dossche.niels@gmail.com>
Date:   Thu Apr 28 23:19:32 2022 +0200

    net: mdio: Fix ENOMEM return value in BCM6368 mux bus controller
    
    commit e87f66b38e66dffdec9daa9f8f0eb044e9a62e3b upstream.
    
    Error values inside the probe function must be < 0. The ENOMEM return
    value has the wrong sign: it is positive instead of negative.
    Add a minus sign.
    
    Fixes: e239756717b5 ("net: mdio: Add BCM6368 MDIO mux bus controller")
    Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220428211931.8130-1-dossche.niels@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: rds: acquire refcount on TCP sockets [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon May 2 10:40:18 2022 +0900

    net: rds: acquire refcount on TCP sockets
    
    [ Upstream commit 3a58f13a881ed351198ffab4cf9953cf19d2ab3a ]
    
    syzbot is reporting use-after-free read in tcp_retransmit_timer() [1],
    for TCP socket used by RDS is accessing sock_net() without acquiring a
    refcount on net namespace. Since TCP's retransmission can happen after
    a process which created net namespace terminated, we need to explicitly
    acquire a refcount.
    
    Link: https://syzkaller.appspot.com/bug?extid=694120e1002c117747ed [1]
    Reported-by: syzbot <syzbot+694120e1002c117747ed@syzkaller.appspotmail.com>
    Fixes: 26abe14379f8e2fa ("net: Modify sk_alloc to not reference count the netns of kernel sockets.")
    Fixes: 8a68173691f03661 ("net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: syzbot <syzbot+694120e1002c117747ed@syzkaller.appspotmail.com>
    Link: https://lore.kernel.org/r/a5fb1fc4-2284-3359-f6a0-e4e390239d7b@I-love.SAKURA.ne.jp
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: disable Split Header (SPH) for Intel platforms [+ + +]
Author: Tan Tee Min <tee.min.tan@linux.intel.com>
Date:   Fri Apr 29 19:58:07 2022 +0800

    net: stmmac: disable Split Header (SPH) for Intel platforms
    
    commit 47f753c1108e287edb3e27fad8a7511a9d55578e upstream.
    
    Based on DesignWare Ethernet QoS datasheet, we are seeing the limitation
    of Split Header (SPH) feature is not supported for Ipv4 fragmented packet.
    This SPH limitation will cause ping failure when the packets size exceed
    the MTU size. For example, the issue happens once the basic ping packet
    size is larger than the configured MTU size and the data is lost inside
    the fragmented packet, replaced by zeros/corrupted values, and leads to
    ping fail.
    
    So, disable the Split Header for Intel platforms.
    
    v2: Add fixes tag in commit message.
    
    Fixes: 67afd6d1cfdf("net: stmmac: Add Split Header support and enable it in XGMAC cores")
    Cc: <stable@vger.kernel.org> # 5.10.x
    Suggested-by: Ong, Boon Leong <boon.leong.ong@intel.com>
    Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com>
    Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
    Signed-off-by: Tan Tee Min <tee.min.tan@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: stmmac: dwmac-sun8i: add missing of_node_put() in sun8i_dwmac_register_mdio_mux() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Apr 28 17:57:16 2022 +0800

    net: stmmac: dwmac-sun8i: add missing of_node_put() in sun8i_dwmac_register_mdio_mux()
    
    commit 1a15267b7be77e0792cf0c7b36ca65c8eb2df0d8 upstream.
    
    The node pointer returned by of_get_child_by_name() with refcount incremented,
    so add of_node_put() after using it.
    
    Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220428095716.540452-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFC: netlink: fix sleep in atomic bug when firmware download timeout [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Wed May 4 13:58:47 2022 +0800

    NFC: netlink: fix sleep in atomic bug when firmware download timeout
    
    commit 4071bf121d59944d5cd2238de0642f3d7995a997 upstream.
    
    There are sleep in atomic bug that could cause kernel panic during
    firmware download process. The root cause is that nlmsg_new with
    GFP_KERNEL parameter is called in fw_dnld_timeout which is a timer
    handler. The call trace is shown below:
    
    BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265
    Call Trace:
    kmem_cache_alloc_node
    __alloc_skb
    nfc_genl_fw_download_done
    call_timer_fn
    __run_timers.part.0
    run_timer_softirq
    __do_softirq
    ...
    
    The nlmsg_new with GFP_KERNEL parameter may sleep during memory
    allocation process, and the timer handler is run as the result of
    a "software interrupt" that should not call any other function
    that could sleep.
    
    This patch changes allocation mode of netlink message from GFP_KERNEL
    to GFP_ATOMIC in order to prevent sleep in atomic bug. The GFP_ATOMIC
    flag makes memory allocation operation could be used in atomic context.
    
    Fixes: 9674da8759df ("NFC: Add firmware upload netlink command")
    Fixes: 9ea7187c53f6 ("NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220504055847.38026-1-duoming@zju.edu.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: nfcmrvl: main: reorder destructive operations in nfcmrvl_nci_unregister_dev to avoid bugs [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Fri Apr 29 20:45:51 2022 +0800

    nfc: nfcmrvl: main: reorder destructive operations in nfcmrvl_nci_unregister_dev to avoid bugs
    
    commit d270453a0d9ec10bb8a802a142fb1b3601a83098 upstream.
    
    There are destructive operations such as nfcmrvl_fw_dnld_abort and
    gpio_free in nfcmrvl_nci_unregister_dev. The resources such as firmware,
    gpio and so on could be destructed while the upper layer functions such as
    nfcmrvl_fw_dnld_start and nfcmrvl_nci_recv_frame is executing, which leads
    to double-free, use-after-free and null-ptr-deref bugs.
    
    There are three situations that could lead to double-free bugs.
    
    The first situation is shown below:
    
       (Thread 1)                 |      (Thread 2)
    nfcmrvl_fw_dnld_start         |
     ...                          |  nfcmrvl_nci_unregister_dev
     release_firmware()           |   nfcmrvl_fw_dnld_abort
      kfree(fw) //(1)             |    fw_dnld_over
                                  |     release_firmware
      ...                         |      kfree(fw) //(2)
                                  |     ...
    
    The second situation is shown below:
    
       (Thread 1)                 |      (Thread 2)
    nfcmrvl_fw_dnld_start         |
     ...                          |
     mod_timer                    |
     (wait a time)                |
     fw_dnld_timeout              |  nfcmrvl_nci_unregister_dev
       fw_dnld_over               |   nfcmrvl_fw_dnld_abort
        release_firmware          |    fw_dnld_over
         kfree(fw) //(1)          |     release_firmware
         ...                      |      kfree(fw) //(2)
    
    The third situation is shown below:
    
           (Thread 1)               |       (Thread 2)
    nfcmrvl_nci_recv_frame          |
     if(..->fw_download_in_progress)|
      nfcmrvl_fw_dnld_recv_frame    |
       queue_work                   |
                                    |
    fw_dnld_rx_work                 | nfcmrvl_nci_unregister_dev
     fw_dnld_over                   |  nfcmrvl_fw_dnld_abort
      release_firmware              |   fw_dnld_over
       kfree(fw) //(1)              |    release_firmware
                                    |     kfree(fw) //(2)
    
    The firmware struct is deallocated in position (1) and deallocated
    in position (2) again.
    
    The crash trace triggered by POC is like below:
    
    BUG: KASAN: double-free or invalid-free in fw_dnld_over
    Call Trace:
      kfree
      fw_dnld_over
      nfcmrvl_nci_unregister_dev
      nci_uart_tty_close
      tty_ldisc_kill
      tty_ldisc_hangup
      __tty_hangup.part.0
      tty_release
      ...
    
    What's more, there are also use-after-free and null-ptr-deref bugs
    in nfcmrvl_fw_dnld_start. If we deallocate firmware struct, gpio or
    set null to the members of priv->fw_dnld in nfcmrvl_nci_unregister_dev,
    then, we dereference firmware, gpio or the members of priv->fw_dnld in
    nfcmrvl_fw_dnld_start, the UAF or NPD bugs will happen.
    
    This patch reorders destructive operations after nci_unregister_device
    in order to synchronize between cleanup routine and firmware download
    routine.
    
    The nci_unregister_device is well synchronized. If the device is
    detaching, the firmware download routine will goto error. If firmware
    download routine is executing, nci_unregister_device will wait until
    firmware download routine is finished.
    
    Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfc: replace improper check device_is_registered() in netlink related functions [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Fri Apr 29 20:45:50 2022 +0800

    nfc: replace improper check device_is_registered() in netlink related functions
    
    commit da5c0f119203ad9728920456a0f52a6d850c01cd upstream.
    
    The device_is_registered() in nfc core is used to check whether
    nfc device is registered in netlink related functions such as
    nfc_fw_download(), nfc_dev_up() and so on. Although device_is_registered()
    is protected by device_lock, there is still a race condition between
    device_del() and device_is_registered(). The root cause is that
    kobject_del() in device_del() is not protected by device_lock.
    
       (cleanup task)         |     (netlink task)
                              |
    nfc_unregister_device     | nfc_fw_download
     device_del               |  device_lock
      ...                     |   if (!device_is_registered)//(1)
      kobject_del//(2)        |   ...
     ...                      |  device_unlock
    
    The device_is_registered() returns the value of state_in_sysfs and
    the state_in_sysfs is set to zero in kobject_del(). If we pass check in
    position (1), then set zero in position (2). As a result, the check
    in position (1) is useless.
    
    This patch uses bool variable instead of device_is_registered() to judge
    whether the nfc device is registered, which is well synchronized.
    
    Fixes: 3e256b8f8dfa ("NFC: add nfc subsystem core")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFSv4: Don't invalidate inode attributes on delegation return [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Apr 25 18:04:27 2022 -0400

    NFSv4: Don't invalidate inode attributes on delegation return
    
    commit 00c94ebec5925593c0377b941289224469e72ac7 upstream.
    
    There is no need to declare attributes such as the ctime, mtime and
    block size invalid when we're just returning a delegation, so it is
    inappropriate to call nfs_post_op_update_inode_force_wcc().
    Instead, just call nfs_refresh_inode() after faking up the change
    attribute. We know that the GETATTR op occurs before the DELEGRETURN, so
    we are safe when doing this.
    
    Fixes: 0bc2c9b4dca9 ("NFSv4: Don't discard the attributes returned by asynchronous DELEGRETURN")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
parisc: Mark cr16 clock unstable on all SMP machines [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sun May 8 18:25:00 2022 +0200

    parisc: Mark cr16 clock unstable on all SMP machines
    
    commit 340233dcc0160aafcce46ca893d1679f16acf409 upstream.
    
    The cr16 interval timers are not synchronized across CPUs, even with just
    one dual-core CPU. This becomes visible if the machines have a longer
    uptime.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Merge model and model name into one line in /proc/cpuinfo [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sun Apr 3 21:57:51 2022 +0200

    parisc: Merge model and model name into one line in /proc/cpuinfo
    
    commit 5b89966bc96a06f6ad65f64ae4b0461918fcc9d3 upstream.
    
    The Linux tool "lscpu" shows the double amount of CPUs if we have
    "model" and "model name" in two different lines in /proc/cpuinfo.
    This change combines the model and the model name into one line.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: aardvark: Add support for ERR interrupt on emulated bridge [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:44 2022 +0200

    PCI: aardvark: Add support for ERR interrupt on emulated bridge
    
    commit 3ebfefa396ebee21061fd5fa36073368ed2cd467 upstream.
    
    ERR interrupt is triggered when corresponding bit is unmasked in both ISR0
    and PCI_EXP_DEVCTL registers. Unmasking ERR bits in PCI_EXP_DEVCTL register
    is not enough. This means that currently the ERR interrupt is never
    triggered.
    
    Unmask ERR bits in ISR0 register at driver probe time. ERR interrupt is not
    triggered until ERR bits are unmasked also in PCI_EXP_DEVCTL register,
    which is done by AER driver. So it is safe to unconditionally unmask all
    ERR bits in aardvark probe.
    
    Aardvark HW sets PCI_ERR_ROOT_AER_IRQ to zero and when corresponding bits
    in ISR0 and PCI_EXP_DEVCTL are enabled, the HW triggers a generic interrupt
    on GIC. Chain this interrupt to PCIe interrupt 0 with
    generic_handle_domain_irq() to allow processing of ERR interrupts.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-14-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Add support for masking MSI interrupts [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:41 2022 +0200

    PCI: aardvark: Add support for masking MSI interrupts
    
    commit e77d9c90691071769cd2b86ef097f7d07167dc3b upstream.
    
    We should not unmask MSIs at setup, but only when kernel asks for them
    to be unmasked.
    
    At setup, mask all MSIs, and implement IRQ chip callbacks for masking
    and unmasking particular MSIs.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-11-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Add support for PME interrupts [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:46 2022 +0200

    PCI: aardvark: Add support for PME interrupts
    
    commit 0fc75d87454195885bd1a81fc7e6ce92572b6109 upstream.
    
    Currently enabling PCI_EXP_RTSTA_PME bit in PCI_EXP_RTCTL register does
    nothing. This is because PCIe PME driver expects to receive PCIe interrupt
    defined in PCI_EXP_FLAGS_IRQ register, but aardvark hardware does not
    trigger PCIe INTx/MSI interrupt for PME event, rather it triggers custom
    aardvark interrupt which this driver is not processing yet.
    
    Fix this issue by handling PME interrupt in advk_pcie_handle_int() and
    chaining it to PCIe interrupt 0 with generic_handle_domain_irq() (since
    aardvark sets PCI_EXP_FLAGS_IRQ to zero). With this change PCIe PME driver
    finally starts receiving PME interrupt.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-17-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Check return value of generic_handle_domain_irq() when processing INTx IRQ [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:36 2022 +0200

    PCI: aardvark: Check return value of generic_handle_domain_irq() when processing INTx IRQ
    
    commit 51f96e287c6f003d3bb29672811c757c5fbf0028 upstream.
    
    It is possible that we receive spurious INTx interrupt. Check for the
    return value of generic_handle_domain_irq() when processing INTx IRQ.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-6-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Don't mask irq when mapping [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:50 2022 +0200

    PCI: aardvark: Don't mask irq when mapping
    
    commit befa71000160b39c1bf6cdfca6837bb5e9d372d7 upstream.
    
    By default, all Legacy INTx interrupts are masked, so there is no need to
    mask this interrupt during irq_map() callback.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-21-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Drop __maybe_unused from advk_pcie_disable_phy() [+ + +]
Author: Marek BehĂșn <kabel@kernel.org>
Date:   Wed May 4 18:58:51 2022 +0200

    PCI: aardvark: Drop __maybe_unused from advk_pcie_disable_phy()
    
    commit 0c36ab437e1d94b6628b006a1d48f05ea3b0b222 upstream.
    
    This function is now always used in driver remove method, drop the
    __maybe_unused attribute.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-22-kabel@kernel.org
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Enable MSI-X support [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:43 2022 +0200

    PCI: aardvark: Enable MSI-X support
    
    commit 754e449889b22fc3c34235e8836f08f51121d307 upstream.
    
    According to PCI 3.0 specification, sending both MSI and MSI-X interrupts
    is done by DWORD memory write operation to doorbell message address. The
    write operation for MSI has zero upper 16 bits and the MSI interrupt number
    in the lower 16 bits, while the write operation for MSI-X contains a 32-bit
    value from MSI-X table.
    
    Since the driver only uses interrupt numbers from range 0..31, the upper
    16 bits of the DWORD memory write operation to doorbell message address
    are zero even for MSI-X interrupts. Thus we can enable MSI-X interrupts.
    
    Testing proves that kernel can correctly receive MSI-X interrupts from PCIe
    cards which supports both MSI and MSI-X interrupts.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-13-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Fix setting MSI address [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:42 2022 +0200

    PCI: aardvark: Fix setting MSI address
    
    commit 46ad3dc4171b5ee1d12267d70112563d5760210a upstream.
    
    MSI address for receiving MSI interrupts needs to be correctly set before
    enabling processing of MSI interrupts.
    
    Move code for setting PCIE_MSI_ADDR_LOW_REG and PCIE_MSI_ADDR_HIGH_REG
    from advk_pcie_init_msi_irq_domain() to advk_pcie_setup_hw(), before
    enabling PCIE_CORE_CTRL2_MSI_ENABLE.
    
    After this we can remove the now unused member msi_msg, which was used
    only for MSI doorbell address. MSI address can be any address which cannot
    be used to DMA to. So change it to the address of the main struct advk_pcie.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-12-kabel@kernel.org
    Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org # f21a8b1b6837 ("PCI: aardvark: Move to MSI handling using generic MSI support")
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Fix support for PME requester on emulated bridge [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:47 2022 +0200

    PCI: aardvark: Fix support for PME requester on emulated bridge
    
    commit 273ddd86d67694e3639e3bfe337a96d8861798b8 upstream.
    
    Enable aardvark PME interrupt unconditionally by unmasking it and read PME
    requester ID to emulated bridge config space immediately after receiving
    interrupt.
    
    PME requester ID is stored in the PCIE_MSG_LOG_REG register, which contains
    the last inbound message. So when new inbound message is received by HW
    (including non-PM), the content in PCIE_MSG_LOG_REG register is replaced by
    a new value.
    
    PCIe specification mandates that subsequent PMEs are kept pending until the
    PME Status Register bit is cleared by software by writing a 1b.
    
    Support for masking/unmasking PME interrupt on emulated bridge via
    PCI_EXP_RTCTL_PMEIE bit is now implemented only in emulated bridge config
    space, to ensure that we do not miss any aardvark PME interrupt.
    
    Reading of PCI_EXP_RTCAP and PCI_EXP_RTSTA registers is simplified as final
    value is now always stored into emulated bridge config space by the
    interrupt handler, so there is no need to implement support for these
    registers in read_pcie callback.
    
    Clearing of W1C bit PCI_EXP_RTSTA_PME is now also simplified as it is done
    by pci-bridge-emul.c code for emulated bridge config space. So there is no
    need to implement support for clearing this bit in write_pcie callback.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-18-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Make MSI irq_chip structures static driver structures [+ + +]
Author: Marek BehĂșn <kabel@kernel.org>
Date:   Wed May 4 18:58:37 2022 +0200

    PCI: aardvark: Make MSI irq_chip structures static driver structures
    
    commit c3cb8e51839adc0aaef478c47665443d02f5aa07 upstream.
    
    In [1] it was agreed that we should use struct irq_chip as a global
    static struct in the driver. Even though the structure currently
    contains a dynamic member (parent_device), In [2] the plans to kill it
    and make the structure completely static were set out.
    
    Convert Aardvark's priv->msi_bottom_irq_chip and priv->msi_irq_chip to
    static driver structure.
    
    [1] https://lore.kernel.org/linux-pci/877dbcvngf.wl-maz@kernel.org/
    [2] https://lore.kernel.org/linux-pci/874k6gvkhz.wl-maz@kernel.org/
    
    Link: https://lore.kernel.org/r/20220110015018.26359-7-kabel@kernel.org
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Make msi_domain_info structure a static driver structure [+ + +]
Author: Marek BehĂșn <kabel@kernel.org>
Date:   Wed May 4 18:58:38 2022 +0200

    PCI: aardvark: Make msi_domain_info structure a static driver structure
    
    commit 26bcd54e4a5cd51ec12d06fdc30e22863ed4c422 upstream.
    
    Make Aardvark's msi_domain_info structure into a private driver structure.
    Domain info is same for every potential instatination of a controller.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-8-kabel@kernel.org
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Optimize writing PCI_EXP_RTCTL_PMEIE and PCI_EXP_RTSTA_PME on emulated bridge [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:45 2022 +0200

    PCI: aardvark: Optimize writing PCI_EXP_RTCTL_PMEIE and PCI_EXP_RTSTA_PME on emulated bridge
    
    commit 7122bcb33295228c882c0aa32a04b2547beba2c3 upstream.
    
    To optimize advk_pci_bridge_emul_pcie_conf_write() code, touch
    PCIE_ISR0_REG and PCIE_ISR0_MASK_REG registers only when it is really
    needed, when processing PCI_EXP_RTCTL_PMEIE and PCI_EXP_RTSTA_PME bits.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-16-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Refactor unmasking summary MSI interrupt [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:40 2022 +0200

    PCI: aardvark: Refactor unmasking summary MSI interrupt
    
    commit 4689c0916320f112a8a33f2689d3addc3262f02c upstream.
    
    Refactor the masking of ISR0/1 Sources and unmasking of summary MSI interrupt
    so that it corresponds to the comments:
    - first mask all ISR0/1
    - then unmask all MSIs
    - then unmask summary MSI interrupt
    
    Link: https://lore.kernel.org/r/20220110015018.26359-10-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Remove irq_mask_ack() callback for INTx interrupts [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:49 2022 +0200

    PCI: aardvark: Remove irq_mask_ack() callback for INTx interrupts
    
    commit b08e5b53d17be58eb2311d6790a84fe2c200ee47 upstream.
    
    Callback for irq_mask_ack() is the same as for irq_mask(). As there is no
    special handling for irq_ack(), there is no need to define irq_mask_ack()
    too.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-20-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Replace custom PCIE_CORE_INT_* macros with PCI_INTERRUPT_* [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:34 2022 +0200

    PCI: aardvark: Replace custom PCIE_CORE_INT_* macros with PCI_INTERRUPT_*
    
    commit 1d86abf1f89672a70f2ab65f6000299feb1f1781 upstream.
    
    Header file linux/pci.h defines enum pci_interrupt_pin with corresponding
    PCI_INTERRUPT_* values.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-2-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Rewrite IRQ code to chained IRQ handler [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:35 2022 +0200

    PCI: aardvark: Rewrite IRQ code to chained IRQ handler
    
    commit 1571d67dc190e50c6c56e8f88cdc39f7cc53166e upstream.
    
    Rewrite the code to use irq_set_chained_handler_and_data() handler with
    chained_irq_enter() and chained_irq_exit() processing instead of using
    devm_request_irq().
    
    advk_pcie_irq_handler() reads IRQ status bits and calls other functions
    based on which bits are set. These functions then read its own IRQ status
    bits and calls other aardvark functions based on these bits. Finally
    generic_handle_domain_irq() with translated linux IRQ numbers are called.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-5-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Update comment about link going down after link-up [+ + +]
Author: Marek BehĂșn <kabel@kernel.org>
Date:   Wed May 4 18:58:52 2022 +0200

    PCI: aardvark: Update comment about link going down after link-up
    
    commit 92f4ffecc4170ce29e67a1f8d51c168c3de95fb2 upstream.
    
    Update the comment about what happens when link goes down after we have
    checked for link-up. If a PIO request is done while link-down, we have
    a serious problem.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-23-kabel@kernel.org
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Use dev_fwnode() instead of of_node_to_fwnode(dev->of_node) [+ + +]
Author: Marek BehĂșn <kabel@kernel.org>
Date:   Wed May 4 18:58:39 2022 +0200

    PCI: aardvark: Use dev_fwnode() instead of of_node_to_fwnode(dev->of_node)
    
    commit 222af78532fa299cd9b1008e49c347b7f5a45c17 upstream.
    
    Use simple
      dev_fwnode(dev)
    instead of
      struct device_node *node = dev->of_node;
      of_node_to_fwnode(node)
    especially since the node variable is not used elsewhere in the function.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-9-kabel@kernel.org
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: aardvark: Use separate INTA interrupt for emulated root bridge [+ + +]
Author: Pali RohĂĄr <pali@kernel.org>
Date:   Wed May 4 18:58:48 2022 +0200

    PCI: aardvark: Use separate INTA interrupt for emulated root bridge
    
    commit 815bc313686783e3a1823ec0efc332c70e6bd976 upstream.
    
    Emulated root bridge currently provides only one Legacy INTA interrupt
    which is used for reporting PCIe PME and ERR events and handled by kernel
    PCIe PME and AER drivers.
    
    Aardvark HW reports these PME and ERR events separately, so there is no
    need to mix real INTA interrupt and emulated INTA interrupt for PCIe PME
    and AER drivers.
    
    Register a new advk-RP (as in Root Port) irq chip and a new irq domain
    for emulated root bridge and use this new separate irq domain for
    providing INTA interrupt from emulated root bridge for PME and ERR events.
    
    The real INTA interrupt from real devices is now separate.
    
    A custom map_irq callback function on PCI host bridge structure is used to
    allocate IRQ mapping for emulated root bridge from new irq domain. Original
    callback of_irq_parse_and_map_pci() is used for all other devices as before.
    
    Link: https://lore.kernel.org/r/20220110015018.26359-19-kabel@kernel.org
    Signed-off-by: Pali RohĂĄr <pali@kernel.org>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Marek BehĂșn <kabel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pci_irq_vector() can: 't be used in atomic context any longer. This conflicts with the usage of this function in nic_mbx_intr_handler(). age of this function in nic_mbx_intr_handler(). [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Apr 29 15:54:24 2022 +0200

    pci_irq_vector() can't be used in atomic context any longer. This conflicts with the usage of this function in nic_mbx_intr_handler(). age of this function in nic_mbx_intr_handler().
    
    commit 6b292a04c694573a302686323fe15b1c7e673e5b upstream.
    
    Cache the Linux interrupt numbers in struct nicpf and use that cache in the
    interrupt handler to select the mailbox.
    
    Fixes: 495c66aca3da ("genirq/msi: Convert to new functions")
    Reported-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Sunil Goutham <sgoutham@marvell.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2041772
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
RDMA/irdma: Fix possible crash due to NULL netdev in notifier [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Mon Apr 25 13:17:03 2022 -0500

    RDMA/irdma: Fix possible crash due to NULL netdev in notifier
    
    commit 1c9043ae0667a43bd87beeebbdd4bed674713629 upstream.
    
    For some net events in irdma_net_event notifier, the netdev can be NULL
    which will cause a crash in rdma_vlan_dev_real_dev.  Fix this by moving
    all processing to the NETEVENT_NEIGH_UPDATE case where the netdev is
    guaranteed to not be NULL.
    
    Fixes: 6702bc147448 ("RDMA/irdma: Fix netdev notifications for vlan's")
    Link: https://lore.kernel.org/r/20220425181703.1634-4-shiraz.saleem@intel.com
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RDMA/irdma: Flush iWARP QP if modified to ERR from RTR state [+ + +]
Author: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Date:   Mon Apr 25 13:17:01 2022 -0500

    RDMA/irdma: Flush iWARP QP if modified to ERR from RTR state
    
    commit 7b8943b821bafab492f43aafbd006b57c6b65845 upstream.
    
    When connection establishment fails in iWARP mode, an app can drain the
    QPs and hang because flush isn't issued when the QP is modified from RTR
    state to error. Issue a flush in this case using function
    irdma_cm_disconn().
    
    Update irdma_cm_disconn() to do flush when cm_id is NULL, which is the
    case when the QP is in RTR state and there is an error in the connection
    establishment.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Link: https://lore.kernel.org/r/20220425181703.1634-2-shiraz.saleem@intel.com
    Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RDMA/irdma: Reduce iWARP QP destroy time [+ + +]
Author: Shiraz Saleem <shiraz.saleem@intel.com>
Date:   Mon Apr 25 13:17:02 2022 -0500

    RDMA/irdma: Reduce iWARP QP destroy time
    
    commit 2df6d895907b2f5dfbc558cbff7801bba82cb3cc upstream.
    
    QP destroy is synchronous and waits for its refcnt to be decremented in
    irdma_cm_node_free_cb (for iWARP) which fires after the RCU grace period
    elapses.
    
    Applications running a large number of connections are exposed to high
    wait times on destroy QP for events like SIGABORT.
    
    The long pole for this wait time is the firing of the call_rcu callback
    during a CM node destroy which can be slow. It holds the QP reference
    count and blocks the destroy QP from completing.
    
    call_rcu only needs to make sure that list walkers have a reference to the
    cm_node object before freeing it and thus need to wait for grace period
    elapse. The rest of the connection teardown in irdma_cm_node_free_cb is
    moved out of the grace period wait in irdma_destroy_connection. Also,
    replace call_rcu with a simple kfree_rcu as it just needs to do a kfree on
    the cm_node
    
    Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager")
    Link: https://lore.kernel.org/r/20220425181703.1634-3-shiraz.saleem@intel.com
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/siw: Fix a condition race issue in MPA request processing [+ + +]
Author: Cheng Xu <chengyou@linux.alibaba.com>
Date:   Sun Apr 24 16:01:03 2022 +0800

    RDMA/siw: Fix a condition race issue in MPA request processing
    
    commit ef91271c65c12d36e4c2b61c61d4849fb6d11aa0 upstream.
    
    The calling of siw_cm_upcall and detaching new_cep with its listen_cep
    should be atomistic semantics. Otherwise siw_reject may be called in a
    temporary state, e,g, siw_cm_upcall is called but the new_cep->listen_cep
    has not being cleared.
    
    This fixes a WARN:
    
      WARNING: CPU: 7 PID: 201 at drivers/infiniband/sw/siw/siw_cm.c:255 siw_cep_put+0x125/0x130 [siw]
      CPU: 2 PID: 201 Comm: kworker/u16:22 Kdump: loaded Tainted: G            E     5.17.0-rc7 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
      Workqueue: iw_cm_wq cm_work_handler [iw_cm]
      RIP: 0010:siw_cep_put+0x125/0x130 [siw]
      Call Trace:
       <TASK>
       siw_reject+0xac/0x180 [siw]
       iw_cm_reject+0x68/0xc0 [iw_cm]
       cm_work_handler+0x59d/0xe20 [iw_cm]
       process_one_work+0x1e2/0x3b0
       worker_thread+0x50/0x3a0
       ? rescuer_thread+0x390/0x390
       kthread+0xe5/0x110
       ? kthread_complete_and_exit+0x20/0x20
       ret_from_fork+0x1f/0x30
       </TASK>
    
    Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
    Link: https://lore.kernel.org/r/d528d83466c44687f3872eadcb8c184528b2e2d4.1650526554.git.chengyou@linux.alibaba.com
    Reported-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Bernard Metzler <bmt@zurich.ibm.com>
    Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "parisc: Mark cr16 CPU clocksource unstable on all SMP machines" [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sat May 7 15:31:16 2022 +0200

    Revert "parisc: Mark cr16 CPU clocksource unstable on all SMP machines"
    
    commit 9dc4241bb14afecd16518a0760bceb3d7359b12a upstream.
    
    This reverts commit afdb4a5b1d340e4afffc65daa21cc71890d7d589.
    
    It triggers RCU stalls at boot with a 32-bit kernel.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Noticed-by: John David Anglin <dave.anglin@bell.net>
    Cc: stable@vger.kernel.org # v5.16+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "parisc: Mark sched_clock unstable only if clocks are not syncronized" [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sat May 7 15:32:38 2022 +0200

    Revert "parisc: Mark sched_clock unstable only if clocks are not syncronized"
    
    commit 7962c0896429af2a0e00ec6bc15d992536453b2d upstream.
    
    This reverts commit d97180ad68bdb7ee10f327205a649bc2f558741d.
    
    It triggers RCU stalls at boot with a 32-bit kernel.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Noticed-by: John David Anglin <dave.anglin@bell.net>
    Cc: stable@vger.kernel.org # v5.15+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "SUNRPC: attempt AF_LOCAL connect on setup" [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Apr 29 12:27:30 2022 -0400

    Revert "SUNRPC: attempt AF_LOCAL connect on setup"
    
    commit a3d0562d4dc039bca39445e1cddde7951662e17d upstream.
    
    This reverts commit 7073ea8799a8cf73db60270986f14e4aae20fa80.
    
    We must not try to connect the socket while the transport is under
    construction, because the mechanisms to safely tear it down are not in
    place. As the code stands, we end up leaking the sockets on a connection
    error.
    
    Reported-by: wanghai (M) <wanghai38@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RISC-V: relocate DTB if it's outside memory region [+ + +]
Author: Nick Kossifidis <mick@ics.forth.gr>
Date:   Tue Mar 22 15:28:39 2022 +0200

    RISC-V: relocate DTB if it's outside memory region
    
    commit c6fe81191bd74f7e6ae9ce96a4837df9485f3ab8 upstream.
    
    In case the DTB provided by the bootloader/BootROM is before the kernel
    image or outside /memory, we won't be able to access it through the
    linear mapping, and get a segfault on setup_arch(). Currently OpenSBI
    relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR
    is not specified), and it's also not the most portable approach since
    the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB
    at a specific offset that may not be available. To avoid this situation
    copy DTB so that it's visible through the linear mapping.
    
    Signed-off-by: Nick Kossifidis <mick@ics.forth.gr>
    Link: https://lore.kernel.org/r/20220322132839.3653682-1-mick@ics.forth.gr
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Fixes: f105aa940e78 ("riscv: add BUILTIN_DTB support for MMU-enabled targets")
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rxrpc: Enable IPv6 checksums on transport socket [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Apr 29 21:05:16 2022 +0100

    rxrpc: Enable IPv6 checksums on transport socket
    
    commit 39cb9faa5d46d0d0694f4b594ef905f517600c8e upstream.
    
    AF_RXRPC doesn't currently enable IPv6 UDP Tx checksums on the transport
    socket it opens and the checksums in the packets it generates end up 0.
    
    It probably should also enable IPv6 UDP Rx checksums and IPv4 UDP
    checksums.  The latter only seem to be applied if the socket family is
    AF_INET and don't seem to apply if it's AF_INET6.  IPv4 packets from an
    IPv6 socket seem to have checksums anyway.
    
    What seems to have happened is that the inet_inv_convert_csum() call didn't
    get converted to the appropriate udp_port_cfg parameters - and
    udp_sock_create() disables checksums unless explicitly told not too.
    
    Fix this by enabling the three udp_port_cfg checksum options.
    
    Fixes: 1a9b86c9fd95 ("rxrpc: use udp tunnel APIs instead of open code in rxrpc_open_socket")
    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: Vadim Fedorenko <vfedorenko@novek.ru>
    cc: David S. Miller <davem@davemloft.net>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/dasd: fix data corruption for ESE devices [+ + +]
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu May 5 16:17:29 2022 +0200

    s390/dasd: fix data corruption for ESE devices
    
    commit 5b53a405e4658580e1faf7c217db3f55a21ba849 upstream.
    
    For ESE devices we get an error when accessing an unformatted track.
    The handling of this error will return zero data for read requests and
    format the track on demand before writing to it. To do this the code needs
    to distinguish between read and write requests. This is done with data from
    the blocklayer request. A pointer to the blocklayer request is stored in
    the CQR.
    
    If there is an error on the device an ERP request is built to do error
    recovery. While the ERP request is mostly a copy of the original CQR the
    pointer to the blocklayer request is not copied to not accidentally pass
    it back to the blocklayer without cleanup.
    
    This leads to the error that during ESE handling after an ERP request was
    built it is not possible to determine the IO direction. This leads to the
    formatting of a track for read requests which might in turn lead to data
    corruption.
    
    Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes")
    Cc: stable@vger.kernel.org # 5.3+
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220505141733.1989450-2-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/dasd: Fix read for ESE with blksize < 4k [+ + +]
Author: Jan Höppner <hoeppner@linux.ibm.com>
Date:   Thu May 5 16:17:31 2022 +0200

    s390/dasd: Fix read for ESE with blksize < 4k
    
    commit cd68c48ea15c85f1577a442dc4c285e112ff1b37 upstream.
    
    When reading unformatted tracks on ESE devices, the corresponding memory
    areas are simply set to zero for each segment. This is done incorrectly
    for blocksizes < 4096.
    
    There are two problems. First, the increment of dst is done using the
    counter of the loop (off), which is increased by blksize every
    iteration. This leads to a much bigger increment for dst as actually
    intended. Second, the increment of dst is done before the memory area
    is set to 0, skipping a significant amount of bytes of memory.
    
    This leads to illegal overwriting of memory and ultimately to a kernel
    panic.
    
    This is not a problem with 4k blocksize because
    blk_queue_max_segment_size is set to PAGE_SIZE, always resulting in a
    single iteration for the inner segment loop (bv.bv_len == blksize). The
    incorrectly used 'off' value to increment dst is 0 and the correct
    memory area is used.
    
    In order to fix this for blksize < 4k, increment dst correctly using the
    blksize and only do it at the end of the loop.
    
    Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes")
    Cc: stable@vger.kernel.org # v5.3+
    Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
    Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220505141733.1989450-4-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/dasd: Fix read inconsistency for ESE DASD devices [+ + +]
Author: Jan Höppner <hoeppner@linux.ibm.com>
Date:   Thu May 5 16:17:32 2022 +0200

    s390/dasd: Fix read inconsistency for ESE DASD devices
    
    commit b9c10f68e23c13f56685559a0d6fdaca9f838324 upstream.
    
    Read requests that return with NRF error are partially completed in
    dasd_eckd_ese_read(). The function keeps track of the amount of
    processed bytes and the driver will eventually return this information
    back to the block layer for further processing via __dasd_cleanup_cqr()
    when the request is in the final stage of processing (from the driver's
    perspective).
    
    For this, blk_update_request() is used which requires the number of
    bytes to complete the request. As per documentation the nr_bytes
    parameter is described as follows:
       "number of bytes to complete for @req".
    
    This was mistakenly interpreted as "number of bytes _left_ for @req"
    leading to new requests with incorrect data length. The consequence are
    inconsistent and completely wrong read requests as data from random
    memory areas are read back.
    
    Fix this by correctly specifying the amount of bytes that should be used
    to complete the request.
    
    Fixes: 5e6bdd37c552 ("s390/dasd: fix data corruption for thin provisioned devices")
    Cc: stable@vger.kernel.org # 5.3+
    Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
    Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220505141733.1989450-5-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/dasd: prevent double format of tracks for ESE devices [+ + +]
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Thu May 5 16:17:30 2022 +0200

    s390/dasd: prevent double format of tracks for ESE devices
    
    commit 71f3871657370dbbaf942a1c758f64e49a36c70f upstream.
    
    For ESE devices we get an error for write operations on an unformatted
    track. Afterwards the track will be formatted and the IO operation
    restarted.
    When using alias devices a track might be accessed by multiple requests
    simultaneously and there is a race window that a track gets formatted
    twice resulting in data loss.
    
    Prevent this by remembering the amount of formatted tracks when starting
    a request and comparing this number before actually formatting a track
    on the fly. If the number has changed there is a chance that the current
    track was finally formatted in between. As a result do not format the
    track and restart the current IO to check.
    
    The number of formatted tracks does not match the overall number of
    formatted tracks on the device and it might wrap around but this is no
    problem. It is only needed to recognize that a track has been formatted at
    all in between.
    
    Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes")
    Cc: stable@vger.kernel.org # 5.3+
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220505141733.1989450-3-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftest/vm: verify mmap addr in mremap_test [+ + +]
Author: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Date:   Thu Apr 21 16:35:49 2022 -0700

    selftest/vm: verify mmap addr in mremap_test
    
    [ Upstream commit 9c85a9bae267f6b5e5e374d0d023bbbe9db096d3 ]
    
    Avoid calling mmap with requested addresses that are less than the
    system's mmap_min_addr.  When run as root, mmap returns EACCES when
    trying to map addresses < mmap_min_addr.  This is not one of the error
    codes for the condition to retry the mmap in the test.
    
    Rather than arbitrarily retrying on EACCES, don't attempt an mmap until
    addr > vm.mmap_min_addr.
    
    Add a munmap call after an alignment check as the mappings are retained
    after the retry and can reach the vm.max_map_count sysctl.
    
    Link: https://lkml.kernel.org/r/20220420215721.4868-1-sidhartha.kumar@oracle.com
    Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftest/vm: verify remap destination address in mremap_test [+ + +]
Author: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Date:   Thu Apr 21 16:35:52 2022 -0700

    selftest/vm: verify remap destination address in mremap_test
    
    [ Upstream commit 18d609daa546c919fd36b62a7b510c18de4b4af8 ]
    
    Because mremap does not have a MAP_FIXED_NOREPLACE flag, it can destroy
    existing mappings.  This causes a segfault when regions such as text are
    remapped and the permissions are changed.
    
    Verify the requested mremap destination address does not overlap any
    existing mappings by using mmap's MAP_FIXED_NOREPLACE flag.  Keep
    incrementing the destination address until a valid mapping is found or
    fail the current test once the max address is reached.
    
    Link: https://lkml.kernel.org/r/20220420215721.4868-2-sidhartha.kumar@oracle.com
    Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/net: so_txtime: fix parsing of start time stamp on 32 bit systems [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Mon May 2 11:46:37 2022 +0200

    selftests/net: so_txtime: fix parsing of start time stamp on 32 bit systems
    
    commit 97926d5a847ca1758ad8702ce591e3b05a701e0d upstream.
    
    This patch fixes the parsing of the cmd line supplied start time on 32
    bit systems. A "long" on 32 bit systems is only 32 bit wide and cannot
    hold a timestamp in nano second resolution.
    
    Fixes: 040806343bb4 ("selftests/net: so_txtime multi-host support")
    Cc: Carlos Llamas <cmllamas@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20220502094638.1921702-2-mkl@pengutronix.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests/net: so_txtime: usage(): fix documentation of default clock [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Mon May 2 11:46:38 2022 +0200

    selftests/net: so_txtime: usage(): fix documentation of default clock
    
    commit f5c2174a3775491e890ce285df52f5715fbef875 upstream.
    
    The program uses CLOCK_TAI as default clock since it was added to the
    Linux repo. In commit:
    | 040806343bb4 ("selftests/net: so_txtime multi-host support")
    a help text stating the wrong default clock was added.
    
    This patch fixes the help text.
    
    Fixes: 040806343bb4 ("selftests/net: so_txtime multi-host support")
    Cc: Carlos Llamas <cmllamas@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20220502094638.1921702-3-mkl@pengutronix.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/seccomp: Don't call read() on TTY from background pgrp [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Sat Mar 19 02:00:11 2022 +0100

    selftests/seccomp: Don't call read() on TTY from background pgrp
    
    commit 2bfed7d2ffa5d86c462d3e2067f2832eaf8c04c7 upstream.
    
    Since commit 92d25637a3a4 ("kselftest: signal all child processes"), tests
    are executed in background process groups. This means that trying to read
    from stdin now throws SIGTTIN when stdin is a TTY, which breaks some
    seccomp selftests that try to use read(0, NULL, 0) as a dummy syscall.
    
    The simplest way to fix that is probably to just use -1 instead of 0 as
    the dummy read()'s FD.
    
    Fixes: 92d25637a3a4 ("kselftest: signal all child processes")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220319010011.1374622-1-jannh@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests: mirror_gre_bridge_1q: Avoid changing PVID while interface is operational [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon May 2 11:45:07 2022 +0300

    selftests: mirror_gre_bridge_1q: Avoid changing PVID while interface is operational
    
    commit 3122257c02afd9f199a8fc84ae981e1fc4958532 upstream.
    
    In emulated environments, the bridge ports enslaved to br1 get a carrier
    before changing br1's PVID. This means that by the time the PVID is
    changed, br1 is already operational and configured with an IPv6
    link-local address.
    
    When the test is run with netdevs registered by mlxsw, changing the PVID
    is vetoed, as changing the VID associated with an existing L3 interface
    is forbidden. This restriction is similar to the 8021q driver's
    restriction of changing the VID of an existing interface.
    
    Fix this by taking br1 down and bringing it back up when it is fully
    configured.
    
    With this fix, the test reliably passes on top of both the SW and HW
    data paths (emulated or not).
    
    Fixes: 239e754af854 ("selftests: forwarding: Test mirror-to-gretap w/ UL 802.1q")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Link: https://lore.kernel.org/r/20220502084507.364774-1-idosch@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: ocelot: tc_flower_chains: specify conform-exceed action for policer [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue May 3 15:14:28 2022 +0300

    selftests: ocelot: tc_flower_chains: specify conform-exceed action for policer
    
    commit 5a7c5f70c743c6cf32b44b05bd6b19d4ad82f49d upstream.
    
    As discussed here with Ido Schimmel:
    https://patchwork.kernel.org/project/netdevbpf/patch/20220224102908.5255-2-jianbol@nvidia.com/
    
    the default conform-exceed action is "reclassify", for a reason we don't
    really understand.
    
    The point is that hardware can't offload that police action, so not
    specifying "conform-exceed" was always wrong, even though the command
    used to work in hardware (but not in software) until the kernel started
    adding validation for it.
    
    Fix the command used by the selftest by making the policer drop on
    exceed, and pass the packet to the next action (goto) on conform.
    
    Fixes: 8cd6b020b644 ("selftests: ocelot: add some example VCAP IS1, IS2 and ES0 tc offloads")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://lore.kernel.org/r/20220503121428.842906-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smsc911x: allow using IRQ0 [+ + +]
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Mon May 2 23:14:09 2022 +0300

    smsc911x: allow using IRQ0
    
    commit 5ef9b803a4af0f5e42012176889b40bb2a978b18 upstream.
    
    The AlphaProject AP-SH4A-3A/AP-SH4AD-0A SH boards use IRQ0 for their SMSC
    LAN911x Ethernet chip, so the networking on them must have been broken by
    commit 965b2aa78fbc ("net/smsc911x: fix irq resource allocation failure")
    which filtered out 0 as well as the negative error codes -- it was kinda
    correct at the time, as platform_get_irq() could return 0 on of_irq_get()
    failure and on the actual 0 in an IRQ resource.  This issue was fixed by
    me (back in 2016!), so we should be able to fix this driver to allow IRQ0
    usage again...
    
    When merging this to the stable kernels, make sure you also merge commit
    e330b9a6bb35 ("platform: don't return 0 from platform_get_irq[_byname]()
    on error") -- that's my fix to platform_get_irq() for the DT platforms...
    
    Fixes: 965b2aa78fbc ("net/smsc911x: fix irq resource allocation failure")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/656036e4-6387-38df-b8a7-6ba683b16e63@omp.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: SUNRPC release the transport of a relocated task with an assigned transport [+ + +]
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Thu Apr 21 10:32:34 2022 -0400

    SUNRPC release the transport of a relocated task with an assigned transport
    
    commit e13433b4416fa31a24e621cbbbb39227a3d651dd upstream.
    
    A relocated task must release its previous transport.
    
    Fixes: 82ee41b85cef1 ("SUNRPC don't resend a task on an offlined transport")
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SUNRPC: Don't leak sockets in xs_local_connect() [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Apr 28 11:08:13 2022 -0400

    SUNRPC: Don't leak sockets in xs_local_connect()
    
    commit aad41a7d7cf6c6fa804c872a2480f8e541da37cf upstream.
    
    If there is still a closed socket associated with the transport, then we
    need to trigger an autoclose before we can set up a new connection.
    
    Reported-by: wanghai (M) <wanghai38@huawei.com>
    Fixes: f00432063db1 ("SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
timekeeping: Mark NMI safe time accessors as notrace [+ + +]
Author: Kurt Kanzenbach <kurt@linutronix.de>
Date:   Thu Apr 28 08:24:32 2022 +0200

    timekeeping: Mark NMI safe time accessors as notrace
    
    commit 2c33d775ef4c25c0e1e1cc0fd5496d02f76bfa20 upstream.
    
    Mark the CLOCK_MONOTONIC fast time accessors as notrace. These functions are
    used in tracing to retrieve timestamps, so they should not recurse.
    
    Fixes: 4498e7467e9e ("time: Parametrize all tk_fast_mono users")
    Fixes: f09cb9a1808e ("time: Introduce tk_fast_raw")
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220426175338.3807ca4f@gandalf.local.home/
    Link: https://lore.kernel.org/r/20220428062432.61063-1-kurt@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/fpu: Prevent FPU state corruption [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun May 1 21:31:43 2022 +0200

    x86/fpu: Prevent FPU state corruption
    
    commit 59f5ede3bc0f00eb856425f636dab0c10feb06d8 upstream.
    
    The FPU usage related to task FPU management is either protected by
    disabling interrupts (switch_to, return to user) or via fpregs_lock() which
    is a wrapper around local_bh_disable(). When kernel code wants to use the
    FPU then it has to check whether it is possible by calling irq_fpu_usable().
    
    But the condition in irq_fpu_usable() is wrong. It allows FPU to be used
    when:
    
       !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle()
    
    The latter is checking whether some other context already uses FPU in the
    kernel, but if that's not the case then it allows FPU to be used
    unconditionally even if the calling context interrupted a fpregs_lock()
    critical region. If that happens then the FPU state of the interrupted
    context becomes corrupted.
    
    Allow in kernel FPU usage only when no other context has in kernel FPU
    usage and either the calling context is not hard interrupt context or the
    hard interrupt did not interrupt a local bottomhalf disabled region.
    
    It's hard to find a proper Fixes tag as the condition was broken in one way
    or the other for a very long time and the eager/lazy FPU changes caused a
    lot of churn. Picked something remotely connected from the history.
    
    This survived undetected for quite some time as FPU usage in interrupt
    context is rare, but the recent changes to the random code unearthed it at
    least on a kernel which had FPU debugging enabled. There is probably a
    higher rate of silent corruption as not all issues can be detected by the
    FPU debugging code. This will be addressed in a subsequent change.
    
    Fixes: 5d2bd7009f30 ("x86, fpu: decouple non-lazy/eager fpu restore from xsave")
    Reported-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220501193102.588689270@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/kvm: Preserve BSP MSR_KVM_POLL_CONTROL across suspend/resume [+ + +]
Author: Wanpeng Li <wanpengli@tencent.com>
Date:   Mon Apr 18 00:42:32 2022 -0700

    x86/kvm: Preserve BSP MSR_KVM_POLL_CONTROL across suspend/resume
    
    [ Upstream commit 0361bdfddca20c8855ea3bdbbbc9c999912b10ff ]
    
    MSR_KVM_POLL_CONTROL is cleared on reset, thus reverting guests to
    host-side polling after suspend/resume.  Non-bootstrap CPUs are
    restored correctly by the haltpoll driver because they are hot-unplugged
    during suspend and hot-plugged during resume; however, the BSP
    is not hotpluggable and remains in host-sde polling mode after
    the guest resume.  The makes the guest pay for the cost of vmexits
    every time the guest enters idle.
    
    Fix it by recording BSP's haltpoll state and resuming it during guest
    resume.
    
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
    Message-Id: <1650267752-46796-1-git-send-email-wanpengli@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>