Linux 6.1.21

 
ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent [+ + +]
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Wed Mar 8 11:26:32 2023 +0000

    ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent
    
    commit 91d7b60a65d9f71230ea09b86d2058a884a3c2af upstream.
    
    Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
    enabled to map PPTT once on the first invocation of acpi_get_pptt() and
    never unmapped the same allowing it to be used at runtime with out the
    hassle of mapping and unmapping the table. This was needed to fetch LLC
    information from the PPTT in the cpuhotplug path which is executed in
    the atomic context as the acpi_get_table() might sleep waiting for a
    mutex.
    
    However it missed to handle the case when there is no PPTT on the system
    which results in acpi_get_pptt() being called from all the secondary
    CPUs attempting to fetch the LLC information in the atomic context
    without knowing the absence of PPTT resulting in the splat like below:
    
     | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164
     | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
     | preempt_count: 1, expected: 0
     | RCU nest depth: 0, expected: 0
     | no locks held by swapper/1/0.
     | irq event stamp: 0
     | hardirqs last  enabled at (0): 0x0
     | hardirqs last disabled at (0): copy_process+0x61c/0x1b40
     | softirqs last  enabled at (0): copy_process+0x61c/0x1b40
     | softirqs last disabled at (0): 0x0
     | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1
     | Call trace:
     |  dump_backtrace+0xac/0x138
     |  show_stack+0x30/0x48
     |  dump_stack_lvl+0x60/0xb0
     |  dump_stack+0x18/0x28
     |  __might_resched+0x160/0x270
     |  __might_sleep+0x58/0xb0
     |  down_timeout+0x34/0x98
     |  acpi_os_wait_semaphore+0x7c/0xc0
     |  acpi_ut_acquire_mutex+0x58/0x108
     |  acpi_get_table+0x40/0xe8
     |  acpi_get_pptt+0x48/0xa0
     |  acpi_get_cache_info+0x38/0x140
     |  init_cache_level+0xf4/0x118
     |  detect_cache_attributes+0x2e4/0x640
     |  update_siblings_masks+0x3c/0x330
     |  store_cpu_topology+0x88/0xf0
     |  secondary_start_kernel+0xd0/0x168
     |  __secondary_switched+0xb8/0xc0
    
    Update acpi_get_pptt() to consider the fact that PPTT is once checked and
    is not available on the system and return NULL avoiding any attempts to
    fetch PPTT and thereby avoiding any possible sleep waiting for a mutex
    in the atomic context.
    
    Fixes: 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
    Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Tested-by: Pierre Gondois <pierre.gondois@arm.com>
    Cc: 6.0+ <stable@vger.kernel.org> # 6.0+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: hda/realtek: fix speaker, mute/micmute LEDs not work on a HP platform [+ + +]
Author: Jeremy Szu <jeremy.szu@canonical.com>
Date:   Tue Mar 7 21:53:16 2023 +0800

    ALSA: hda/realtek: fix speaker, mute/micmute LEDs not work on a HP platform
    
    commit 7bb62340951a9af20235a3bde8c98e2e292915df upstream.
    
    There is a HP platform needs ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED quirk to
    make mic-mute/audio-mute/speaker working.
    
    Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230307135317.37621-1-jeremy.szu@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book2 Pro [+ + +]
Author: Hamidreza H. Fard <nitocris@posteo.net>
Date:   Tue Mar 7 16:37:41 2023 +0000

    ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book2 Pro
    
    commit a86e79e3015f5dd8e1b01ccfa49bd5c6e41047a1 upstream.
    
    Samsung Galaxy Book2 Pro (13" 2022 NP930XED-KA1DE) with codec SSID
    144d:c868 requires the same workaround for enabling the speaker amp
    like other Samsung models with ALC298 code.
    
    Signed-off-by: Hamidreza H. Fard <nitocris@posteo.net>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230307163741.3878-1-nitocris@posteo.net
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: intel-dsp-config: add MTL PCI id [+ + +]
Author: Bard Liao <yung-chuan.liao@linux.intel.com>
Date:   Mon Mar 6 15:41:01 2023 +0800

    ALSA: hda: intel-dsp-config: add MTL PCI id
    
    commit bbdf904b13a62bb8b1272d92a7dde082dff86fbb upstream.
    
    Use SOF as default audio driver.
    
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Gongjun Song <gongjun.song@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230306074101.3906707-1-yung-chuan.liao@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: Match only Intel devices with CONTROLLER_IN_GPU() [+ + +]
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Mar 7 15:40:54 2023 -0600

    ALSA: hda: Match only Intel devices with CONTROLLER_IN_GPU()
    
    [ Upstream commit ff447886e675979d66b2bc01810035d3baea1b3a ]
    
    CONTROLLER_IN_GPU() is clearly intended to match only Intel devices, but
    previously it checked only the PCI Device ID, not the Vendor ID, so it
    could match devices from other vendors that happened to use the same Device
    ID.
    
    Update CONTROLLER_IN_GPU() so it matches only Intel devices.
    
    Fixes: 535115b5ff51 ("ALSA: hda - Abort the probe without i915 binding for HSW/B")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://lore.kernel.org/r/20230307214054.886721-1-helgaas@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: Intel: soc-acpi: fix copy-paste issue in topology names [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Mar 7 12:07:33 2023 +0200

    ASoC: Intel: soc-acpi: fix copy-paste issue in topology names
    
    commit 858a438a6cf919e5727d2a0f5f3f0e68b2d5354e upstream.
    
    For some reason the convention for topology names was not followed and
    the name inspired by another unrelated hardware configuration. As a
    result, the kernel will request a non-existent topology file.
    
    Link: https://github.com/thesofproject/sof/pull/6878
    Fixes: 2ec8b081d59f ("ASoC: Intel: soc-acpi: Add entry for sof_es8336 in ADL match table")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230307100733.15025-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: qcom: q6prm: fix incorrect clk_root passed to ADSP [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Mar 2 13:29:08 2023 +0100

    ASoC: qcom: q6prm: fix incorrect clk_root passed to ADSP
    
    commit 65882134bc622a1e57bd5928ac588855ea2e3ddd upstream.
    
    The second to last argument is clk_root (root of the clock), however the
    code called q6prm_request_lpass_clock() with clk_attr instead
    (copy-paste error).  This effectively was passing value of 1 as root
    clock which worked on some of the SoCs (e.g. SM8450) but fails on
    others, depending on the ADSP.  For example on SM8550 this "1" as root
    clock is not accepted and results in errors coming from ADSP.
    
    Fixes: 2f20640491ed ("ASoC: qdsp6: qdsp6: q6prm: handle clk disable correctly")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230302122908.221398-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: SOF: Intel: HDA: Fix device description [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Tue Mar 7 11:39:12 2023 +0200

    ASoC: SOF: Intel: HDA: Fix device description
    
    [ Upstream commit 9eb2b4cac223095d2079a6d52b8bbddc6e064288 ]
    
    Add the missing ops_free callback for APL/CNL/CML/JSL/TGL/EHL platforms.
    
    Fixes: 1da51943725f ("ASoC: SOF: Intel: hda: init NHLT for IPC4")
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230307093914.25409-3-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: MTL: Fix the device description [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Tue Mar 7 11:39:11 2023 +0200

    ASoC: SOF: Intel: MTL: Fix the device description
    
    [ Upstream commit a659e35ca0af2765f567bdfdccfa247eff0cdab8 ]
    
    Add the missing ops_free callback.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230307093914.25409-2-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASOC: SOF: Intel: pci-tgl: Fix device description [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Tue Mar 7 11:39:14 2023 +0200

    ASOC: SOF: Intel: pci-tgl: Fix device description
    
    [ Upstream commit 376f79bbf521fc37b871b536276319951b5bef3a ]
    
    Add the missing ops_free callback.
    
    Fixes: 63d375b9f2a9 ("ASoC: SOF: Intel: pci-tgl: use RPL specific firmware definitions")
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230307093914.25409-5-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: SOF: Intel: SKL: Fix device description [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Tue Mar 7 11:39:13 2023 +0200

    ASoC: SOF: Intel: SKL: Fix device description
    
    [ Upstream commit 1f320bdb29b644a2c9fb301a6fb2d6170e6417e9 ]
    
    Add missing ops_free callback for SKL/KBL platforms.
    
    Fixes: 52d7939d10f2 ("ASoC: SOF: Intel: add ops for SKL/KBL")
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230307093914.25409-4-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: ipc4-topology: set dmic dai index from copier [+ + +]
Author: Jaska Uimonen <jaska.uimonen@linux.intel.com>
Date:   Tue Mar 7 13:07:30 2023 +0200

    ASoC: SOF: ipc4-topology: set dmic dai index from copier
    
    [ Upstream commit c99e48f4ce9b986ab7992ec7283a06dae875f668 ]
    
    Dmic dai index was set incorrectly to bits 5-7, when it is actually using
    just the lowest 3. Fix the macro for setting the bits.
    
    Fixes: aa84ffb72158 ("ASoC: SOF: ipc4-topology: Add support for SSP/DMIC DAI's")
    Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com>
    Reviewed-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230307110730.1995-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: do not reverse request order when flushing plug list [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Mar 13 10:30:02 2023 +0100

    block: do not reverse request order when flushing plug list
    
    [ Upstream commit 34e0a279a993debaff03158fc2fbf6a00c093643 ]
    
    Commit 26fed4ac4eab ("block: flush plug based on hardware and software
    queue order") changed flushing of plug list to submit requests one
    device at a time. However while doing that it also started using
    list_add_tail() instead of list_add() used previously thus effectively
    submitting requests in reverse order. Also when forming a rq_list with
    remaining requests (in case two or more devices are used), we
    effectively reverse the ordering of the plug list for each device we
    process. Submitting requests in reverse order has negative impact on
    performance for rotational disks (when BFQ is not in use). We observe
    10-25% regression in random 4k write throughput, as well as ~20%
    regression in MariaDB OLTP benchmark on rotational storage on btrfs
    filesystem.
    
    Fix the problem by preserving ordering of the plug list when inserting
    requests into the queuelist as well as by appending to requeue_list
    instead of prepending to it.
    
    Fixes: 26fed4ac4eab ("block: flush plug based on hardware and software queue order")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230313093002.11756-1-jack@suse.cz
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: null_blk: Fix handling of fake timeout request [+ + +]
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Tue Mar 14 13:11:05 2023 +0900

    block: null_blk: Fix handling of fake timeout request
    
    [ Upstream commit 63f886597085f346276e3b3c8974de0100d65f32 ]
    
    When injecting a fake timeout into the null_blk driver using
    fail_io_timeout, the request timeout handler does not execute
    blk_mq_complete_request(), so the complete callback is never executed
    for a timedout request.
    
    The null_blk driver also has a driver-specific fake timeout mechanism
    which does not have this problem. Fix the problem with fail_io_timeout
    by using the same meachanism as null_blk internal timeout feature, using
    the fake_timeout field of null_blk commands.
    
    Reported-by: Akinobu Mita <akinobu.mita@gmail.com>
    Fixes: de3510e52b0a ("null_blk: fix command timeout completion handling")
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Link: https://lore.kernel.org/r/20230314041106.19173-2-damien.lemoal@opensource.wdc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: sunvdc: add check for mdesc_grab() returning NULL [+ + +]
Author: Liang He <windhl@126.com>
Date:   Wed Mar 15 14:20:32 2023 +0800

    block: sunvdc: add check for mdesc_grab() returning NULL
    
    [ Upstream commit 6030363199e3a6341afb467ddddbed56640cbf6a ]
    
    In vdc_port_probe(), we should check the return value of mdesc_grab() as
    it may return NULL, which can cause potential NPD bug.
    
    Fixes: 43fdf27470b2 ("[SPARC64]: Abstract out mdesc accesses for better MD update handling.")
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20230315062032.1741692-1-windhl@126.com
    [axboe: style cleanup]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Wed Mar 15 13:18:41 2023 +0200

    bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails
    
    [ Upstream commit e667d469098671261d558be0cd93dca4d285ce1e ]
    
    syzbot reported a warning[1] where the bond device itself is a slave and
    we try to enslave a non-ethernet device as the first slave which fails
    but then in the error path when ether_setup() restores the bond device
    it also clears all flags. In my previous fix[2] I restored the
    IFF_MASTER flag, but I didn't consider the case that the bond device
    itself might also be a slave with IFF_SLAVE set, so we need to restore
    that flag as well. Use the bond_ether_setup helper which does the right
    thing and restores the bond's flags properly.
    
    Steps to reproduce using a nlmon dev:
     $ ip l add nlmon0 type nlmon
     $ ip l add bond1 type bond
     $ ip l add bond2 type bond
     $ ip l set bond1 master bond2
     $ ip l set dev nlmon0 master bond1
     $ ip -d l sh dev bond1
     22: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000
     (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we
      try to delete it)
    
    [1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef
    [2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")
    [3] example warning:
     [   27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address
     [   27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address
     [   32.464639] bond1 (unregistering): Released all slaves
     [   32.464685] ------------[ cut here ]------------
     [   32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780
     [   32.464694] Modules linked in: br_netfilter bridge bonding virtio_net
     [   32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47
     [   32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
     [   32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780
     [   32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59
     [   32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206
     [   32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000
     [   32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520
     [   32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728
     [   32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140
     [   32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140
     [   32.464723] FS:  00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000
     [   32.464725] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     [   32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0
     [   32.464730] Call Trace:
     [   32.464763]  <TASK>
     [   32.464767]  rtnl_dellink+0x13e/0x380
     [   32.464776]  ? cred_has_capability.isra.0+0x68/0x100
     [   32.464780]  ? __rtnl_unlock+0x33/0x60
     [   32.464783]  ? bpf_lsm_capset+0x10/0x10
     [   32.464786]  ? security_capable+0x36/0x50
     [   32.464790]  rtnetlink_rcv_msg+0x14e/0x3b0
     [   32.464792]  ? _copy_to_iter+0xb1/0x790
     [   32.464796]  ? post_alloc_hook+0xa0/0x160
     [   32.464799]  ? rtnl_calcit.isra.0+0x110/0x110
     [   32.464802]  netlink_rcv_skb+0x50/0xf0
     [   32.464806]  netlink_unicast+0x216/0x340
     [   32.464809]  netlink_sendmsg+0x23f/0x480
     [   32.464812]  sock_sendmsg+0x5e/0x60
     [   32.464815]  ____sys_sendmsg+0x22c/0x270
     [   32.464818]  ? import_iovec+0x17/0x20
     [   32.464821]  ? sendmsg_copy_msghdr+0x59/0x90
     [   32.464823]  ? do_set_pte+0xa0/0xe0
     [   32.464828]  ___sys_sendmsg+0x81/0xc0
     [   32.464832]  ? mod_objcg_state+0xc6/0x300
     [   32.464835]  ? refill_obj_stock+0xa9/0x160
     [   32.464838]  ? memcg_slab_free_hook+0x1a5/0x1f0
     [   32.464842]  __sys_sendmsg+0x49/0x80
     [   32.464847]  do_syscall_64+0x3b/0x90
     [   32.464851]  entry_SYSCALL_64_after_hwframe+0x44/0xae
     [   32.464865] RIP: 0033:0x7f297bf2e5e7
     [   32.464868] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
     [   32.464869] RSP: 002b:00007ffd96c824c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
     [   32.464872] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f297bf2e5e7
     [   32.464874] RDX: 0000000000000000 RSI: 00007ffd96c82540 RDI: 0000000000000003
     [   32.464875] RBP: 00000000640f19de R08: 0000000000000001 R09: 000000000000007c
     [   32.464876] R10: 00007f297bffabe0 R11: 0000000000000246 R12: 0000000000000001
     [   32.464877] R13: 00007ffd96c82d20 R14: 00007ffd96c82610 R15: 000055bfe38a7020
     [   32.464881]  </TASK>
     [   32.464882] ---[ end trace 0000000000000000 ]---
    
    Fixes: 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")
    Reported-by: syzbot+9dfc3f3348729cc82277@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Acked-by: Jonathan Toppins <jtoppins@redhat.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Wed Mar 15 13:18:40 2023 +0200

    bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change
    
    [ Upstream commit 9ec7eb60dcbcb6c41076defbc5df7bbd95ceaba5 ]
    
    Add bond_ether_setup helper which is used to fix ether_setup() calls in the
    bonding driver. It takes care of both IFF_MASTER and IFF_SLAVE flags, the
    former is always restored and the latter only if it was set.
    If the bond enslaves non-ARPHRD_ETHER device (changes its type), then
    releases it and enslaves ARPHRD_ETHER device (changes back) then we
    use ether_setup() to restore the bond device type but it also resets its
    flags and removes IFF_MASTER and IFF_SLAVE[1]. Use the bond_ether_setup
    helper to restore both after such transition.
    
    [1] reproduce (nlmon is non-ARPHRD_ETHER):
     $ ip l add nlmon0 type nlmon
     $ ip l add bond2 type bond mode active-backup
     $ ip l set nlmon0 master bond2
     $ ip l set nlmon0 nomaster
     $ ip l add bond1 type bond
     (we use bond1 as ARPHRD_ETHER device to restore bond2's mode)
     $ ip l set bond1 master bond2
     $ ip l sh dev bond2
     37: bond2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
        link/ether be:d7:c5:40:5b:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500
     (notice bond2's IFF_MASTER is missing)
    
    Fixes: e36b9d16c6a6 ("bonding: clean muticast addresses when device changes type")
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: Fix smb2_set_path_size() [+ + +]
Author: Volker Lendecke <vl@samba.org>
Date:   Mon Mar 13 16:09:54 2023 +0100

    cifs: Fix smb2_set_path_size()
    
    commit 211baef0eabf4169ce4f73ebd917749d1a7edd74 upstream.
    
    If cifs_get_writable_path() finds a writable file, smb2_compound_op()
    must use that file's FID and not the COMPOUND_FID.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Volker Lendecke <vl@samba.org>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: generate signkey for the channel that's reconnecting [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Fri Mar 10 15:32:01 2023 +0000

    cifs: generate signkey for the channel that's reconnecting
    
    commit 05ce0448c3f36febd8db0ee0e9e16557f3ab5ee8 upstream.
    
    Before my changes to how multichannel reconnects work, the
    primary channel was always used to do a non-binding session
    setup. With my changes, that is not the case anymore.
    Missed this place where channel at index 0 was forcibly
    updated with the signing key.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: Move the in_send statistic to __smb_send_rqst() [+ + +]
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Wed Nov 16 11:11:36 2022 +0800

    cifs: Move the in_send statistic to __smb_send_rqst()
    
    [ Upstream commit d0dc41119905f740e8d5594adce277f7c0de8c92 ]
    
    When send SMB_COM_NT_CANCEL and RFC1002_SESSION_REQUEST, the
    in_send statistic was lost.
    
    Let's move the in_send statistic to the send function to avoid
    this scenario.
    
    Fixes: 7ee1af765dfa ("[CIFS]")
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: HI655X: select REGMAP instead of depending on it [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 25 21:39:47 2023 -0800

    clk: HI655X: select REGMAP instead of depending on it
    
    [ Upstream commit 0ffad67784a097beccf34d297ddd1b0773b3b8a3 ]
    
    REGMAP is a hidden (not user visible) symbol. Users cannot set it
    directly thru "make *config", so drivers should select it instead of
    depending on it if they need it.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on REGMAP" to "select REGMAP".
    
    Fixes: 3a49afb84ca0 ("clk: enable hi655x common clk automatically")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Riku Voipio <riku.voipio@linaro.org>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: linux-clk@vger.kernel.org
    Link: https://lore.kernel.org/r/20230226053953.4681-3-rdunlap@infradead.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpuidle: psci: Iterate backwards over list in psci_pd_remove() [+ + +]
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Sat Mar 4 15:41:07 2023 +0800

    cpuidle: psci: Iterate backwards over list in psci_pd_remove()
    
    commit 6b0313c2fa3d2cf991c9ffef6fae6e7ef592ce6d upstream.
    
    In case that psci_pd_init_topology() fails for some reason,
    psci_pd_remove() will be responsible for deleting provider and removing
    genpd from psci_pd_providers list.  There will be a failure when removing
    the cluster PD, because the cpu (child) PDs haven't been removed.
    
    [    0.050232] CPUidle PSCI: init PM domain cpu0
    [    0.050278] CPUidle PSCI: init PM domain cpu1
    [    0.050329] CPUidle PSCI: init PM domain cpu2
    [    0.050370] CPUidle PSCI: init PM domain cpu3
    [    0.050422] CPUidle PSCI: init PM domain cpu-cluster0
    [    0.050475] PM: genpd_remove: unable to remove cpu-cluster0
    [    0.051412] PM: genpd_remove: removed cpu3
    [    0.051449] PM: genpd_remove: removed cpu2
    [    0.051499] PM: genpd_remove: removed cpu1
    [    0.051546] PM: genpd_remove: removed cpu0
    
    Fix the problem by iterating the provider list reversely, so that parent
    PD gets removed after child's PDs like below.
    
    [    0.029052] CPUidle PSCI: init PM domain cpu0
    [    0.029076] CPUidle PSCI: init PM domain cpu1
    [    0.029103] CPUidle PSCI: init PM domain cpu2
    [    0.029124] CPUidle PSCI: init PM domain cpu3
    [    0.029151] CPUidle PSCI: init PM domain cpu-cluster0
    [    0.029647] PM: genpd_remove: removed cpu0
    [    0.029666] PM: genpd_remove: removed cpu1
    [    0.029690] PM: genpd_remove: removed cpu2
    [    0.029714] PM: genpd_remove: removed cpu3
    [    0.029738] PM: genpd_remove: removed cpu-cluster0
    
    Fixes: a65a397f2451 ("cpuidle: psci: Add support for PM domains by using genpd")
    Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
    Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
docs: Correct missing "d_" prefix for dentry_operations member d_weak_revalidate [+ + +]
Author: Glenn Washburn <development@efficientek.com>
Date:   Mon Feb 27 12:40:42 2023 -0600

    docs: Correct missing "d_" prefix for dentry_operations member d_weak_revalidate
    
    [ Upstream commit 74596085796fae0cfce3e42ee46bf4f8acbdac55 ]
    
    The details for struct dentry_operations member d_weak_revalidate is
    missing a "d_" prefix.
    
    Fixes: af96c1e304f7 ("docs: filesystems: vfs: Convert vfs.txt to RST")
    Signed-off-by: Glenn Washburn <development@efficientek.com>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Link: https://lore.kernel.org/r/20230227184042.2375235-1-development@efficientek.com
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: disconnect MPCC only on OTG change [+ + +]
Author: Ayush Gupta <ayugupta@amd.com>
Date:   Thu Mar 2 09:58:05 2023 -0500

    drm/amd/display: disconnect MPCC only on OTG change
    
    commit 7304ee979b6b6422f41a1312391a5e505fc29ccd upstream.
    
    [Why]
    Framedrops are observed while playing Vp9 and Av1 10 bit
    video on 8k resolution using VSR while playback controls
    are disappeared/appeared
    
    [How]
    Now ODM 2 to 1 is disabled for 5k or greater resolutions on VSR.
    
    Cc: stable@vger.kernel.org
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Ayush Gupta <ayugupta@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Do not set DRR on pipe Commit [+ + +]
Author: Wesley Chalmers <Wesley.Chalmers@amd.com>
Date:   Thu Nov 3 22:29:31 2022 -0400

    drm/amd/display: Do not set DRR on pipe Commit
    
    commit 56574f89dbd84004c3fd6485bcaafb5aa9b8be14 upstream.
    
    [WHY]
    Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
    pipe commit can cause underflow.
    
    Cc: stable@vger.kernel.org
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Jun Lei <Jun.Lei@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Wed Jan 11 09:54:11 2023 -0700

    drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes
    
    [ Upstream commit 031f196d1b1b6d5dfcb0533b431e3ab1750e6189 ]
    
    [WHY]
    When PTEBufferSizeInRequests is zero, UBSAN reports the following
    warning because dml_log2 returns an unexpected negative value:
    
      shift exponent 4294966273 is too large for 32-bit type 'int'
    
    [HOW]
    
    In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and
    assign the result directly.
    
    Reviewed-by: Jun Lei <Jun.Lei@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: bump SMU 13.0.4 driver_if header version [+ + +]
Author: Tim Huang <tim.huang@amd.com>
Date:   Wed Mar 1 10:53:03 2023 +0800

    drm/amd/pm: bump SMU 13.0.4 driver_if header version
    
    commit ab9bdb1213b4b40942af6a383f555d0c14874c1b upstream.
    
    Align the SMU driver interface version with PMFW to
    suppress the version mismatch message on driver loading.
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/pm: Fix sienna cichlid incorrect OD volage after resume [+ + +]
Author: Błażej Szczygieł <mumei6102@gmail.com>
Date:   Sun Mar 5 00:44:31 2023 +0100

    drm/amd/pm: Fix sienna cichlid incorrect OD volage after resume
    
    commit a9386ee9681585794dbab95d4ce6826f73d19af6 upstream.
    
    Always setup overdrive tables after resume. Preserve only some
    user-defined settings in user_overdrive_table if they're set.
    
    Copy restored user_overdrive_table into od_table to get correct
    values.
    
    On cold boot, BTC was triggered and GfxVfCurve was calibrated. We
    got VfCurve settings (a). On resuming back, BTC will be triggered
    again and GfxVfCurve will be recalibrated. VfCurve settings (b)
    got may be different from those of cold boot.  So if we reuse
    those VfCurve settings (a) got on cold boot on suspend, we can
    run into discrepencies.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1897
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2276
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Błażej Szczygieł <mumei6102@gmail.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: Don't resume IOMMU after incomplete init [+ + +]
Author: Felix Kuehling <Felix.Kuehling@amd.com>
Date:   Mon Mar 13 20:03:08 2023 -0400

    drm/amdgpu: Don't resume IOMMU after incomplete init
    
    commit f3921a9a641483784448fb982b2eb738b383d9b9 upstream.
    
    Check kfd->init_complete in kgd2kfd_iommu_resume, consistent with other
    kgd2kfd calls. This should fix IOMMU errors on resume from suspend when
    KFD IOMMU initialization failed.
    
    Reported-by: Matt Fagnani <matt.fagnani@bell.net>
    Link: https://lore.kernel.org/r/4a3b225c-2ffd-e758-4de1-447375e34cad@bell.net/
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217170
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2454
    Cc: Vasant Hegde <vasant.hegde@amd.com>
    Cc: Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info>
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Tested-by: Matt Fagnani <matt.fagnani@bell.net>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini [+ + +]
Author: Horatio Zhang <Hongkun.Zhang@amd.com>
Date:   Fri Feb 24 13:55:44 2023 +0800

    drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini
    
    [ Upstream commit 23f4a2d29ba57bf88095f817de5809d427fcbe7e ]
    
    The call trace occurs when the amdgpu is removed after
    the mode1 reset. During mode1 reset, from suspend to resume,
    there is no need to reinitialize the ta firmware buffer
    which caused the bo pin_count increase redundantly.
    
    [  489.885525] Call Trace:
    [  489.885525]  <TASK>
    [  489.885526]  amdttm_bo_put+0x34/0x50 [amdttm]
    [  489.885529]  amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu]
    [  489.885620]  psp_free_shared_bufs+0xb7/0x150 [amdgpu]
    [  489.885720]  psp_hw_fini+0xce/0x170 [amdgpu]
    [  489.885815]  amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu]
    [  489.885960]  ? blocking_notifier_chain_unregister+0x56/0xb0
    [  489.885962]  amdgpu_driver_unload_kms+0x51/0x60 [amdgpu]
    [  489.886049]  amdgpu_pci_remove+0x5a/0x140 [amdgpu]
    [  489.886132]  ? __pm_runtime_resume+0x60/0x90
    [  489.886134]  pci_device_remove+0x3e/0xb0
    [  489.886135]  __device_release_driver+0x1ab/0x2a0
    [  489.886137]  driver_detach+0xf3/0x140
    [  489.886138]  bus_remove_driver+0x6c/0xf0
    [  489.886140]  driver_unregister+0x31/0x60
    [  489.886141]  pci_unregister_driver+0x40/0x90
    [  489.886142]  amdgpu_exit+0x15/0x451 [amdgpu]
    
    Signed-off-by: Horatio Zhang <Hongkun.Zhang@amd.com>
    Signed-off-by: longlyao <Longlong.Yao@amd.com>
    Reviewed-by: Guchun Chen <guchun.chen@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdkfd: Fix an illegal memory access [+ + +]
Author: Qu Huang <qu.huang@linux.dev>
Date:   Tue Feb 21 11:35:16 2023 +0000

    drm/amdkfd: Fix an illegal memory access
    
    [ Upstream commit 4fc8fff378b2f2039f2a666d9f8c570f4e58352c ]
    
    In the kfd_wait_on_events() function, the kfd_event_waiter structure is
    allocated by alloc_event_waiters(), but the event field of the waiter
    structure is not initialized; When copy_from_user() fails in the
    kfd_wait_on_events() function, it will enter exception handling to
    release the previously allocated memory of the waiter structure;
    Due to the event field of the waiters structure being accessed
    in the free_waiters() function, this results in illegal memory access
    and system crash, here is the crash log:
    
    localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0
    localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082
    localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000
    localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0
    localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64
    localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002
    localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698
    localhost kernel: FS:  0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000
    localhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0
    localhost kernel: Call Trace:
    localhost kernel: _raw_spin_lock_irqsave+0x30/0x40
    localhost kernel: remove_wait_queue+0x12/0x50
    localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu]
    localhost kernel: ? ftrace_graph_caller+0xa0/0xa0
    localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu]
    localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu]
    localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu]
    localhost kernel: ? ftrace_graph_caller+0xa0/0xa0
    localhost kernel: __x64_sys_ioctl+0x8e/0xd0
    localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0
    localhost kernel: do_syscall_64+0x33/0x80
    localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
    localhost kernel: RIP: 0033:0x152a4dff68d7
    
    Allocate the structure with kcalloc, and remove redundant 0-initialization
    and a redundant loop condition check.
    
    Signed-off-by: Qu Huang <qu.huang@linux.dev>
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: Fix returned array size name for atomic_get_input_bus_fmts kdoc [+ + +]
Author: Liu Ying <victor.liu@nxp.com>
Date:   Tue Mar 14 13:50:35 2023 +0800

    drm/bridge: Fix returned array size name for atomic_get_input_bus_fmts kdoc
    
    [ Upstream commit 0d3c9333d976af41d7dbc6bf4d9d2e95fbdf9c89 ]
    
    The returned array size for input formats is set through
    atomic_get_input_bus_fmts()'s 'num_input_fmts' argument, so use
    'num_input_fmts' to represent the array size in the function's kdoc,
    not 'num_output_fmts'.
    
    Fixes: 91ea83306bfa ("drm/bridge: Fix the bridge kernel doc")
    Fixes: f32df58acc68 ("drm/bridge: Add the necessary bits to support bus format negotiation")
    Signed-off-by: Liu Ying <victor.liu@nxp.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230314055035.3731179-1-victor.liu@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/active: Fix misuse of non-idle barriers as fence trackers [+ + +]
Author: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Date:   Thu Mar 2 13:08:20 2023 +0100

    drm/i915/active: Fix misuse of non-idle barriers as fence trackers
    
    commit e0e6b416b25ee14716f3549e0cbec1011b193809 upstream.
    
    Users reported oopses on list corruptions when using i915 perf with a
    number of concurrently running graphics applications.  Root cause analysis
    pointed at an issue in barrier processing code -- a race among perf open /
    close replacing active barriers with perf requests on kernel context and
    concurrent barrier preallocate / acquire operations performed during user
    context first pin / last unpin.
    
    When adding a request to a composite tracker, we try to reuse an existing
    fence tracker, already allocated and registered with that composite.  The
    tracker we obtain may already track another fence, may be an idle barrier,
    or an active barrier.
    
    If the tracker we get occurs a non-idle barrier then we try to delete that
    barrier from a list of barrier tasks it belongs to.  However, while doing
    that we don't respect return value from a function that performs the
    barrier deletion.  Should the deletion ever fail, we would end up reusing
    the tracker still registered as a barrier task.  Since the same structure
    field is reused with both fence callback lists and barrier tasks list,
    list corruptions would likely occur.
    
    Barriers are now deleted from a barrier tasks list by temporarily removing
    the list content, traversing that content with skip over the node to be
    deleted, then populating the list back with the modified content.  Should
    that intentionally racy concurrent deletion attempts be not serialized,
    one or more of those may fail because of the list being temporary empty.
    
    Related code that ignores the results of barrier deletion was initially
    introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
    idle-barrier from other kernel requests").  However, all users of the
    barrier deletion routine were apparently serialized at that time, then the
    issue didn't exhibit itself.  Results of git bisect with help of a newly
    developed igt@gem_barrier_race@remote-request IGT test indicate that list
    corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
    Schedule request retirement when timeline idles"), introduced in v5.5.
    
    Respect results of barrier deletion attempts -- mark the barrier as idle
    only if successfully deleted from the list.  Then, before proceeding with
    setting our fence as the one currently tracked, make sure that the tracker
    we've got is not a non-idle barrier.  If that check fails then don't use
    that tracker but go back and try to acquire a new, usable one.
    
    v3: use unlikely() to document what outcome we expect (Andi),
      - fix bad grammar in commit description.
    v2: no code changes,
      - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
        when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
        sharing the idle-barrier from other kernel requests"), v5.4,
      - reword commit description.
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
    Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles")
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@vger.kernel.org # v5.5
    Cc: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230302120820.48740-1-janusz.krzysztofik@linux.intel.com
    (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz [+ + +]
Author: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Date:   Thu Feb 23 10:06:19 2023 +0530

    drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz
    
    commit 46bc23dcd94569270d02c4c1f7e62ae01ebd53bb upstream.
    
    Add snps phy table values for HDMI pixel clocks 267.30 MHz and
    319.89 MHz. Values are based on the Bspec algorithm for
    PLL programming for HDMI.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8008
    Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
    Reviewed-by: Uma Shankar <uma.shankar@intel.com>
    Signed-off-by: Uma Shankar <uma.shankar@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230223043619.3941382-1-ankit.k.nautiyal@intel.com
    (cherry picked from commit d46746b8b13cbd377ffc733e465d25800459a31b)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/psr: Use calculated io and fast wake lines [+ + +]
Author: Jouni Högander <jouni.hogander@intel.com>
Date:   Tue Feb 21 10:53:04 2023 +0200

    drm/i915/psr: Use calculated io and fast wake lines
    
    [ Upstream commit 71c602103c74b277bef3d20a308874a33ec8326d ]
    
    Currently we are using hardcoded 7 for io and fast wake lines.
    
    According to Bspec io and fast wake times are both 42us for
    DISPLAY_VER >= 12 and 50us and 32us for older platforms.
    
    Calculate line counts for these and configure them into PSR2_CTL
    accordingly
    
    Use 45 us for the fast wake calculation as 42 seems to be too
    tight based on testing.
    
    Bspec: 49274, 4289
    
    Cc: Mika Kahola <mika.kahola@intel.com>
    Cc: José Roberto de Souza <jose.souza@intel.com>
    Fixes: 64cf40a125ff ("drm/i915/psr: Program default IO buffer Wake and Fast Wake")
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7725
    Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
    Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230221085304.3382297-1-jouni.hogander@intel.com
    (cherry picked from commit cb42e8ede5b475c096e473b86c356b1158b4bc3b)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/sseu: fix max_subslices array-index-out-of-bounds access [+ + +]
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Mon Feb 20 18:18:58 2023 +0100

    drm/i915/sseu: fix max_subslices array-index-out-of-bounds access
    
    [ Upstream commit 193c41926d152761764894f46e23b53c00186a82 ]
    
    It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
    mask internally in UAPI format") exposed a potential out-of-bounds
    access, reported by UBSAN as following on a laptop with a gen 11 i915
    card:
    
      UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27
      index 6 is out of range for type 'u16 [6]'
      CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu
      Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022
      Call Trace:
       <TASK>
       show_stack+0x4e/0x61
       dump_stack_lvl+0x4a/0x6f
       dump_stack+0x10/0x18
       ubsan_epilogue+0x9/0x3a
       __ubsan_handle_out_of_bounds.cold+0x42/0x47
       gen11_compute_sseu_info+0x121/0x130 [i915]
       intel_sseu_info_init+0x15d/0x2b0 [i915]
       intel_gt_init_mmio+0x23/0x40 [i915]
       i915_driver_mmio_probe+0x129/0x400 [i915]
       ? intel_gt_probe_all+0x91/0x2e0 [i915]
       i915_driver_probe+0xe1/0x3f0 [i915]
       ? drm_privacy_screen_get+0x16d/0x190 [drm]
       ? acpi_dev_found+0x64/0x80
       i915_pci_probe+0xac/0x1b0 [i915]
       ...
    
    According to the definition of sseu_dev_info, eu_mask->hsw is limited to
    a maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but
    gen11_sseu_info_init() can potentially set 8 sub-slices, in the
    !IS_JSL_EHL(gt->i915) case.
    
    Fix this by reserving up to 8 slots for max_subslices in the eu_mask
    struct.
    
    Reported-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Fixes: bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU mask internally in UAPI format")
    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230220171858.131416-1-andrea.righi@canonical.com
    (cherry picked from commit 3cba09a6ac86ea1d456909626eb2685596c07822)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/meson: fix 1px pink line on GXM when scaling video overlay [+ + +]
Author: Christian Hewitt <christianshewitt@gmail.com>
Date:   Fri Mar 3 12:33:12 2023 +0000

    drm/meson: fix 1px pink line on GXM when scaling video overlay
    
    [ Upstream commit 5c8cf1664f288098a971a1d1e65716a2b6a279e1 ]
    
    Playing media with a resolution smaller than the crtc size requires the
    video overlay to be scaled for output and GXM boards display a 1px pink
    line on the bottom of the scaled overlay. Comparing with the downstream
    vendor driver revealed VPP_DUMMY_DATA not being set [0].
    
    Setting VPP_DUMMY_DATA prevents the 1px pink line from being seen.
    
    [0] https://github.com/endlessm/linux-s905x/blob/master/drivers/amlogic/amports/video.c#L7869
    
    Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
    Suggested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230303123312.155164-1-christianshewitt@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/gem: Prevent blocking within shrinker loop [+ + +]
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date:   Fri Nov 4 19:04:59 2022 +0300

    drm/msm/gem: Prevent blocking within shrinker loop
    
    [ Upstream commit 9630b585b607bd26f505d34620b14d75b9a5af7d ]
    
    Consider this scenario:
    
    1. APP1 continuously creates lots of small GEMs
    2. APP2 triggers `drop_caches`
    3. Shrinker starts to evict APP1 GEMs, while APP1 produces new purgeable
       GEMs
    4. msm_gem_shrinker_scan() returns non-zero number of freed pages
       and causes shrinker to try shrink more
    5. msm_gem_shrinker_scan() returns non-zero number of freed pages again,
       goto 4
    6. The APP2 is blocked in `drop_caches` until APP1 stops producing
       purgeable GEMs
    
    To prevent this blocking scenario, check number of remaining pages
    that GPU shrinker couldn't release due to a GEM locking contention
    or shrinking rejection. If there are no remaining pages left to shrink,
    then there is no need to free up more pages and shrinker may break out
    from the loop.
    
    This problem was found during shrinker/madvise IOCTL testing of
    virtio-gpu driver. The MSM driver is affected in the same way.
    
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: b352ba54a820 ("drm/msm/gem: Convert to using drm_gem_lru")
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://lore.kernel.org/all/20230108210445.3948344-2-dmitry.osipenko@collabora.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panfrost: Don't sync rpm suspension after mmu flushing [+ + +]
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date:   Thu Nov 17 04:40:38 2022 +0300

    drm/panfrost: Don't sync rpm suspension after mmu flushing
    
    [ Upstream commit ba3be66f11c3c49afaa9f49b99e21d88756229ef ]
    
    Lockdep warns about potential circular locking dependency of devfreq
    with the fs_reclaim caused by immediate device suspension when mapping is
    released by shrinker. Fix it by doing the suspension asynchronously.
    
    Reviewed-by: Steven Price <steven.price@arm.com>
    Fixes: ec7eba47da86 ("drm/panfrost: Rework page table flushing and runtime PM interaction")
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://lore.kernel.org/all/20230108210445.3948344-3-dmitry.osipenko@collabora.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/shmem-helper: Remove another errant put in error path [+ + +]
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date:   Mon Jan 9 00:13:11 2023 +0300

    drm/shmem-helper: Remove another errant put in error path
    
    commit ee9adb7a45516cfa536ca92253d7ae59d56db9e4 upstream.
    
    drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
    in the dma-buf shmem GEM object getting prematurely freed leading to a
    later use-after-free.
    
    Fixes: f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwarding bug")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230108211311.3950107-1-dmitry.osipenko@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/sun4i: fix missing component unbind on bind errors [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 11:32:42 2023 +0100

    drm/sun4i: fix missing component unbind on bind errors
    
    commit c22f2ff8724b49dce2ae797e9fbf4bc0fa91112f upstream.
    
    Make sure to unbind all subcomponents when binding the aggregate device
    fails.
    
    Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
    Cc: stable@vger.kernel.org      # 4.7
    Cc: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230306103242.4775-1-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/ttm: Fix a NULL pointer dereference [+ + +]
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Date:   Tue Mar 7 15:46:15 2023 +0100

    drm/ttm: Fix a NULL pointer dereference
    
    commit 9a9a8fe26751334b7739193a94eba741073b8a55 upstream.
    
    The LRU mechanism may look up a resource in the process of being removed
    from an object. The locking rules here are a bit unclear but it looks
    currently like res->bo assignment is protected by the LRU lock, whereas
    bo->resource is protected by the object lock, while *clearing* of
    bo->resource is also protected by the LRU lock. This means that if
    we check that bo->resource points to the LRU resource under the LRU
    lock we should be safe.
    So perform that check before deciding to swap out a bo. That avoids
    dereferencing a NULL bo->resource in ttm_bo_swapout().
    
    Fixes: 6a9b02899402 ("drm/ttm: move the LRU into resource handling v4")
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Christian Koenig <christian.koenig@amd.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: Felix Kuehling <Felix.Kuehling@amd.com>
    Cc: Philip Yang <Philip.Yang@amd.com>
    Cc: Qiang Yu <qiang.yu@amd.com>
    Cc: Matthew Auld <matthew.auld@intel.com>
    Cc: Nirmoy Das <nirmoy.das@intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
    Cc: Anshuman Gupta <anshuman.gupta@intel.com>
    Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v5.19+
    Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230307144621.10748-2-thomas.hellstrom@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/virtio: Pass correct device to dma_sync_sgtable_for_device() [+ + +]
Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date:   Fri Feb 24 17:34:50 2023 +0200

    drm/virtio: Pass correct device to dma_sync_sgtable_for_device()
    
    [ Upstream commit a54bace095d00e9222161495649688bc43de4dde ]
    
    The "vdev->dev.parent" should be used instead of "vdev->dev" as a device
    for which to perform the DMA operation in both
    virtio_gpu_cmd_transfer_to_host_2d(3d).
    
    Because the virtio-gpu device "vdev->dev" doesn't really have DMA OPS
    assigned to it, but parent (virtio-pci or virtio-mmio) device
    "vdev->dev.parent" has. The more, the sgtable in question the code is
    trying to sync here was mapped for the parent device (by using its DMA OPS)
    previously at:
    virtio_gpu_object_shmem_init()->drm_gem_shmem_get_pages_sgt()->
    dma_map_sgtable(), so should be synced here for the same parent device.
    
    Fixes: b5c9ed70d1a9 ("drm/virtio: Improve DMA API usage for shmem BOs")
    Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230224153450.526222-1-olekstysh@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ethernet: sun: add check for the mdesc_grab() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Wed Mar 15 14:00:21 2023 +0800

    ethernet: sun: add check for the mdesc_grab()
    
    [ Upstream commit 90de546d9a0b3c771667af18bb3f80567eabb89b ]
    
    In vnet_port_probe() and vsw_port_probe(), we should
    check the return value of mdesc_grab() as it may
    return NULL which can caused NPD bugs.
    
    Fixes: 5d01fa0c6bd8 ("ldmvsw: Add ldmvsw.c driver code")
    Fixes: 43fdf27470b2 ("[SPARC64]: Abstract out mdesc accesses for better MD update handling.")
    Signed-off-by: Liang He <windhl@126.com>
    Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: fail ext4_iget if special inode unallocated [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Sat Jan 7 11:21:25 2023 +0800

    ext4: fail ext4_iget if special inode unallocated
    
    [ Upstream commit 5cd740287ae5e3f9d1c46f5bfe8778972fd6d3fe ]
    
    In ext4_fill_super(), EXT4_ORPHAN_FS flag is cleared after
    ext4_orphan_cleanup() is executed. Therefore, when __ext4_iget() is
    called to get an inode whose i_nlink is 0 when the flag exists, no error
    is returned. If the inode is a special inode, a null pointer dereference
    may occur. If the value of i_nlink is 0 for any inodes (except boot loader
    inodes) got by using the EXT4_IGET_SPECIAL flag, the current file system
    is corrupted. Therefore, make the ext4_iget() function return an error if
    it gets such an abnormal special inode.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199179
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216541
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216539
    Reported-by: Luís Henriques <lhenriques@suse.de>
    Suggested-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230107032126.4165860-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix possible double unlock when moving a directory [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Mar 17 21:53:52 2023 -0400

    ext4: fix possible double unlock when moving a directory
    
    commit 70e42feab2e20618ddd0cbfc4ab4b08628236ecd upstream.
    
    Fixes: 0813299c586b ("ext4: Fix possible corruption when moving a directory")
    Link: https://lore.kernel.org/r/5efbe1b9-ad8b-4a4f-b422-24824d2b775c@kili.mountain
    Reported-by: Dan Carpenter <error27@gmail.com>
    Reported-by: syzbot+0c73d1d8b952c5f3d714@syzkaller.appspotmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix task hung in ext4_xattr_delete_inode [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Tue Jan 10 21:34:36 2023 +0800

    ext4: fix task hung in ext4_xattr_delete_inode
    
    [ Upstream commit 0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7 ]
    
    Syzbot reported a hung task problem:
    ==================================================================
    INFO: task syz-executor232:5073 blocked for more than 143 seconds.
          Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004
    Call Trace:
     <TASK>
     context_switch kernel/sched/core.c:5244 [inline]
     __schedule+0x995/0xe20 kernel/sched/core.c:6555
     schedule+0xcb/0x190 kernel/sched/core.c:6631
     __wait_on_freeing_inode fs/inode.c:2196 [inline]
     find_inode_fast+0x35a/0x4c0 fs/inode.c:950
     iget_locked+0xb1/0x830 fs/inode.c:1273
     __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861
     ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389
     ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148
     ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880
     ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296
     evict+0x2a4/0x620 fs/inode.c:664
     ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
     __ext4_fill_super fs/ext4/super.c:5516 [inline]
     ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
     get_tree_bdev+0x400/0x620 fs/super.c:1282
     vfs_get_tree+0x88/0x270 fs/super.c:1489
     do_new_mount+0x289/0xad0 fs/namespace.c:3145
     do_mount fs/namespace.c:3488 [inline]
     __do_sys_mount fs/namespace.c:3697 [inline]
     __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fa5406fd5ea
    RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea
    RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970
    RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432
    R10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004
    R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000
     </TASK>
    ==================================================================
    
    The problem is that the inode contains an xattr entry with ea_inum of 15
    when cleaning up an orphan inode <15>. When evict inode <15>, the reference
    counting of the corresponding EA inode is decreased. When EA inode <15> is
    found by find_inode_fast() in __ext4_iget(), it is found that the EA inode
    holds the I_FREEING flag and waits for the EA inode to complete deletion.
    As a result, when inode <15> is being deleted, we wait for inode <15> to
    complete the deletion, resulting in an infinite loop and triggering Hung
    Task. To solve this problem, we only need to check whether the ino of EA
    inode and parent is the same before getting EA inode.
    
    Link: https://syzkaller.appspot.com/bug?extid=77d6fcc37bbb92f26048
    Reported-by: syzbot+77d6fcc37bbb92f26048@syzkaller.appspotmail.com
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230110133436.996350-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: update s_journal_inum if it changes after journal replay [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Sat Jan 7 11:21:26 2023 +0800

    ext4: update s_journal_inum if it changes after journal replay
    
    [ Upstream commit 3039d8b8692408438a618fac2776b629852663c3 ]
    
    When mounting a crafted ext4 image, s_journal_inum may change after journal
    replay, which is obviously unreasonable because we have successfully loaded
    and replayed the journal through the old s_journal_inum. And the new
    s_journal_inum bypasses some of the checks in ext4_get_journal(), which
    may trigger a null pointer dereference problem. So if s_journal_inum
    changes after the journal replay, we ignore the change, and rewrite the
    current journal_inum to the superblock.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216541
    Reported-by: Luís Henriques <lhenriques@suse.de>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230107032126.4165860-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: chipsfb: Fix error codes in chipsfb_pci_init() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Mon Feb 27 13:33:30 2023 +0300

    fbdev: chipsfb: Fix error codes in chipsfb_pci_init()
    
    [ Upstream commit 77bc762451c2dc72bdbea07b857c916c9e7f4952 ]
    
    The error codes are not set on these error paths.
    
    Fixes: 145eed48de27 ("fbdev: Remove conflicting devices on PCI bus")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/Y/yG+sm2mhdJeTZW@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release() [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Mar 8 11:50:12 2023 +0100

    fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release()
    
    commit fe9ae05cfbe587dda724fcf537c00bc2f287da62 upstream.
    
    The recent fix for the deferred I/O by the commit
      3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
    caused a regression when the same fb device is opened/closed while
    it's being used.  It resulted in a frozen screen even if something
    is redrawn there after the close.  The breakage is because the patch
    was made under a wrong assumption of a single open; in the current
    code, fb_deferred_io_release() cleans up the page mapping of the
    pageref list and it calls cancel_delayed_work_sync() unconditionally,
    where both are no correct behavior for multiple opens.
    
    This patch adds a refcount for the opens of the device, and applies
    the cleanup only when all files get closed.
    
    As both fb_deferred_io_open() and _close() are called always in the
    fb_info lock (mutex), it's safe to use the normal int for the
    refcounting.
    
    Also, a useless BUG_ON() is dropped.
    
    Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230308105012.1845-1-tiwai@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fbdev: stifb: Provide valid pixelclock and add fb_check_var() checks [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Thu Mar 16 11:38:19 2023 +0100

    fbdev: stifb: Provide valid pixelclock and add fb_check_var() checks
    
    commit 203873a535d627c668f293be0cb73e26c30f9cc7 upstream.
    
    Find a valid modeline depending on the machine graphic card
    configuration and add the fb_check_var() function to validate
    Xorg provided graphics settings.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: xilinx: don't make a sleepable memory allocation from an atomic context [+ + +]
Author: Roman Gushchin <roman.gushchin@linux.dev>
Date:   Wed Mar 8 14:26:02 2023 -0800

    firmware: xilinx: don't make a sleepable memory allocation from an atomic context
    
    commit 38ed310c22e7a0fc978b1f8292136a4a4a8b3051 upstream.
    
    The following issue was discovered using lockdep:
    [    6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209
    [    6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0
    [    6.702431] 2 locks held by swapper/0/1:
    [    6.706300]  #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90
    [    6.714900]  #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140
    [    6.723156] irq event stamp: 304030
    [    6.726596] hardirqs last  enabled at (304029): [<ffffffc008d17ee0>] _raw_spin_unlock_irqrestore+0xc0/0xd0
    [    6.736142] hardirqs last disabled at (304030): [<ffffffc00876bc5c>] clk_enable_lock+0xfc/0x140
    [    6.744742] softirqs last  enabled at (303958): [<ffffffc0080904f0>] _stext+0x4f0/0x894
    [    6.752655] softirqs last disabled at (303951): [<ffffffc0080e53b8>] irq_exit+0x238/0x280
    [    6.760744] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G     U            5.15.36 #2
    [    6.768048] Hardware name: xlnx,zynqmp (DT)
    [    6.772179] Call trace:
    [    6.774584]  dump_backtrace+0x0/0x300
    [    6.778197]  show_stack+0x18/0x30
    [    6.781465]  dump_stack_lvl+0xb8/0xec
    [    6.785077]  dump_stack+0x1c/0x38
    [    6.788345]  ___might_sleep+0x1a8/0x2a0
    [    6.792129]  __might_sleep+0x6c/0xd0
    [    6.795655]  kmem_cache_alloc_trace+0x270/0x3d0
    [    6.800127]  do_feature_check_call+0x100/0x220
    [    6.804513]  zynqmp_pm_invoke_fn+0x8c/0xb0
    [    6.808555]  zynqmp_pm_clock_getstate+0x90/0xe0
    [    6.813027]  zynqmp_pll_is_enabled+0x8c/0x120
    [    6.817327]  zynqmp_pll_enable+0x38/0xc0
    [    6.821197]  clk_core_enable+0x144/0x400
    [    6.825067]  clk_core_enable+0xd4/0x400
    [    6.828851]  clk_core_enable+0xd4/0x400
    [    6.832635]  clk_core_enable+0xd4/0x400
    [    6.836419]  clk_core_enable+0xd4/0x400
    [    6.840203]  clk_core_enable+0xd4/0x400
    [    6.843987]  clk_core_enable+0xd4/0x400
    [    6.847771]  clk_core_enable+0xd4/0x400
    [    6.851555]  clk_core_enable_lock+0x24/0x50
    [    6.855683]  clk_enable+0x24/0x40
    [    6.858952]  fclk_probe+0x84/0xf0
    [    6.862220]  platform_probe+0x8c/0x110
    [    6.865918]  really_probe+0x110/0x5f0
    [    6.869530]  __driver_probe_device+0xcc/0x210
    [    6.873830]  driver_probe_device+0x64/0x140
    [    6.877958]  __driver_attach+0x114/0x1f0
    [    6.881828]  bus_for_each_dev+0xe8/0x160
    [    6.885698]  driver_attach+0x34/0x50
    [    6.889224]  bus_add_driver+0x228/0x300
    [    6.893008]  driver_register+0xc0/0x1e0
    [    6.896792]  __platform_driver_register+0x44/0x60
    [    6.901436]  fclk_driver_init+0x1c/0x28
    [    6.905220]  do_one_initcall+0x104/0x590
    [    6.909091]  kernel_init_freeable+0x254/0x2bc
    [    6.913390]  kernel_init+0x24/0x130
    [    6.916831]  ret_from_fork+0x10/0x20
    
    Fix it by passing the GFP_ATOMIC gfp flag for the corresponding
    memory allocation.
    
    Fixes: acfdd18591ea ("firmware: xilinx: Use hash-table for api feature check")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
    Cc: Amit Sunil Dhamne <amit.sunil.dhamne@xilinx.com>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Link: https://lore.kernel.org/r/20230308222602.123866-1-roman.gushchin@linux.dev
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ftrace,kcfi: Define ftrace_stub_graph conditionally [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 31 10:36:30 2023 +0100

    ftrace,kcfi: Define ftrace_stub_graph conditionally
    
    [ Upstream commit aa69f814920d85a2d4cfd5c294757c3d59d2fba6 ]
    
    When CONFIG_FUNCTION_GRAPH_TRACER is disabled, __kcfi_typeid_ftrace_stub_graph
    is missing, causing a link failure:
    
     ld.lld: error: undefined symbol: __kcfi_typeid_ftrace_stub_graph
     referenced by arch/x86/kernel/ftrace_64.o:(__cfi_ftrace_stub_graph) in archive vmlinux.a
    
    Mark the reference to it as conditional on the same symbol, as
    is done on arm64.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230131093643.3850272-1-arnd@kernel.org
    
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@kernel.org>
    Fixes: 883bbbffa5a4 ("ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()")
    See-also: 2598ac6ec493 ("arm64: ftrace: Define ftrace_stub_graph only with FUNCTION_GRAPH_TRACER")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ftrace: Fix invalid address access in lookup_rec() when index is 0 [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Thu Mar 9 16:02:30 2023 +0800

    ftrace: Fix invalid address access in lookup_rec() when index is 0
    
    commit ee92fa443358f4fc0017c1d0d325c27b37802504 upstream.
    
    KASAN reported follow problem:
    
     BUG: KASAN: use-after-free in lookup_rec
     Read of size 8 at addr ffff000199270ff0 by task modprobe
     CPU: 2 Comm: modprobe
     Call trace:
      kasan_report
      __asan_load8
      lookup_rec
      ftrace_location
      arch_check_ftrace_location
      check_kprobe_address_safe
      register_kprobe
    
    When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a
    pg which is newly added to ftrace_pages_start in ftrace_process_locs().
    Before the first pg->index++, index is 0 and accessing pg->records[-1].ip
    will cause this problem.
    
    Don't check the ip when pg->index is 0.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230309080230.36064-1-chenzhongjin@huawei.com
    
    Cc: stable@vger.kernel.org
    Fixes: 9644302e3315 ("ftrace: Speed up search by skipping pages by address")
    Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hwmon: (adm1266) Set `can_sleep` flag for GPIO chip [+ + +]
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Mar 14 02:31:45 2023 -0700

    hwmon: (adm1266) Set `can_sleep` flag for GPIO chip
    
    [ Upstream commit a5bb73b3f5db1a4e91402ad132b59b13d2651ed9 ]
    
    The adm1266 driver uses I2C bus access in its GPIO chip `set` and `get`
    implementation. This means these functions can sleep and the GPIO chip
    should set the `can_sleep` property to true.
    
    This will ensure that a warning is printed when trying to set or get the
    GPIO value from a context that potentially can't sleep.
    
    Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Link: https://lore.kernel.org/r/20230314093146.2443845-1-lars@metafoo.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (adt7475) Display smoothing attributes in correct order [+ + +]
Author: Tony O'Brien <tony.obrien@alliedtelesis.co.nz>
Date:   Wed Feb 22 13:52:27 2023 +1300

    hwmon: (adt7475) Display smoothing attributes in correct order
    
    [ Upstream commit 5f8d1e3b6f9b5971f9c06d5846ce00c49e3a8d94 ]
    
    Throughout the ADT7475 driver, attributes relating to the temperature
    sensors are displayed in the order Remote 1, Local, Remote 2.  Make
    temp_st_show() conform to this expectation so that values set by
    temp_st_store() can be displayed using the correct attribute.
    
    Fixes: 8f05bcc33e74 ("hwmon: (adt7475) temperature smoothing")
    Signed-off-by: Tony O'Brien <tony.obrien@alliedtelesis.co.nz>
    Link: https://lore.kernel.org/r/20230222005228.158661-2-tony.obrien@alliedtelesis.co.nz
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (adt7475) Fix masking of hysteresis registers [+ + +]
Author: Tony O'Brien <tony.obrien@alliedtelesis.co.nz>
Date:   Wed Feb 22 13:52:28 2023 +1300

    hwmon: (adt7475) Fix masking of hysteresis registers
    
    [ Upstream commit 48e8186870d9d0902e712d601ccb7098cb220688 ]
    
    The wrong bits are masked in the hysteresis register; indices 0 and 2
    should zero bits [7:4] and preserve bits [3:0], and index 1 should zero
    bits [3:0] and preserve bits [7:4].
    
    Fixes: 1c301fc5394f ("hwmon: Add a driver for the ADT7475 hardware monitoring chip")
    Signed-off-by: Tony O'Brien <tony.obrien@alliedtelesis.co.nz>
    Link: https://lore.kernel.org/r/20230222005228.158661-3-tony.obrien@alliedtelesis.co.nz
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (ina3221) return prober error code [+ + +]
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Fri Mar 10 08:50:35 2023 +0100

    hwmon: (ina3221) return prober error code
    
    [ Upstream commit c93f5e2ab53243b17febabb9422a697017d3d49a ]
    
    ret is set to 0 which do not indicate an error.
    Return -EINVAL instead.
    
    Fixes: a9e9dd9c6de5 ("hwmon: (ina3221) Read channel input source info from DT")
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Link: https://lore.kernel.org/r/20230310075035.246083-1-marcus.folkesson@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (ltc2992) Set `can_sleep` flag for GPIO chip [+ + +]
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Mar 14 02:31:46 2023 -0700

    hwmon: (ltc2992) Set `can_sleep` flag for GPIO chip
    
    [ Upstream commit ab00709310eedcd8dae0df1f66d332f9bc64c99e ]
    
    The ltc2992 drivers uses a mutex and I2C bus access in its GPIO chip `set`
    and `get` implementation. This means these functions can sleep and the GPIO
    chip should set the `can_sleep` property to true.
    
    This will ensure that a warning is printed when trying to set or get the
    GPIO value from a context that potentially can't sleep.
    
    Fixes: 9ca26df1ba25 ("hwmon: (ltc2992) Add support for GPIOs.")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Link: https://lore.kernel.org/r/20230314093146.2443845-2-lars@metafoo.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (ucd90320) Add minimum delay between bus accesses [+ + +]
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Sun Mar 12 09:03:12 2023 -0700

    hwmon: (ucd90320) Add minimum delay between bus accesses
    
    [ Upstream commit 8d655e65237643c48ada2c131b83679bf1105373 ]
    
    When probing the ucd90320 access to some of the registers randomly fails.
    Sometimes it NACKs a transfer, sometimes it returns just random data and
    the PEC check fails.
    
    Experimentation shows that this seems to be triggered by a register access
    directly back to back with a previous register write. Experimentation also
    shows that inserting a small delay after register writes makes the issue go
    away.
    
    Use a similar solution to what the max15301 driver does to solve the same
    problem. Create a custom set of bus read and write functions that make sure
    that the delay is added.
    
    Fixes: a470f11c5ba2 ("hwmon: (pmbus/ucd9000) Add support for UCD90320 Power Sequencer")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Link: https://lore.kernel.org/r/20230312160312.2227405-1-lars@metafoo.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (xgene) Fix use after free bug in xgene_hwmon_remove due to race condition [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Fri Mar 10 16:40:07 2023 +0800

    hwmon: (xgene) Fix use after free bug in xgene_hwmon_remove due to race condition
    
    [ Upstream commit cb090e64cf25602b9adaf32d5dfc9c8bec493cd1 ]
    
    In xgene_hwmon_probe, &ctx->workq is bound with xgene_hwmon_evt_work.
    Then it will be started.
    
    If we remove the driver which will call xgene_hwmon_remove to clean up,
    there may be unfinished work.
    
    The possible sequence is as follows:
    
    Fix it by finishing the work before cleanup in xgene_hwmon_remove.
    
    CPU0                  CPU1
    
                        |xgene_hwmon_evt_work
    xgene_hwmon_remove   |
    kfifo_free(&ctx->async_msg_fifo);|
                        |
                        |kfifo_out_spinlocked
                        |//use &ctx->async_msg_fifo
    Fixes: 2ca492e22cb7 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Link: https://lore.kernel.org/r/20230310084007.1403388-1-zyytlz.wz@163.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: tmp512: drop of_match_ptr for ID table [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Mar 12 20:37:23 2023 +0100

    hwmon: tmp512: drop of_match_ptr for ID table
    
    [ Upstream commit 00d85e81796b17a29a0e096c5a4735daa47adef8 ]
    
    The driver will match mostly by DT table (even thought there is regular
    ID table) so there is little benefit in of_match_ptr (this also allows
    ACPI matching via PRP0001, even though it might not be relevant here).
    This also fixes !CONFIG_OF error:
    
      drivers/hwmon/tmp513.c:610:34: error: ‘tmp51x_of_match’ defined but not used [-Werror=unused-const-variable=]
    
    Fixes: 59dfa75e5d82 ("hwmon: Add driver for Texas Instruments TMP512/513 sensor chips.")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230312193723.478032-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Fix kernel crash during reboot when adapter is in recovery mode [+ + +]
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Thu Mar 9 10:45:09 2023 -0800

    i40e: Fix kernel crash during reboot when adapter is in recovery mode
    
    [ Upstream commit 7e4f8a0c495413a50413e8c9f1032ce1bc633bae ]
    
    If the driver detects during probe that firmware is in recovery
    mode then i40e_init_recovery_mode() is called and the rest of
    probe function is skipped including pci_set_drvdata(). Subsequent
    i40e_shutdown() called during shutdown/reboot dereferences NULL
    pointer as pci_get_drvdata() returns NULL.
    
    To fix call pci_set_drvdata() also during entering to recovery mode.
    
    Reproducer:
    1) Lets have i40e NIC with firmware in recovery mode
    2) Run reboot
    
    Result:
    [  139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver
    [  139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
    [  139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.
    [  139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
    [  139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
    [  139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0
    [  139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.
    [  139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
    [  139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
    [  139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0
    ...
    [  156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2
    [  156.318330] #PF: supervisor write access in kernel mode
    [  156.323546] #PF: error_code(0x0002) - not-present page
    [  156.328679] PGD 0 P4D 0
    [  156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI
    [  156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G            E      6.2.0+ #1
    [  156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022
    [  156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]
    [  156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 <f0> 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00
    [  156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282
    [  156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001
    [  156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000
    [  156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40
    [  156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000
    [  156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000
    [  156.418007] FS:  00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000
    [  156.426083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0
    [  156.438944] PKRU: 55555554
    [  156.441647] Call Trace:
    [  156.444096]  <TASK>
    [  156.446199]  pci_device_shutdown+0x38/0x60
    [  156.450297]  device_shutdown+0x163/0x210
    [  156.454215]  kernel_restart+0x12/0x70
    [  156.457872]  __do_sys_reboot+0x1ab/0x230
    [  156.461789]  ? vfs_writev+0xa6/0x1a0
    [  156.465362]  ? __pfx_file_free_rcu+0x10/0x10
    [  156.469635]  ? __call_rcu_common.constprop.85+0x109/0x5a0
    [  156.475034]  do_syscall_64+0x3e/0x90
    [  156.478611]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
    [  156.483658] RIP: 0033:0x7fe7bff37ab7
    
    Fixes: 4ff0ee1af016 ("i40e: Introduce recovery mode support")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20230309184509.984639-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i825xx: sni_82596: use eth_hw_addr_set() [+ + +]
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Wed Mar 15 14:41:17 2023 +0100

    i825xx: sni_82596: use eth_hw_addr_set()
    
    [ Upstream commit f38373345c65529639a01fba3675eb8cb4c579c3 ]
    
    netdev->dev_addr is now const, we can't write to it directly.
    Copy scrambled mac address octects into an array then eth_hw_addr_set().
    
    Fixes: adeef3e32146 ("net: constify netdev->dev_addr")
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Link: https://lore.kernel.org/r/20230315134117.79511-1-tsbogend@alpha.franken.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: avoid bonding causing auxiliary plug/unplug under RTNL lock [+ + +]
Author: Dave Ertman <david.m.ertman@intel.com>
Date:   Fri Mar 10 11:48:33 2023 -0800

    ice: avoid bonding causing auxiliary plug/unplug under RTNL lock
    
    commit 248401cb2c4612d83eb0c352ee8103b78b8eb365 upstream.
    
    RDMA is not supported in ice on a PF that has been added to a bonded
    interface. To enforce this, when an interface enters a bond, we unplug
    the auxiliary device that supports RDMA functionality.  This unplug
    currently happens in the context of handling the netdev bonding event.
    This event is sent to the ice driver under RTNL context.  This is causing
    a deadlock where the RDMA driver is waiting for the RTNL lock to complete
    the removal.
    
    Defer the unplugging/re-plugging of the auxiliary device to the service
    task so that it is not performed under the RTNL lock context.
    
    Cc: stable@vger.kernel.org # 6.1.x
    Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
    Link: https://lore.kernel.org/netdev/CAK8fFZ6A_Gphw_3-QMGKEFQk=sfCw1Qmq0TVZK3rtAi7vb621A@mail.gmail.com/
    Fixes: 5cb1ebdbc434 ("ice: Fix race condition during interface enslave")
    Fixes: 4eace75e0853 ("RDMA/irdma: Report the correct link speed")
    Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
    Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20230310194833.3074601-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ice: xsk: disable txq irq before flushing hw [+ + +]
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Tue Mar 14 10:45:43 2023 -0700

    ice: xsk: disable txq irq before flushing hw
    
    [ Upstream commit b830c9642386867863ac64295185f896ff2928ac ]
    
    ice_qp_dis() intends to stop a given queue pair that is a target of xsk
    pool attach/detach. One of the steps is to disable interrupts on these
    queues. It currently is broken in a way that txq irq is turned off
    *after* HW flush which in turn takes no effect.
    
    ice_qp_dis():
    -> ice_qvec_dis_irq()
    --> disable rxq irq
    --> flush hw
    -> ice_vsi_stop_tx_ring()
    -->disable txq irq
    
    Below splat can be triggered by following steps:
    - start xdpsock WITHOUT loading xdp prog
    - run xdp_rxq_info with XDP_TX action on this interface
    - start traffic
    - terminate xdpsock
    
    [  256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018
    [  256.319560] #PF: supervisor read access in kernel mode
    [  256.324775] #PF: error_code(0x0000) - not-present page
    [  256.329994] PGD 0 P4D 0
    [  256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [  256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G           OE      6.2.0-rc5+ #51
    [  256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
    [  256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice]
    [  256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44
    [  256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206
    [  256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f
    [  256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80
    [  256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000
    [  256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000
    [  256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600
    [  256.421990] FS:  0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000
    [  256.430207] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0
    [  256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  256.457770] PKRU: 55555554
    [  256.460529] Call Trace:
    [  256.463015]  <TASK>
    [  256.465157]  ? ice_xmit_zc+0x6e/0x150 [ice]
    [  256.469437]  ice_napi_poll+0x46d/0x680 [ice]
    [  256.473815]  ? _raw_spin_unlock_irqrestore+0x1b/0x40
    [  256.478863]  __napi_poll+0x29/0x160
    [  256.482409]  net_rx_action+0x136/0x260
    [  256.486222]  __do_softirq+0xe8/0x2e5
    [  256.489853]  ? smpboot_thread_fn+0x2c/0x270
    [  256.494108]  run_ksoftirqd+0x2a/0x50
    [  256.497747]  smpboot_thread_fn+0x1c1/0x270
    [  256.501907]  ? __pfx_smpboot_thread_fn+0x10/0x10
    [  256.506594]  kthread+0xea/0x120
    [  256.509785]  ? __pfx_kthread+0x10/0x10
    [  256.513597]  ret_from_fork+0x29/0x50
    [  256.517238]  </TASK>
    
    In fact, irqs were not disabled and napi managed to be scheduled and run
    while xsk_pool pointer was still valid, but SW ring of xdp_buff pointers
    was already freed.
    
    To fix this, call ice_qvec_dis_irq() after ice_vsi_stop_tx_ring(). Also
    while at it, remove redundant ice_clean_rx_ring() call - this is handled
    in ice_qp_clean_rings().
    
    Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
interconnect: exynos: fix node leak in probe PM QoS error path [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:42 2023 +0100

    interconnect: exynos: fix node leak in probe PM QoS error path
    
    commit 3aab264875bf3c915ea2517fae1eec213e0b4987 upstream.
    
    Make sure to add the newly allocated interconnect node to the provider
    before adding the PM QoS request so that the node is freed on errors.
    
    Fixes: 2f95b9d5cf0b ("interconnect: Add generic interconnect driver for Exynos SoCs")
    Cc: stable@vger.kernel.org      # 5.11
    Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-15-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: exynos: fix registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:43 2023 +0100

    interconnect: exynos: fix registration race
    
    commit c9e46ca612cfbb0cf890f7ae7389b742e90efe64 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to trigger a NULL-pointer
    deference when either a NULL pointer or not fully initialised node is
    returned from exynos_generic_icc_xlate().
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 2f95b9d5cf0b ("interconnect: Add generic interconnect driver for Exynos SoCs")
    Cc: stable@vger.kernel.org      # 5.11
    Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-16-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: fix icc_provider_del() error handling [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:30 2023 +0100

    interconnect: fix icc_provider_del() error handling
    
    commit e0e7089bf9a87bc5e3997422e4e24563424f9018 upstream.
    
    The interconnect framework currently expects that providers are only
    removed when there are no users and after all nodes have been removed.
    
    There is currently nothing that guarantees this to be the case and the
    framework does not do any reference counting, but refusing to remove the
    provider is never correct as that would leave a dangling pointer to a
    resource that is about to be released in the global provider list (e.g.
    accessible through debugfs).
    
    Replace the current sanity checks with WARN_ON() so that the provider is
    always removed.
    
    Fixes: 11f1ceca7031 ("interconnect: Add generic on-chip interconnect API")
    Cc: stable@vger.kernel.org      # 5.1: 680f8666baf6: interconnect: Make icc_provider_del() return void
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board
    Link: https://lore.kernel.org/r/20230306075651.2449-3-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: fix mem leak when freeing nodes [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:29 2023 +0100

    interconnect: fix mem leak when freeing nodes
    
    commit a5904f415e1af72fa8fe6665aa4f554dc2099a95 upstream.
    
    The node link array is allocated when adding links to a node but is not
    deallocated when nodes are destroyed.
    
    Fixes: 11f1ceca7031 ("interconnect: Add generic on-chip interconnect API")
    Cc: stable@vger.kernel.org      # 5.1
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board
    Link: https://lore.kernel.org/r/20230306075651.2449-2-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: fix provider registration API [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:31 2023 +0100

    interconnect: fix provider registration API
    
    commit eb59eca0d8ac15f8c1b7f1cd35999455a90292c0 upstream.
    
    The current interconnect provider interface is inherently racy as
    providers are expected to be added before being fully initialised.
    
    Specifically, nodes are currently not added and the provider data is not
    initialised until after registering the provider which can cause racing
    DT lookups to fail.
    
    Add a new provider API which will be used to fix up the interconnect
    drivers.
    
    The old API is reimplemented using the new interface and will be removed
    once all drivers have been fixed.
    
    Fixes: 11f1ceca7031 ("interconnect: Add generic on-chip interconnect API")
    Fixes: 87e3031b6fbd ("interconnect: Allow endpoints translation via DT")
    Cc: stable@vger.kernel.org      # 5.1
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board
    Link: https://lore.kernel.org/r/20230306075651.2449-4-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: imx: fix registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:32 2023 +0100

    interconnect: imx: fix registration race
    
    commit 9fbd35520f1f7f3cbe1873939a27ad9b009f21f9 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
    Cc: stable@vger.kernel.org      # 5.8
    Cc: Alexandre Bailon <abailon@baylibre.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # i.MX8MP MSC SM2-MB-EP1 Board
    Link: https://lore.kernel.org/r/20230306075651.2449-5-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: qcom: msm8974: fix registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:39 2023 +0100

    interconnect: qcom: msm8974: fix registration race
    
    commit bfe7bcd2b9f5215de2144f097f39971180e7ea54 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 4e60a9568dc6 ("interconnect: qcom: add msm8974 driver")
    Cc: stable@vger.kernel.org      # 5.5
    Reviewed-by: Brian Masney <bmasney@redhat.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-12-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: qcom: osm-l3: fix registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:33 2023 +0100

    interconnect: qcom: osm-l3: fix registration race
    
    commit 174941ed28a3573db075da46d95b4dcf9d4c49c2 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail:
    
            of_icc_xlate_onecell: invalid index 0
            cpu cpu0: error -EINVAL: error finding src node
            cpu cpu0: dev_pm_opp_of_find_icc_paths: Unable to get path0: -22
            qcom-cpufreq-hw: probe of 18591000.cpufreq failed with error -22
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support")
    Cc: stable@vger.kernel.org      # 5.7
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-6-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: qcom: rpm: fix probe child-node error handling [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:34 2023 +0100

    interconnect: qcom: rpm: fix probe child-node error handling
    
    commit bc463201f60803fa6bf2741d59441031cd0910e4 upstream.
    
    Make sure to clean up and release resources properly also in case probe
    fails when populating child devices.
    
    Fixes: e39bf2972c6e ("interconnect: icc-rpm: Support child NoC device probe")
    Cc: stable@vger.kernel.org      # 5.17
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-7-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: qcom: rpm: fix registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:36 2023 +0100

    interconnect: qcom: rpm: fix registration race
    
    commit 90ae93d8affc1061cd87ca8ddd9a838c7d31a158 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 62feb14ee8a3 ("interconnect: qcom: Consolidate interconnect RPM support")
    Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver")
    Cc: stable@vger.kernel.org      # 5.7
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Jun Nie <jun.nie@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-9-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: qcom: rpmh: fix probe child-node error handling [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:37 2023 +0100

    interconnect: qcom: rpmh: fix probe child-node error handling
    
    commit 6570d1d46eeade82965ccc4a3ab7d778898ef4bf upstream.
    
    Make sure to clean up and release resources properly also in case probe
    fails when populating child devices.
    
    Fixes: 57eb14779dfd ("interconnect: qcom: icc-rpmh: Support child NoC device probe")
    Cc: stable@vger.kernel.org      # 6.0
    Cc: Luca Weiss <luca.weiss@fairphone.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-10-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

interconnect: qcom: rpmh: fix registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:38 2023 +0100

    interconnect: qcom: rpmh: fix registration race
    
    commit 74240a5bebd48d8b843c6d0f1acfaa722a5abeb7 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 976daac4a1c5 ("interconnect: qcom: Consolidate interconnect RPMh support")
    Cc: stable@vger.kernel.org      # 5.7
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-11-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/msg_ring: let target know allocated index [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Mar 20 07:05:02 2023 -0600

    io_uring/msg_ring: let target know allocated index
    
    commit 5da28edd7bd5518f97175ecea77615bb729a7a28 upstream.
    
    msg_ring requests transferring files support auto index selection via
    IORING_FILE_INDEX_ALLOC, however they don't return the selected index
    to the target ring and there is no other good way for the userspace to
    know where is the receieved file.
    
    Return the index for allocated slots and 0 otherwise, which is
    consistent with other fixed file installing requests.
    
    Cc: stable@vger.kernel.org # v6.0+
    Fixes: e6130eba8a848 ("io_uring: add support for passing fixed file descriptors")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://github.com/axboe/liburing/issues/809
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ipv4: Fix incorrect table ID in IOCTL path [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Mar 15 14:40:09 2023 +0200

    ipv4: Fix incorrect table ID in IOCTL path
    
    [ Upstream commit 8a2618e14f81604a9b6ad305d57e0c8da939cd65 ]
    
    Commit f96a3d74554d ("ipv4: Fix incorrect route flushing when source
    address is deleted") started to take the table ID field in the FIB info
    structure into account when determining if two structures are identical
    or not. This field is initialized using the 'fc_table' field in the
    route configuration structure, which is not set when adding a route via
    IOCTL.
    
    The above can result in user space being able to install two identical
    routes that only differ in the table ID field of their associated FIB
    info.
    
    Fix by initializing the table ID field in the route configuration
    structure in the IOCTL path.
    
    Before the fix:
    
     # ip route add default via 192.0.2.2
     # route add default gw 192.0.2.2
     # ip -4 r show default
     # default via 192.0.2.2 dev dummy10
     # default via 192.0.2.2 dev dummy10
    
    After the fix:
    
     # ip route add default via 192.0.2.2
     # route add default gw 192.0.2.2
     SIOCADDRT: File exists
     # ip -4 r show default
     default via 192.0.2.2 dev dummy10
    
    Audited the code paths to ensure there are no other paths that do not
    properly initialize the route configuration structure when installing a
    route.
    
    Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs")
    Fixes: f96a3d74554d ("ipv4: Fix incorrect route flushing when source address is deleted")
    Reported-by: gaoxingwang <gaoxingwang1@huawei.com>
    Link: https://lore.kernel.org/netdev/20230314144159.2354729-1-gaoxingwang1@huawei.com/
    Tested-by: gaoxingwang <gaoxingwang1@huawei.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20230315124009.4015212-1-idosch@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipvlan: Make skb->skb_iif track skb->dev for l3s mode [+ + +]
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Thu Mar 9 10:03:36 2023 +0800

    ipvlan: Make skb->skb_iif track skb->dev for l3s mode
    
    [ Upstream commit 59a0b022aa249e3f5735d93de0849341722c4754 ]
    
    For l3s mode, skb->dev is set to ipvlan interface in ipvlan_nf_input():
      skb->dev = addr->master->dev
    but, skb->skb_iif remain unchanged, this will cause socket lookup failed
    if a target socket is bound to a interface, like the following example:
    
      ip link add ipvlan0 link eth0 type ipvlan mode l3s
      ip addr add dev ipvlan0 192.168.124.111/24
      ip link set ipvlan0 up
    
      ping -c 1 -I ipvlan0 8.8.8.8
      100% packet loss
    
    This is because there is no match sk in __raw_v4_lookup() as sk->sk_bound_dev_if != dif(skb->skb_iif).
    Fix this by make skb->skb_iif track skb->dev in ipvlan_nf_input().
    
    Fixes: c675e06a98a4 ("ipvlan: decouple l3s mode dependencies from other modes")
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/29865b1f-6db7-c07a-de89-949d3721ea30@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jffs2: correct logic when creating a hole in jffs2_write_begin [+ + +]
Author: Yifei Liu <yifeliu@cs.stonybrook.edu>
Date:   Wed Aug 3 15:53:12 2022 +0000

    jffs2: correct logic when creating a hole in jffs2_write_begin
    
    [ Upstream commit 23892d383bee15b64f5463bd7195615734bb2415 ]
    
    Bug description and fix:
    
    1. Write data to a file, say all 1s from offset 0 to 16.
    
    2. Truncate the file to a smaller size, say 8 bytes.
    
    3. Write new bytes (say 2s) from an offset past the original size of the
    file, say at offset 20, for 4 bytes.  This is supposed to create a "hole"
    in the file, meaning that the bytes from offset 8 (where it was truncated
    above) up to the new write at offset 20, should all be 0s (zeros).
    
    4. Flush all caches using "echo 3 > /proc/sys/vm/drop_caches" (or unmount
    and remount) the f/s.
    
    5. Check the content of the file.  It is wrong.  The 1s that used to be
    between bytes 9 and 16, before the truncation, have REAPPEARED (they should
    be 0s).
    
    We wrote a script and helper C program to reproduce the bug
    (reproduce_jffs2_write_begin_issue.sh, write_file.c, and Makefile).  We can
    make them available to anyone.
    
    The above example is shown when writing a small file within the same first
    page.  But the bug happens for larger files, as long as steps 1, 2, and 3
    above all happen within the same page.
    
    The problem was traced to the jffs2_write_begin code, where it goes into an
    'if' statement intended to handle writes past the current EOF (i.e., writes
    that may create a hole).  The code computes a 'pageofs' that is the floor
    of the write position (pos), aligned to the page size boundary.  In other
    words, 'pageofs' will never be larger than 'pos'.  The code then sets the
    internal jffs2_raw_inode->isize to the size of max(current inode size,
    pageofs) but that is wrong: the new file size should be the 'pos', which is
    larger than both the current inode size and pageofs.
    
    Similarly, the code incorrectly sets the internal jffs2_raw_inode->dsize to
    the difference between the pageofs minus current inode size; instead it
    should be the current pos minus the current inode size.  Finally,
    inode->i_size was also set incorrectly.
    
    The patch below fixes this bug.  The bug was discovered using a new tool
    for finding f/s bugs using model checking, called MCFS (Model Checking File
    Systems).
    
    Signed-off-by: Yifei Liu <yifeliu@cs.stonybrook.edu>
    Signed-off-by: Erez Zadok <ezk@cs.stonybrook.edu>
    Signed-off-by: Manish Adkar <madkar@cs.stonybrook.edu>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kconfig: Update config changed flag before calling callback [+ + +]
Author: Jurica Vukadin <jura@vukad.in>
Date:   Tue Mar 7 20:40:39 2023 +0100

    kconfig: Update config changed flag before calling callback
    
    [ Upstream commit ee06a3ef7e3cddb62b90ac40aa661d3c12f7cabc ]
    
    Prior to commit 5ee546594025 ("kconfig: change sym_change_count to a
    boolean flag"), the conf_updated flag was set to the new value *before*
    calling the callback. xconfig's save action depends on this behaviour,
    because xconfig calls conf_get_changed() directly from the callback and
    now sees the old value, thus never enabling the save button or the
    shortcut.
    
    Restore the previous behaviour.
    
    Fixes: 5ee546594025 ("kconfig: change sym_change_count to a boolean flag")
    Signed-off-by: Jurica Vukadin <jura@vukad.in>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: nVMX: add missing consistency checks for CR0 and CR4 [+ + +]
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Mar 10 11:10:56 2023 -0500

    KVM: nVMX: add missing consistency checks for CR0 and CR4
    
    commit 112e66017bff7f2837030f34c2bc19501e9212d5 upstream.
    
    The effective values of the guest CR0 and CR4 registers may differ from
    those included in the VMCS12.  In particular, disabling EPT forces
    CR4.PAE=1 and disabling unrestricted guest mode forces CR0.PG=CR0.PE=1.
    
    Therefore, checks on these bits cannot be delegated to the processor
    and must be performed by KVM.
    
    Reported-by: Reima ISHII <ishiir@g.ecc.u-tokyo.ac.jp>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: SVM: Fix a benign off-by-one bug in AVIC physical table mask [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Feb 7 00:21:54 2023 +0000

    KVM: SVM: Fix a benign off-by-one bug in AVIC physical table mask
    
    commit 3ec7a1b2743c07c45f4a0c508114f6cb410ddef3 upstream.
    
    Define the "physical table max index mask" as bits 8:0, not 9:0.  x2AVIC
    currently supports a max of 512 entries, i.e. the max index is 511, and
    the inputs to GENMASK_ULL() are inclusive.  The bug is benign as bit 9 is
    reserved and never set by KVM, i.e. KVM is just clearing bits that are
    guaranteed to be zero.
    
    Note, as of this writing, APM "Rev. 3.39-October 2022" incorrectly states
    that bits 11:8 are reserved in Table B-1. VMCB Layout, Control Area.  I.e.
    that table wasn't updated when x2AVIC support was added.
    
    Opportunistically fix the comment for the max AVIC ID to align with the
    code, and clean up comment formatting too.
    
    Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode")
    Cc: stable@vger.kernel.org
    Cc: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
    Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Message-Id: <20230207002156.521736-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: SVM: Modify AVIC GATag to support max number of 512 vCPUs [+ + +]
Author: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Date:   Tue Feb 7 00:21:55 2023 +0000

    KVM: SVM: Modify AVIC GATag to support max number of 512 vCPUs
    
    commit 5999715922c5a3ede5d8fe2a6b17aba58a157d41 upstream.
    
    Define AVIC_VCPU_ID_MASK based on AVIC_PHYSICAL_MAX_INDEX, i.e. the mask
    that effectively controls the largest guest physical APIC ID supported by
    x2AVIC, instead of hardcoding the number of bits to 8 (and the number of
    VM bits to 24).
    
    The AVIC GATag is programmed into the AMD IOMMU IRTE to provide a
    reference back to KVM in case the IOMMU cannot inject an interrupt into a
    non-running vCPU.  In such a case, the IOMMU notifies software by creating
    a GALog entry with the corresponded GATag, and KVM then uses the GATag to
    find the correct VM+vCPU to kick.  Dropping bit 8 from the GATag results
    in kicking the wrong vCPU when targeting vCPUs with x2APIC ID > 255.
    
    Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode")
    Cc: stable@vger.kernel.org
    Reported-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Co-developed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Message-Id: <20230207002156.521736-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.1.21 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 22 13:34:07 2023 +0100

    Linux 6.1.21
    
    Link: https://lore.kernel.org/r/20230320145507.420176832@linuxfoundation.org
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20230321080705.245176209@linuxfoundation.org
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Slade Watkins <srw@sladewatkins.net>
    Link: https://lore.kernel.org/r/20230321180747.474321236@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Only call get_timer_irq() once in constant_clockevent_init() [+ + +]
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Sat Feb 25 15:52:56 2023 +0800

    LoongArch: Only call get_timer_irq() once in constant_clockevent_init()
    
    [ Upstream commit bb7a78e343468873bf00b2b181fcfd3c02d8cb56 ]
    
    Under CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_PREEMPT=y, we can see
    the following messages on LoongArch, this is because using might_sleep()
    in preemption disable context.
    
    [    0.001127] smp: Bringing up secondary CPUs ...
    [    0.001222] Booting CPU#1...
    [    0.001244] 64-bit Loongson Processor probed (LA464 Core)
    [    0.001247] CPU1 revision is: 0014c012 (Loongson-64bit)
    [    0.001250] FPU1 revision is: 00000000
    [    0.001252] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
    [    0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
    [    0.001257] preempt_count: 1, expected: 0
    [    0.001258] RCU nest depth: 0, expected: 0
    [    0.001259] Preemption disabled at:
    [    0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110
    [    0.001272] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc7+ #43
    [    0.001275] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202
    [    0.001277] Stack : 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000
    [    0.001286]         90000001001e3be0 90000001001e3be8 0000000000000000 0000000000000000
    [    0.001292]         90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50
    [    0.001297]         9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500
    [    0.001303]         0000000000000001 0000000000000001 00000000ffffe0a2 0000000000000020
    [    0.001309]         000000000000002f 9000000001354116 00000000056b0000 ffffffffffffffff
    [    0.001314]         0000000000000000 0000000000000000 90000000014f6e90 9000000001642000
    [    0.001320]         900000000022b69c 0000000000000001 0000000000000000 9000000001736a90
    [    0.001325]         9000000100038000 0000000000000000 9000000000222f34 0000000000000000
    [    0.001331]         00000000000000b0 0000000000000004 0000000000000000 0000000000070000
    [    0.001337]         ...
    [    0.001339] Call Trace:
    [    0.001342] [<9000000000222f34>] show_stack+0x5c/0x180
    [    0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88
    [    0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc
    [    0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64
    [    0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124
    [    0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204
    [    0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8
    [    0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64
    
    Here are the complete call chains:
    
    smpboot_entry()
      start_secondary()
        constant_clockevent_init()
          get_timer_irq()
            irq_find_matching_fwnode()
              irq_find_matching_fwspec()
                mutex_lock()
                  might_sleep()
                    __might_sleep()
                      __might_resched()
    
    In order to avoid the above issue, we should break the call chains,
    using timer_irq_installed variable as check condition to only call
    get_timer_irq() once in constant_clockevent_init() is a simple and
    proper way.
    
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
loop: Fix use-after-free issues [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Mar 14 11:21:54 2023 -0700

    loop: Fix use-after-free issues
    
    [ Upstream commit 9b0cb770f5d7b1ff40bea7ca385438ee94570eec ]
    
    do_req_filebacked() calls blk_mq_complete_request() synchronously or
    asynchronously when using asynchronous I/O unless memory allocation fails.
    Hence, modify loop_handle_cmd() such that it does not dereference 'cmd' nor
    'rq' after do_req_filebacked() finished unless we are sure that the request
    has not yet been completed. This patch fixes the following kernel crash:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000054
    Call trace:
     css_put.42938+0x1c/0x1ac
     loop_process_work+0xc8c/0xfd4
     loop_rootcg_workfn+0x24/0x34
     process_one_work+0x244/0x558
     worker_thread+0x400/0x8fc
     kthread+0x16c/0x1e0
     ret_from_fork+0x10/0x20
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Dan Schatzberg <schatzberg.dan@gmail.com>
    Fixes: c74d40e8b5e2 ("loop: charge i/o to mem and blk cg")
    Fixes: bc07c10a3603 ("block: loop: support DIO & AIO")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20230314182155.80625-1-bvanassche@acm.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: select BLOCK_LEGACY_AUTOLOAD [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Mon Mar 13 13:29:17 2023 -0700

    md: select BLOCK_LEGACY_AUTOLOAD
    
    commit 6c0f5898836c05c6d850a750ed7940ba29e4e6c5 upstream.
    
    When BLOCK_LEGACY_AUTOLOAD is not enable, mdadm is not able to
    activate new arrays unless "CREATE names=yes" appears in
    mdadm.conf
    
    As this is a regression we need to always enable BLOCK_LEGACY_AUTOLOAD
    for when MD is selected - at least until mdadm is updated and the
    updates widely available.
    
    Cc: stable@vger.kernel.org # v5.18+
    Fixes: fbdee71bb5d8 ("block: deprecate autoloading based on dev_t")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: m5mols: fix off-by-one loop termination error [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Mar 17 13:51:17 2023 -0700

    media: m5mols: fix off-by-one loop termination error
    
    [ Upstream commit efbcbb12ee99f750c9f25c873b55ad774871de2a ]
    
    The __find_restype() function loops over the m5mols_default_ffmt[]
    array, and the termination condition ends up being wrong: instead of
    stopping when the iterator becomes the size of the array it traverses,
    it stops after it has already overshot the array.
    
    Now, in practice this doesn't likely matter, because the code will
    always find the entry it looks for, and will thus return early and never
    hit that last extra iteration.
    
    But it turns out that clang will unroll the loop fully, because it has
    only two iterations (well, three due to the off-by-one bug), and then
    clang will end up just giving up in the middle of the loop unrolling
    when it notices that the code walks past the end of the array.
    
    And that made 'objtool' very unhappy indeed, because the generated code
    just falls off the edge of the universe, and ends up falling through to
    the next function, causing this warning:
    
       drivers/media/i2c/m5mols/m5mols.o: warning: objtool: m5mols_set_fmt() falls through to next function m5mols_get_frame_desc()
    
    Fix the loop ending condition.
    
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Analyzed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Analyzed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/linux-block/CAHk-=wgTSdKYbmB1JYM5vmHMcD9J9UZr0mn7BOYM_LudrP+Xvw@mail.gmail.com/
    Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP")
    Cc: HeungJun, Kim <riverful.kim@samsung.com>
    Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memory: tegra124-emc: fix interconnect registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:46 2023 +0100

    memory: tegra124-emc: fix interconnect registration race
    
    commit abd9f1b49cf25eebeaba193c7707355be3f48dae upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 380def2d4cf2 ("memory: tegra124: Support interconnect framework")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-19-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

memory: tegra20-emc: fix interconnect registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:47 2023 +0100

    memory: tegra20-emc: fix interconnect registration race
    
    commit c5587f61ec050f7e9ebb3e2da29d12af63e833d3 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: d5ef16ba5fbe ("memory: tegra20: Support interconnect framework")
    Cc: stable@vger.kernel.org      # 5.11
    Cc: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-20-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

memory: tegra30-emc: fix interconnect registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:48 2023 +0100

    memory: tegra30-emc: fix interconnect registration race
    
    commit 9db481c909dd6312ccfbdc7e343b50e41c727483 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: d5ef16ba5fbe ("memory: tegra20: Support interconnect framework")
    Cc: stable@vger.kernel.org      # 5.11
    Cc: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-21-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

memory: tegra: fix interconnect registration race [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 08:56:45 2023 +0100

    memory: tegra: fix interconnect registration race
    
    commit 5553055c62683ce339f9ef5fb2a26c8331485d68 upstream.
    
    The current interconnect provider registration interface is inherently
    racy as nodes are not added until the after adding the provider. This
    can specifically cause racing DT lookups to fail.
    
    Switch to using the new API where the provider is not registered until
    after it has been fully initialised.
    
    Fixes: 06f079816d4c ("memory: tegra-mc: Add interconnect framework")
    Cc: stable@vger.kernel.org      # 5.11
    Cc: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230306075651.2449-18-johan+linaro@kernel.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mlxsw: spectrum: Fix incorrect parsing depth after reload [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Mar 13 18:21:24 2023 +0100

    mlxsw: spectrum: Fix incorrect parsing depth after reload
    
    [ Upstream commit 35c356924fe3669dfbb1185607ce3b37f70bfa80 ]
    
    Spectrum ASICs have a configurable limit on how deep into the packet
    they parse. By default, the limit is 96 bytes.
    
    There are several cases where this parsing depth is not enough and there
    is a need to increase it. For example, timestamping of PTP packets and a
    FIB multipath hash policy that requires hashing on inner fields. The
    driver therefore maintains a reference count that reflects the number of
    consumers that require an increased parsing depth.
    
    During reload_down() the parsing depth reference count does not
    necessarily drop to zero, but the parsing depth itself is restored to
    the default during reload_up() when the firmware is reset. It is
    therefore possible to end up in situations where the driver thinks that
    the parsing depth was increased (reference count is non-zero), when it
    is not.
    
    Fix by making sure that all the consumers that increase the parsing
    depth reference count also decrease it during reload_down().
    Specifically, make sure that when the routing code is de-initialized it
    drops the reference count if it was increased because of a FIB multipath
    hash policy that requires hashing on inner fields.
    
    Add a warning if the reference count is not zero after the driver was
    de-initialized and explicitly reset it to zero during initialization for
    good measures.
    
    Fixes: 2d91f0803b84 ("mlxsw: spectrum: Add infrastructure for parsing configuration")
    Reported-by: Maksym Yaremchuk <maksymy@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Link: https://lore.kernel.org/r/9c35e1b3e6c1d8f319a2449d14e2b86373f3b3ba.1678727526.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/userfaultfd: propagate uffd-wp bit when PTE-mapping the huge zeropage [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Mar 2 18:54:23 2023 +0100

    mm/userfaultfd: propagate uffd-wp bit when PTE-mapping the huge zeropage
    
    commit 42b2af2c9b7eede8ef21d0943f84d135e21a32a3 upstream.
    
    Currently, we'd lose the userfaultfd-wp marker when PTE-mapping a huge
    zeropage, resulting in the next write faults in the PMD range not
    triggering uffd-wp events.
    
    Various actions (partial MADV_DONTNEED, partial mremap, partial munmap,
    partial mprotect) could trigger this.  However, most importantly,
    un-protecting a single sub-page from the userfaultfd-wp handler when
    processing a uffd-wp event will PTE-map the shared huge zeropage and lose
    the uffd-wp bit for the remainder of the PMD.
    
    Let's properly propagate the uffd-wp bit to the PMDs.
    
     #define _GNU_SOURCE
     #include <stdio.h>
     #include <stdlib.h>
     #include <stdint.h>
     #include <stdbool.h>
     #include <inttypes.h>
     #include <fcntl.h>
     #include <unistd.h>
     #include <errno.h>
     #include <poll.h>
     #include <pthread.h>
     #include <sys/mman.h>
     #include <sys/syscall.h>
     #include <sys/ioctl.h>
     #include <linux/userfaultfd.h>
    
     static size_t pagesize;
     static int uffd;
     static volatile bool uffd_triggered;
    
     #define barrier() __asm__ __volatile__("": : :"memory")
    
     static void uffd_wp_range(char *start, size_t size, bool wp)
     {
            struct uffdio_writeprotect uffd_writeprotect;
    
            uffd_writeprotect.range.start = (unsigned long) start;
            uffd_writeprotect.range.len = size;
            if (wp) {
                    uffd_writeprotect.mode = UFFDIO_WRITEPROTECT_MODE_WP;
            } else {
                    uffd_writeprotect.mode = 0;
            }
            if (ioctl(uffd, UFFDIO_WRITEPROTECT, &uffd_writeprotect)) {
                    fprintf(stderr, "UFFDIO_WRITEPROTECT failed: %d\n", errno);
                    exit(1);
            }
     }
    
     static void *uffd_thread_fn(void *arg)
     {
            static struct uffd_msg msg;
            ssize_t nread;
    
            while (1) {
                    struct pollfd pollfd;
                    int nready;
    
                    pollfd.fd = uffd;
                    pollfd.events = POLLIN;
                    nready = poll(&pollfd, 1, -1);
                    if (nready == -1) {
                            fprintf(stderr, "poll() failed: %d\n", errno);
                            exit(1);
                    }
    
                    nread = read(uffd, &msg, sizeof(msg));
                    if (nread <= 0)
                            continue;
    
                    if (msg.event != UFFD_EVENT_PAGEFAULT ||
                        !(msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP)) {
                            printf("FAIL: wrong uffd-wp event fired\n");
                            exit(1);
                    }
    
                    /* un-protect the single page. */
                    uffd_triggered = true;
                    uffd_wp_range((char *)(uintptr_t)msg.arg.pagefault.address,
                                  pagesize, false);
            }
            return arg;
     }
    
     static int setup_uffd(char *map, size_t size)
     {
            struct uffdio_api uffdio_api;
            struct uffdio_register uffdio_register;
            pthread_t thread;
    
            uffd = syscall(__NR_userfaultfd,
                           O_CLOEXEC | O_NONBLOCK | UFFD_USER_MODE_ONLY);
            if (uffd < 0) {
                    fprintf(stderr, "syscall() failed: %d\n", errno);
                    return -errno;
            }
    
            uffdio_api.api = UFFD_API;
            uffdio_api.features = UFFD_FEATURE_PAGEFAULT_FLAG_WP;
            if (ioctl(uffd, UFFDIO_API, &uffdio_api) < 0) {
                    fprintf(stderr, "UFFDIO_API failed: %d\n", errno);
                    return -errno;
            }
    
            if (!(uffdio_api.features & UFFD_FEATURE_PAGEFAULT_FLAG_WP)) {
                    fprintf(stderr, "UFFD_FEATURE_WRITEPROTECT missing\n");
                    return -ENOSYS;
            }
    
            uffdio_register.range.start = (unsigned long) map;
            uffdio_register.range.len = size;
            uffdio_register.mode = UFFDIO_REGISTER_MODE_WP;
            if (ioctl(uffd, UFFDIO_REGISTER, &uffdio_register) < 0) {
                    fprintf(stderr, "UFFDIO_REGISTER failed: %d\n", errno);
                    return -errno;
            }
    
            pthread_create(&thread, NULL, uffd_thread_fn, NULL);
    
            return 0;
     }
    
     int main(void)
     {
            const size_t size = 4 * 1024 * 1024ull;
            char *map, *cur;
    
            pagesize = getpagesize();
    
            map = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0);
            if (map == MAP_FAILED) {
                    fprintf(stderr, "mmap() failed\n");
                    return -errno;
            }
    
            if (madvise(map, size, MADV_HUGEPAGE)) {
                    fprintf(stderr, "MADV_HUGEPAGE failed\n");
                    return -errno;
            }
    
            if (setup_uffd(map, size))
                    return 1;
    
            /* Read the whole range, populating zeropages. */
            madvise(map, size, MADV_POPULATE_READ);
    
            /* Write-protect the whole range. */
            uffd_wp_range(map, size, true);
    
            /* Make sure uffd-wp triggers on each page. */
            for (cur = map; cur < map + size; cur += pagesize) {
                    uffd_triggered = false;
    
                    barrier();
                    /* Trigger a write fault. */
                    *cur = 1;
                    barrier();
    
                    if (!uffd_triggered) {
                            printf("FAIL: uffd-wp did not trigger\n");
                            return 1;
                    }
            }
    
            printf("PASS: uffd-wp triggered\n");
            return 0;
     }
    
    Link: https://lkml.kernel.org/r/20230302175423.589164-1-david@redhat.com
    Fixes: e06f1e1dd499 ("userfaultfd: wp: enabled write protection in userfaultfd API")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Acked-by: Peter Xu <peterx@redhat.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Shaohua Li <shli@fb.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: teach mincore_hugetlb about pte markers [+ + +]
Author: James Houghton <jthoughton@google.com>
Date:   Thu Mar 2 22:24:04 2023 +0000

    mm: teach mincore_hugetlb about pte markers
    
    commit 63cf584203f3367c8b073d417c8e5cbbfc450506 upstream.
    
    By checking huge_pte_none(), we incorrectly classify PTE markers as
    "present".  Instead, check huge_pte_none_mostly(), classifying PTE markers
    the same as if the PTE were completely blank.
    
    PTE markers, unlike other kinds of swap entries, don't reference any
    physical page and don't indicate that a physical page was mapped
    previously.  As such, treat them as non-present for the sake of mincore().
    
    Link: https://lkml.kernel.org/r/20230302222404.175303-1-jthoughton@google.com
    Fixes: 5c041f5d1f23 ("mm: teach core mm about pte markers")
    Signed-off-by: James Houghton <jthoughton@google.com>
    Acked-by: Peter Xu <peterx@redhat.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: James Houghton <jthoughton@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: atmel-mci: fix race between stop command and start of next command [+ + +]
Author: Tobias Schramm <t.schramm@manjaro.org>
Date:   Fri Dec 30 20:43:15 2022 +0100

    mmc: atmel-mci: fix race between stop command and start of next command
    
    [ Upstream commit eca5bd666b0aa7dc0bca63292e4778968241134e ]
    
    This commit fixes a race between completion of stop command and start of a
    new command.
    Previously the command ready interrupt was enabled before stop command
    was written to the command register. This caused the command ready
    interrupt to fire immediately since the CMDRDY flag is asserted constantly
    while there is no command in progress.
    Consequently the command state machine will immediately advance to the
    next state when the tasklet function is executed again, no matter
    actual completion state of the stop command.
    Thus a new command can then be dispatched immediately, interrupting and
    corrupting the stop command on the CMD line.
    Fix that by dropping the command ready interrupt enable before calling
    atmci_send_stop_cmd. atmci_send_stop_cmd does already enable the
    command ready interrupt, no further writes to ATMCI_IER are necessary.
    
    Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Link: https://lore.kernel.org/r/20221230194315.809903-2-t.schramm@manjaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_am654: lower power-on failed message severity [+ + +]
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Mon Mar 6 17:27:51 2023 +0100

    mmc: sdhci_am654: lower power-on failed message severity
    
    commit 11440da77d6020831ee6f9ce4551b545dea789ee upstream.
    
    Lower the power-on failed message severity from warn to info when the
    controller does not power-up. It's normal to have this situation when
    the SD card slot is empty, therefore we should not warn the user about
    it.
    
    Fixes: 7ca0f166f5b2 ("mmc: sdhci_am654: Add workaround for card detect debounce timer")
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230306162751.163369-1-francesco@dolcini.it
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mptcp: add ro_after_init for tcp{,v6}_prot_override [+ + +]
Author: Geliang Tang <geliang.tang@suse.com>
Date:   Thu Mar 9 15:50:02 2023 +0100

    mptcp: add ro_after_init for tcp{,v6}_prot_override
    
    commit 822467a48e938e661965d09df5fcac66f7291050 upstream.
    
    Add __ro_after_init labels for the variables tcp_prot_override and
    tcpv6_prot_override, just like other variables adjacent to them, to
    indicate that they are initialised from the init hooks and no writes
    occur afterwards.
    
    Fixes: b19bc2945b40 ("mptcp: implement delegated actions")
    Cc: stable@vger.kernel.org
    Fixes: 51fa7f8ebf0e ("mptcp: mark ops structures as ro_after_init")
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: avoid setting TCP_CLOSE state twice [+ + +]
Author: Matthieu Baerts <matthieu.baerts@tessares.net>
Date:   Thu Mar 9 15:50:03 2023 +0100

    mptcp: avoid setting TCP_CLOSE state twice
    
    commit 3ba14528684f528566fb7d956bfbfb958b591d86 upstream.
    
    tcp_set_state() is called from tcp_done() already.
    
    There is then no need to first set the state to TCP_CLOSE, then call
    tcp_done().
    
    Fixes: d582484726c4 ("mptcp: fix fallback for MP_JOIN subflows")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/362
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: fix lockdep false positive in mptcp_pm_nl_create_listen_socket() [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Mar 9 15:50:04 2023 +0100

    mptcp: fix lockdep false positive in mptcp_pm_nl_create_listen_socket()
    
    commit cee4034a3db1d30c3243dd51506a9d4ab1a849fa upstream.
    
    Christoph reports a lockdep splat in the mptcp_subflow_create_socket()
    error path, when such function is invoked by
    mptcp_pm_nl_create_listen_socket().
    
    Such code path acquires two separates, nested socket lock, with the
    internal lock operation lacking the "nested" annotation. Adding that
    in sock_release() for mptcp's sake only could be confusing.
    
    Instead just add a new lockclass to the in-kernel msk socket,
    re-initializing the lockdep infra after the socket creation.
    
    Fixes: ad2171009d96 ("mptcp: fix locking for in-kernel listener creation")
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/354
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Tested-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: fix possible deadlock in subflow_error_report [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Mar 9 15:49:57 2023 +0100

    mptcp: fix possible deadlock in subflow_error_report
    
    commit b7a679ba7c652587b85294f4953f33ac0b756d40 upstream.
    
    Christoph reported a possible deadlock while the TCP stack
    destroys an unaccepted subflow due to an incoming reset: the
    MPTCP socket error path tries to acquire the msk-level socket
    lock while TCP still owns the listener socket accept queue
    spinlock, and the reverse dependency already exists in the
    TCP stack.
    
    Note that the above is actually a lockdep false positive, as
    the chain involves two separate sockets. A different per-socket
    lockdep key will address the issue, but such a change will be
    quite invasive.
    
    Instead, we can simply stop earlier the socket error handling
    for orphaned or unaccepted subflows, breaking the critical
    lockdep chain. Error handling in such a scenario is a no-op.
    
    Reported-and-tested-by: Christoph Paasch <cpaasch@apple.com>
    Fixes: 15cc10453398 ("mptcp: deliver ssk errors to msk")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/355
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/9p: fix bug in client create for .L [+ + +]
Author: Eric Van Hensbergen <ericvh@kernel.org>
Date:   Sun Dec 18 17:57:27 2022 +0000

    net/9p: fix bug in client create for .L
    
    [ Upstream commit 3866584a1c56a2bbc8c0981deb4476d0b801969e ]
    
    We are supposed to set fid->mode to reflect the flags
    that were used to open the file.  We were actually setting
    it to the creation mode which is the default perms of the
    file not the flags the file was opened with.
    
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Reviewed-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/iucv: Fix size of interrupt data [+ + +]
Author: Alexandra Winter <wintera@linux.ibm.com>
Date:   Wed Mar 15 14:14:35 2023 +0100

    net/iucv: Fix size of interrupt data
    
    [ Upstream commit 3d87debb8ed2649608ff432699e7c961c0c6f03b ]
    
    iucv_irq_data needs to be 4 bytes larger.
    These bytes are not used by the iucv module, but written by
    the z/VM hypervisor in case a CPU is deconfigured.
    
    Reported as:
    BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten
    -----------------------------------------------------------------------------
    0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc
    Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1
    __kmem_cache_alloc_node+0x166/0x450
    kmalloc_node_trace+0x3a/0x70
    iucv_cpu_prepare+0x44/0xd0
    cpuhp_invoke_callback+0x156/0x2f0
    cpuhp_issue_call+0xf0/0x298
    __cpuhp_setup_state_cpuslocked+0x136/0x338
    __cpuhp_setup_state+0xf4/0x288
    iucv_init+0xf4/0x280
    do_one_initcall+0x78/0x390
    do_initcalls+0x11a/0x140
    kernel_init_freeable+0x25e/0x2a0
    kernel_init+0x2e/0x170
    __ret_from_fork+0x3c/0x58
    ret_from_fork+0xa/0x40
    Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1
    __kmem_cache_free+0x308/0x358
    iucv_init+0x92/0x280
    do_one_initcall+0x78/0x390
    do_initcalls+0x11a/0x140
    kernel_init_freeable+0x25e/0x2a0
    kernel_init+0x2e/0x170
    __ret_from_fork+0x3c/0x58
    ret_from_fork+0xa/0x40
    Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0|
    Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000
    Redzone  0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Object   0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00  ................
    Object   0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2  ................
    Object   0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc  ................
    Object   0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400580: cc cc cc cc cc cc cc cc                          ........
    Padding  00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
    Padding  00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
    Padding  00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
    CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1
    Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)
    Call Trace:
    [<000000032aa034ec>] dump_stack_lvl+0xac/0x100
    [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140
    [<0000000329f5aa78>] check_object+0x370/0x3c0
    [<0000000329f5ede6>] free_debug_processing+0x15e/0x348
    [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0
    [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8
    [<0000000329f61768>] __kmem_cache_free+0x308/0x358
    [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88
    [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0
    [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0
    [<0000000329c3243e>] cpu_device_down+0x4e/0x78
    [<000000032a61dee0>] device_offline+0xc8/0x118
    [<000000032a61e048>] online_store+0x60/0xe0
    [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8
    [<0000000329fab65c>] vfs_write+0x174/0x360
    [<0000000329fab9fc>] ksys_write+0x74/0x100
    [<000000032aa03a5a>] __do_syscall+0x1da/0x208
    [<000000032aa177b2>] system_call+0x82/0xb0
    INFO: lockdep is turned off.
    FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc
    FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
    
    Fixes: 2356f4cb1911 ("[S390]: Rewrite of the IUCV base code, part 2")
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230315131435.4113889-1-wintera@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Disable eswitch before waiting for VF pages [+ + +]
Author: Daniel Jurgens <danielj@nvidia.com>
Date:   Thu Oct 20 00:13:50 2022 +0300

    net/mlx5: Disable eswitch before waiting for VF pages
    
    [ Upstream commit 7ba930fc25def6fd736abcdfa224272948a65cf7 ]
    
    The offending commit changed the ordering of moving to legacy mode and
    waiting for the VF pages. Moving to legacy mode is important in
    bluefield, because it sends the host driver into error state, and frees
    its pages. Without this transition we end up waiting 2 minutes for
    pages that aren't coming before carrying on with the unload process.
    
    Fixes: f019679ea5f2 ("net/mlx5: E-switch, Remove dependency between sriov and eswitch mode")
    Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: E-switch, Fix missing set of split_count when forward to ovs internal port [+ + +]
Author: Maor Dickman <maord@nvidia.com>
Date:   Wed Feb 8 11:37:41 2023 +0200

    net/mlx5: E-switch, Fix missing set of split_count when forward to ovs internal port
    
    [ Upstream commit 28d3815a629cbdee660dd1c9de28d77cb3d77917 ]
    
    Rules with mirror actions are split to two FTEs when the actions after the mirror
    action contains pedit, vlan push/pop or ct. Forward to ovs internal port adds
    implicit header rewrite (pedit) but missing trigger to do split.
    
    Fix by setting split_count when forwarding to ovs internal port which
    will trigger split in mirror rules.
    
    Fixes: 27484f7170ed ("net/mlx5e: Offload tc rules that redirect to ovs internal port")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: E-switch, Fix wrong usage of source port rewrite in split rules [+ + +]
Author: Maor Dickman <maord@nvidia.com>
Date:   Tue Feb 7 15:07:00 2023 +0200

    net/mlx5: E-switch, Fix wrong usage of source port rewrite in split rules
    
    [ Upstream commit 1313d78ac0c1cfcff7bdece8da54b080e71487c4 ]
    
    In few cases, rules with mirror use case are split to two FTEs, one which
    do the mirror action and forward to second FTE which do the rest of the rule
    actions and the second redirect action.
    In case of mirror rules which do split and forward to ovs internal port or
    VF stack devices, source port rewrite should be used in the second FTE but
    it is wrongly also set in the first FTE which break the offload.
    
    Fix this issue by removing the wrong check if source port rewrite is needed to
    be used on the first FTE of the split and instead return EOPNOTSUPP which will
    block offload of rules which mirror to ovs internal port or VF stack devices
    which isn't supported.
    
    Fixes: 10742efc20a4 ("net/mlx5e: VF tunnel TX traffic offloading")
    Fixes: a508728a4c8b ("net/mlx5e: VF tunnel RX traffic offloading")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Fix setting ec_function bit in MANAGE_PAGES [+ + +]
Author: Parav Pandit <parav@nvidia.com>
Date:   Thu Jun 24 18:22:57 2021 +0300

    net/mlx5: Fix setting ec_function bit in MANAGE_PAGES
    
    [ Upstream commit ba5d8f72b82cc197355c9340ef89dab813815865 ]
    
    When ECPF is a page supplier, reclaim pages missed to honor the
    ec_function bit provided by the firmware. It always used the ec_function
    to true during driver unload flow for ECPF. This is incorrect.
    
    Honor the ec_function bit provided by device during page allocation
    request event.
    
    Fixes: d6945242f45d ("net/mlx5: Hold pages RB tree per VF")
    Signed-off-by: Parav Pandit <parav@nvidia.com>
    Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Set BREAK_FW_WAIT flag first when removing driver [+ + +]
Author: Shay Drory <shayd@nvidia.com>
Date:   Tue Feb 28 10:36:19 2023 +0200

    net/mlx5: Set BREAK_FW_WAIT flag first when removing driver
    
    [ Upstream commit 031a163f2c476adcb2c01e27a7d323e66174ac11 ]
    
    Currently, BREAK_FW_WAIT flag is set after syncing with fw_reset.
    However, fw_reset can call mlx5_load_one() which is waiting for fw
    init bit and BREAK_FW_WAIT flag is intended to stop. e.g.: the driver
    might wait on a loop it should exit.
    Fix it by setting the flag before syncing with fw_reset.
    
    Fixes: 8324a02c342a ("net/mlx5: Add exit route when waiting for FW")
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Don't cache tunnel offloads capability [+ + +]
Author: Parav Pandit <parav@nvidia.com>
Date:   Fri Mar 12 07:21:29 2021 -0600

    net/mlx5e: Don't cache tunnel offloads capability
    
    [ Upstream commit 9a92fe1db9e57ea94388a1d768e8ee42af858377 ]
    
    When mlx5e attaches again after device health recovery, the device
    capabilities might have changed by the eswitch manager.
    
    For example in one flow when ECPF changes the eswitch mode between
    legacy and switchdev, it updates the flow table tunnel capability.
    
    The cached value is only used in one place, so just check the capability
    there instead.
    
    Fixes: 5bef709d76a2 ("net/mlx5: Enable host PF HCA after eswitch is initialized")
    Signed-off-by: Parav Pandit <parav@nvidia.com>
    Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix cleanup null-ptr deref on encap lock [+ + +]
Author: Paul Blakey <paulb@nvidia.com>
Date:   Sun Feb 12 11:01:43 2023 +0200

    net/mlx5e: Fix cleanup null-ptr deref on encap lock
    
    [ Upstream commit c9668f0b1d28570327dbba189f2c61f6f9e43ae7 ]
    
    During module is unloaded while a peer tc flow is still offloaded,
    first the peer uplink rep profile is changed to a nic profile, and so
    neigh encap lock is destroyed. Next during unload, the VF reps netdevs
    are unregistered which causes the original non-peer tc flow to be deleted,
    which deletes the peer flow. The peer flow deletion detaches the encap
    entry and try to take the already destroyed encap lock, causing the
    below trace.
    
    Fix this by clearing peer flows during tc eswitch cleanup
    (mlx5e_tc_esw_cleanup()).
    
    Relevant trace:
    [ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8
    [ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40
    [ 4316.851897] Call Trace:
    [ 4316.852481]  <TASK>
    [ 4316.857214]  mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core]
    [ 4316.858258]  mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core]
    [ 4316.859134]  mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core]
    [ 4316.859867]  clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core]
    [ 4316.860605]  mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core]
    [ 4316.862609]  __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core]
    [ 4316.863394]  mlx5e_tc_del_flow+0x(/0x630 [mlx5_core]
    [ 4316.864090]  mlx5e_flow_put+0x5f/0x100 [mlx5_core]
    [ 4316.864771]  mlx5e_delete_flower+0x4de/0xa40 [mlx5_core]
    [ 4316.865486]  tc_setup_cb_reoffload+0x20/0x80
    [ 4316.865905]  fl_reoffload+0x47c/0x510 [cls_flower]
    [ 4316.869181]  tcf_block_playback_offloads+0x91/0x1d0
    [ 4316.869649]  tcf_block_unbind+0xe7/0x1b0
    [ 4316.870049]  tcf_block_offload_cmd.isra.0+0x1ee/0x270
    [ 4316.879266]  tcf_block_offload_unbind+0x61/0xa0
    [ 4316.879711]  __tcf_block_put+0xa4/0x310
    
    Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows")
    Fixes: 1418ddd96afd ("net/mlx5e: Duplicate offloaded TC eswitch rules under uplink LAG")
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Chris Mi <cmi@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix macsec ASO context alignment [+ + +]
Author: Emeel Hakim <ehakim@nvidia.com>
Date:   Wed Feb 8 14:25:54 2023 +0200

    net/mlx5e: Fix macsec ASO context alignment
    
    [ Upstream commit 37beabe9a891b92174cd1aafbfa881fe9e05aa87 ]
    
    Currently mlx5e_macsec_umr struct does not satisfy hardware memory
    alignment requirement. Hence the result of querying advanced steering
    operation (ASO) is not copied to the memory region as expected.
    
    Fix by satisfying hardware memory alignment requirement and move
    context to be first field in struct for better readability.
    
    Fixes: 1f53da676439 ("net/mlx5e: Create advanced steering operation (ASO) object for MACsec")
    Signed-off-by: Emeel Hakim <ehakim@nvidia.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Support Geneve and GRE with VF tunnel offload [+ + +]
Author: Maor Dickman <maord@nvidia.com>
Date:   Tue Dec 20 11:21:22 2022 +0200

    net/mlx5e: Support Geneve and GRE with VF tunnel offload
    
    [ Upstream commit 521933cdc4aad133b410d8f64b03f60345021138 ]
    
    Today VF tunnel offload (tunnel endpoint is on VF) is implemented
    by indirect table which use rules that match on VXLAN VNI to
    recirculated to root table, this limit the support for only
    VXLAN tunnels.
    
    This patch change indirect table to use one single match all rule
    to recirculated to root table which is added when any tunnel decap
    rule is added with tunnel endpoint is VF. This allow support of
    Geneve and GRE with this configuration.
    
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: 1313d78ac0c1 ("net/mlx5: E-switch, Fix wrong usage of source port rewrite in split rules")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/smc: fix deadlock triggered by cancel_delayed_work_syn() [+ + +]
Author: Wenjia Zhang <wenjia@linux.ibm.com>
Date:   Mon Mar 13 11:08:28 2023 +0100

    net/smc: fix deadlock triggered by cancel_delayed_work_syn()
    
    [ Upstream commit 13085e1b5cab8ad802904d72e6a6dae85ae0cd20 ]
    
    The following LOCKDEP was detected:
                    Workqueue: events smc_lgr_free_work [smc]
                    WARNING: possible circular locking dependency detected
                    6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
                    ------------------------------------------------------
                    kworker/3:0/176251 is trying to acquire lock:
                    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},
                            at: __flush_workqueue+0x7a/0x4f0
                    but task is already holding lock:
                    0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0},
                            at: process_one_work+0x232/0x730
                    which lock already depends on the new lock.
                    the existing dependency chain (in reverse order) is:
                    -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8
                           lock_acquire.part.0+0xe2/0x248
                           lock_acquire+0xac/0x1c8
                           __flush_work+0x76/0xf0
                           __cancel_work_timer+0x170/0x220
                           __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]
                           smc_connect_rdma+0x15e/0x418 [smc]
                           __smc_connect+0x234/0x480 [smc]
                           smc_connect+0x1d6/0x230 [smc]
                           __sys_connect+0x90/0xc0
                           __do_sys_socketcall+0x186/0x370
                           __do_syscall+0x1da/0x208
                           system_call+0x82/0xb0
                    -> #3 (smc_client_lgr_pending){+.+.}-{3:3}:
                           __lock_acquire+0x58e/0xbd8
                           lock_acquire.part.0+0xe2/0x248
                           lock_acquire+0xac/0x1c8
                           __mutex_lock+0x96/0x8e8
                           mutex_lock_nested+0x32/0x40
                           smc_connect_rdma+0xa4/0x418 [smc]
                           __smc_connect+0x234/0x480 [smc]
                           smc_connect+0x1d6/0x230 [smc]
                           __sys_connect+0x90/0xc0
                           __do_sys_socketcall+0x186/0x370
                           __do_syscall+0x1da/0x208
                           system_call+0x82/0xb0
                    -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8
                           lock_acquire.part.0+0xe2/0x248
                           lock_acquire+0xac/0x1c8
                           lock_sock_nested+0x46/0xa8
                           smc_tx_work+0x34/0x50 [smc]
                           process_one_work+0x30c/0x730
                           worker_thread+0x62/0x420
                           kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58
                           ret_from_fork+0xa/0x40
                    -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8
                           lock_acquire.part.0+0xe2/0x248
                           lock_acquire+0xac/0x1c8
                           process_one_work+0x2bc/0x730
                           worker_thread+0x62/0x420
                           kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58
                           ret_from_fork+0xa/0x40
                    -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:
                           check_prev_add+0xd8/0xe88
                           validate_chain+0x70c/0xb20
                           __lock_acquire+0x58e/0xbd8
                           lock_acquire.part.0+0xe2/0x248
                           lock_acquire+0xac/0x1c8
                           __flush_workqueue+0xaa/0x4f0
                           drain_workqueue+0xaa/0x158
                           destroy_workqueue+0x44/0x2d8
                           smc_lgr_free+0x9e/0xf8 [smc]
                           process_one_work+0x30c/0x730
                           worker_thread+0x62/0x420
                           kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58
                           ret_from_fork+0xa/0x40
                    other info that might help us debug this:
                    Chain exists of:
                      (wq_completion)smc_tx_wq-00000000#2
                      --> smc_client_lgr_pending
                      --> (work_completion)(&(&lgr->free_work)->work)
                     Possible unsafe locking scenario:
                           CPU0                    CPU1
                           ----                    ----
                      lock((work_completion)(&(&lgr->free_work)->work));
                                       lock(smc_client_lgr_pending);
                                       lock((work_completion)
                                            (&(&lgr->free_work)->work));
                      lock((wq_completion)smc_tx_wq-00000000#2);
                     *** DEADLOCK ***
                    2 locks held by kworker/3:0/176251:
                     #0: 0000000080183548
                            ((wq_completion)events){+.+.}-{0:0},
                                    at: process_one_work+0x232/0x730
                     #1: 0000037fffe97dc8
                            ((work_completion)
                             (&(&lgr->free_work)->work)){+.+.}-{0:0},
                                    at: process_one_work+0x232/0x730
                    stack backtrace:
                    CPU: 3 PID: 176251 Comm: kworker/3:0 Not tainted
                    Hardware name: IBM 8561 T01 701 (z/VM 7.2.0)
                    Call Trace:
                     [<000000002983c3e4>] dump_stack_lvl+0xac/0x100
                     [<0000000028b477ae>] check_noncircular+0x13e/0x160
                     [<0000000028b48808>] check_prev_add+0xd8/0xe88
                     [<0000000028b49cc4>] validate_chain+0x70c/0xb20
                     [<0000000028b4bd26>] __lock_acquire+0x58e/0xbd8
                     [<0000000028b4cf6a>] lock_acquire.part.0+0xe2/0x248
                     [<0000000028b4d17c>] lock_acquire+0xac/0x1c8
                     [<0000000028addaaa>] __flush_workqueue+0xaa/0x4f0
                     [<0000000028addf9a>] drain_workqueue+0xaa/0x158
                     [<0000000028ae303c>] destroy_workqueue+0x44/0x2d8
                     [<000003ff8029af26>] smc_lgr_free+0x9e/0xf8 [smc]
                     [<0000000028adf3d4>] process_one_work+0x30c/0x730
                     [<0000000028adf85a>] worker_thread+0x62/0x420
                     [<0000000028aeac50>] kthread+0x138/0x150
                     [<0000000028a63914>] __ret_from_fork+0x3c/0x58
                     [<00000000298503da>] ret_from_fork+0xa/0x40
                    INFO: lockdep is turned off.
    ===================================================================
    
    This deadlock occurs because cancel_delayed_work_sync() waits for
    the work(&lgr->free_work) to finish, while the &lgr->free_work
    waits for the work(lgr->tx_wq), which needs the sk_lock-AF_SMC, that
    is already used under the mutex_lock.
    
    The solution is to use cancel_delayed_work() instead, which kills
    off a pending work.
    
    Fixes: a52bcc919b14 ("net/smc: improve termination processing")
    Signed-off-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Reviewed-by: Jan Karcher <jaka@linux.ibm.com>
    Reviewed-by: Karsten Graul <kgraul@linux.ibm.com>
    Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler() [+ + +]
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Wed Mar 8 16:17:12 2023 +0800

    net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()
    
    [ Upstream commit 22a825c541d775c1dbe7b2402786025acad6727b ]
    
    When performing a stress test on SMC-R by rmmod mlx5_ib driver
    during the wrk/nginx test, we found that there is a probability
    of triggering a panic while terminating all link groups.
    
    This issue dues to the race between smc_smcr_terminate_all()
    and smc_buf_create().
    
                            smc_smcr_terminate_all
    
    smc_buf_create
    /* init */
    conn->sndbuf_desc = NULL;
    ...
    
                            __smc_lgr_terminate
                                    smc_conn_kill
                                            smc_close_abort
                                                    smc_cdc_get_slot_and_msg_send
    
                            __softirqentry_text_start
                                    smc_wr_tx_process_cqe
                                            smc_cdc_tx_handler
                                                    READ(conn->sndbuf_desc->len);
                                                    /* panic dues to NULL sndbuf_desc */
    
    conn->sndbuf_desc = xxx;
    
    This patch tries to fix the issue by always to check the sndbuf_desc
    before send any cdc msg, to make sure that no null pointer is
    seen during cqe processing.
    
    Fixes: 0b29ec643613 ("net/smc: immediate termination for SMCR link groups")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Link: https://lore.kernel.org/r/1678263432-17329-1-git-send-email-alibuda@linux.alibaba.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: atlantic: Fix crash when XDP is enabled but no program is loaded [+ + +]
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Wed Mar 15 13:55:38 2023 +0100

    net: atlantic: Fix crash when XDP is enabled but no program is loaded
    
    [ Upstream commit 37d010399f7552add2b68e2b347901c83562dab8 ]
    
    The aq_xdp_run_prog() function falls back to the XDP_ABORTED action
    handler (using a goto) if the operations for any of the other actions fail.
    The XDP_ABORTED handler in turn calls the bpf_warn_invalid_xdp_action()
    tracepoint. However, the function also jumps into the XDP_PASS helper if no
    XDP program is loaded on the device, which means the XDP_ABORTED handler
    can be run with a NULL program pointer. This results in a NULL pointer
    deref because the tracepoint dereferences the 'prog' pointer passed to it.
    
    This situation can happen in multiple ways:
    - If a packet arrives between the removal of the program from the interface
      and the static_branch_dec() in aq_xdp_setup()
    - If there are multiple devices using the same driver in the system and
      one of them has an XDP program loaded and the other does not.
    
    Fix this by refactoring the aq_xdp_run_prog() function to remove the 'goto
    pass' handling if there is no XDP program loaded. Instead, factor out the
    skb building in a separate small helper function.
    
    Fixes: 26efaef759a1 ("net: atlantic: Implement xdp data plane")
    Reported-by: Freysteinn Alfredsson <Freysteinn.Alfredsson@kau.se>
    Tested-by: Freysteinn Alfredsson <Freysteinn.Alfredsson@kau.se>
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://lore.kernel.org/r/20230315125539.103319-1-toke@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: don't error out when drivers return ETH_DATA_LEN in .port_max_mtu() [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Mar 14 20:24:04 2023 +0200

    net: dsa: don't error out when drivers return ETH_DATA_LEN in .port_max_mtu()
    
    [ Upstream commit 636e8adf7878eab3614250234341bde45537f47a ]
    
    Currently, when dsa_slave_change_mtu() is called on a user port where
    dev->max_mtu is 1500 (as returned by ds->ops->port_max_mtu()), the code
    will stumble upon this check:
    
            if (new_master_mtu > mtu_limit)
                    return -ERANGE;
    
    because new_master_mtu is adjusted for the tagger overhead but mtu_limit
    is not.
    
    But it would be good if the logic went through, for example if the DSA
    master really depends on an MTU adjustment to accept DSA-tagged frames.
    
    To make the code pass through the check, we need to adjust mtu_limit for
    the overhead as well, if the minimum restriction was caused by the DSA
    user port's MTU (dev->max_mtu). A DSA user port MTU and a DSA master MTU
    are always offset by the protocol overhead.
    
    Currently no drivers return 1500 .port_max_mtu(), but this is only
    temporary and a bug in itself - mv88e6xxx should have done that, but
    since commit b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when
    setting MTU for DSA and CPU ports") it no longer does. This is a
    preparation for fixing that.
    
    Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: microchip: fix RGMII delay configuration on KSZ8765/KSZ8794/KSZ8795 [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Mar 16 01:19:16 2023 +0200

    net: dsa: microchip: fix RGMII delay configuration on KSZ8765/KSZ8794/KSZ8795
    
    [ Upstream commit 5ae06327a3a5bad4ee246d81df203b1b00a7b390 ]
    
    The blamed commit has replaced a ksz_write8() call to address
    REG_PORT_5_CTRL_6 (0x56) with a ksz_set_xmii() -> ksz_pwrite8() call to
    regs[P_XMII_CTRL_1], which is also defined as 0x56 for ksz8795_regs[].
    
    The trouble is that, when compared to ksz_write8(), ksz_pwrite8() also
    adjusts the register offset with the port base address. So in reality,
    ksz_pwrite8(offset=0x56) accesses register 0x56 + 0x50 = 0xa6, which in
    this switch appears to be unmapped, and the RGMII delay configuration on
    the CPU port does nothing.
    
    So if the switch wasn't fine with the RGMII delay configuration done
    through pin strapping and relied on Linux to apply a different one in
    order to pass traffic, this is now broken.
    
    Using the offset translation logic imposed by ksz_pwrite8(), the correct
    value for regs[P_XMII_CTRL_1] should have been 0x6 on ksz8795_regs[], in
    order to really end up accessing register 0x56.
    
    Static code analysis shows that, despite there being multiple other
    accesses to regs[P_XMII_CTRL_1] in this driver, the only code path that
    is applicable to ksz8795_regs[] and ksz8_dev_ops is ksz_set_xmii().
    Therefore, the problem is isolated to RGMII delays.
    
    In its current form, ksz8795_regs[] contains the same value for
    P_XMII_CTRL_0 and for P_XMII_CTRL_1, and this raises valid suspicions
    that writes made by the driver to regs[P_XMII_CTRL_0] might overwrite
    writes made to regs[P_XMII_CTRL_1] or vice versa.
    
    Again, static analysis shows that the only accesses to P_XMII_CTRL_0
    from the driver are made from code paths which are not reachable with
    ksz8_dev_ops. So the accesses made by ksz_set_xmii() are safe for this
    switch family.
    
    [ vladimiroltean: rewrote commit message ]
    
    Fixes: c476bede4b0f ("net: dsa: microchip: ksz8795: use common xmii function")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20230315231916.2998480-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mt7530: remove now incorrect comment regarding port 5 [+ + +]
Author: Arınç ÜNAL <arinc.unal@arinc9.com>
Date:   Fri Mar 10 10:33:37 2023 +0300

    net: dsa: mt7530: remove now incorrect comment regarding port 5
    
    [ Upstream commit feb03fd11c5616f3a47e4714d2f9917d0f1a2edd ]
    
    Remove now incorrect comment regarding port 5 as GMAC5. This is supposed to
    be supported since commit 38f790a80560 ("net: dsa: mt7530: Add support for
    port 5") under mt7530_setup_port5().
    
    Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5")
    Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Link: https://lore.kernel.org/r/20230310073338.5836-1-arinc.unal@arinc9.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mt7530: set PLL frequency and trgmii only when trgmii is used [+ + +]
Author: Arınç ÜNAL <arinc.unal@arinc9.com>
Date:   Fri Mar 10 10:33:38 2023 +0300

    net: dsa: mt7530: set PLL frequency and trgmii only when trgmii is used
    
    [ Upstream commit 0b086d76e7b011772b0ac214c6e5fd5816eff2df ]
    
    As my testing on the MCM MT7530 switch on MT7621 SoC shows, setting the PLL
    frequency does not affect MII modes other than trgmii on port 5 and port 6.
    So the assumption is that the operation here called "setting the PLL
    frequency" actually sets the frequency of the TRGMII TX clock.
    
    Make it so that it and the rest of the trgmii setup run only when the
    trgmii mode is used.
    
    Tested rgmii and trgmii modes of port 6 on MCM MT7530 on MT7621AT Unielec
    U7621-06 and standalone MT7530 on MT7623NI Bananapi BPI-R2.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Link: https://lore.kernel.org/r/20230310073338.5836-2-arinc.unal@arinc9.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250, 6290 [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Mar 14 20:24:05 2023 +0200

    net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250, 6290
    
    [ Upstream commit 7e9517375a14f44ee830ca1c3278076dd65fcc8f ]
    
    There are 3 classes of switch families that the driver is aware of, as
    far as mv88e6xxx_change_mtu() is concerned:
    
    - MTU configuration is available per port. Here, the
      chip->info->ops->port_set_jumbo_size() method will be present.
    
    - MTU configuration is global to the switch. Here, the
      chip->info->ops->set_max_frame_size() method will be present.
    
    - We don't know how to change the MTU. Here, none of the above methods
      will be present.
    
    Switch families MV88E6165, MV88E6191, MV88E6220, MV88E6250 and MV88E6290
    fall in category 3.
    
    The blamed commit has adjusted the MTU for all 3 categories by EDSA_HLEN
    (8 bytes), resulting in a new maximum MTU of 1492 being reported by the
    driver for these switches.
    
    I don't have the hardware to test, but I do have a MV88E6390 switch on
    which I can simulate this by commenting out its .port_set_jumbo_size
    definition from mv88e6390_ops. The result is this set of messages at
    probe time:
    
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 1
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 2
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 3
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 4
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 5
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 6
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 7
    mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 8
    
    It is highly implausible that there exist Ethernet switches which don't
    support the standard MTU of 1500 octets, and this is what the DSA
    framework says as well - the error comes from dsa_slave_create() ->
    dsa_slave_change_mtu(slave_dev, ETH_DATA_LEN).
    
    But the error messages are alarming, and it would be good to suppress
    them.
    
    As a consequence of this unlikeliness, we reimplement mv88e6xxx_get_max_mtu()
    and mv88e6xxx_change_mtu() on switches from the 3rd category as follows:
    the maximum supported MTU is 1500, and any request to set the MTU to a
    value larger than that fails in dev_validate_mtu().
    
    Fixes: b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: nxp-c45-tja11xx: fix MII_BASIC_CONFIG_REV bit [+ + +]
Author: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com>
Date:   Thu Mar 9 12:01:11 2023 +0200

    net: phy: nxp-c45-tja11xx: fix MII_BASIC_CONFIG_REV bit
    
    commit 8ba572052a4b8fe5b205854d27e54e3486049b71 upstream.
    
    According to the TJA1103 user manual, the bit for the reversed role in MII
    or RMII modes is bit 4.
    
    Cc: <stable@vger.kernel.org> # 5.15+
    Fixes: b050f2f15e04 ("phy: nxp-c45: add driver for tja1103")
    Signed-off-by: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com>
    Link: https://lore.kernel.org/r/20230309100111.1246214-1-radu-nicolae.pirea@oss.nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: phy: smsc: bail out in lan87xx_read_status if genphy_read_status fails [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Mar 11 19:34:45 2023 +0100

    net: phy: smsc: bail out in lan87xx_read_status if genphy_read_status fails
    
    [ Upstream commit c22c3bbf351e4ce905f082649cffa1ff893ea8c1 ]
    
    If genphy_read_status fails then further access to the PHY may result
    in unpredictable behavior. To prevent this bail out immediately if
    genphy_read_status fails.
    
    Fixes: 4223dbffed9f ("net: phy: smsc: Re-enable EDPD mode for LAN87xx")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/026aa4f2-36f5-1c10-ab9f-cdb17dda6ac4@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tunnels: annotate lockless accesses to dev->needed_headroom [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 10 19:11:09 2023 +0000

    net: tunnels: annotate lockless accesses to dev->needed_headroom
    
    [ Upstream commit 4b397c06cb987935b1b097336532aa6b4210e091 ]
    
    IP tunnels can apparently update dev->needed_headroom
    in their xmit path.
    
    This patch takes care of three tunnels xmit, and also the
    core LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()
    helpers.
    
    More changes might be needed for completeness.
    
    BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit
    
    read to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:
    ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    
    write to 0xffff88815b9da0ec of 2 bytes by task 2379 on cpu 0:
    ip_tunnel_xmit+0x1294/0x1730 net/ipv4/ip_tunnel.c:804
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip6_finish_output2+0x9bc/0xc50 net/ipv6/ip6_output.c:134
    __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
    ip6_finish_output+0x39a/0x4e0 net/ipv6/ip6_output.c:206
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip6_output+0xeb/0x220 net/ipv6/ip6_output.c:227
    dst_output include/net/dst.h:444 [inline]
    NF_HOOK include/linux/netfilter.h:302 [inline]
    mld_sendpack+0x438/0x6a0 net/ipv6/mcast.c:1820
    mld_send_cr net/ipv6/mcast.c:2121 [inline]
    mld_ifc_work+0x519/0x7b0 net/ipv6/mcast.c:2653
    process_one_work+0x3e6/0x750 kernel/workqueue.c:2390
    worker_thread+0x5f2/0xa10 kernel/workqueue.c:2537
    kthread+0x1ac/0x1e0 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
    
    value changed: 0x0dd4 -> 0x0e14
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 2379 Comm: kworker/0:0 Not tainted 6.3.0-rc1-syzkaller-00002-g8ca09d5fa354-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
    Workqueue: mld mld_ifc_work
    
    Fixes: 8eb30be0352d ("ipv6: Create ip6_tnl_xmit")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230310191109.2384387-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: smsc75xx: Limit packet length to skb->len [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Mon Mar 13 23:00:45 2023 +0100

    net: usb: smsc75xx: Limit packet length to skb->len
    
    [ Upstream commit d8b228318935044dafe3a5bc07ee71a1f1424b8d ]
    
    Packet length retrieved from skb data may be larger than
    the actual socket buffer length (up to 9026 bytes). In such
    case the cloned skb passed up the network stack will leak
    kernel memory contents.
    
    Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Thu Mar 16 12:05:40 2023 +0100

    net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull
    
    [ Upstream commit 43ffe6caccc7a1bb9d7442fbab521efbf6c1378c ]
    
    Packet length check needs to be located after size and align_count
    calculation to prevent kernel panic in skb_pull() in case
    rx_cmd_a & RX_CMD_A_RED evaluates to true.
    
    Fixes: d8b228318935 ("net: usb: smsc75xx: Limit packet length to skb->len")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Link: https://lore.kernel.org/r/20230316110540.77531-1-szymon.heidrich@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nft_masq: correct length for loading protocol registers [+ + +]
Author: Jeremy Sowden <jeremy@azazel.net>
Date:   Tue Mar 7 23:22:57 2023 +0000

    netfilter: nft_masq: correct length for loading protocol registers
    
    [ Upstream commit ec2c5917eb858428b2083d1c74f445aabbe8316b ]
    
    The values in the protocol registers are two bytes wide.  However, when
    parsing the register loads, the code currently uses the larger 16-byte
    size of a `union nf_inet_addr`.  Change it to use the (correct) size of
    a `union nf_conntrack_man_proto` instead.
    
    Fixes: 8a6bf5da1aef ("netfilter: nft_masq: support port range")
    Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_nat: correct length for loading protocol registers [+ + +]
Author: Jeremy Sowden <jeremy@azazel.net>
Date:   Tue Mar 7 23:22:56 2023 +0000

    netfilter: nft_nat: correct length for loading protocol registers
    
    [ Upstream commit 068d82e75d537b444303b8c449a11e51ea659565 ]
    
    The values in the protocol registers are two bytes wide.  However, when
    parsing the register loads, the code currently uses the larger 16-byte
    size of a `union nf_inet_addr`.  Change it to use the (correct) size of
    a `union nf_conntrack_man_proto` instead.
    
    Fixes: d07db9884a5f ("netfilter: nf_tables: introduce nft_validate_register_load()")
    Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_redir: correct length for loading protocol registers [+ + +]
Author: Jeremy Sowden <jeremy@azazel.net>
Date:   Tue Mar 7 23:22:58 2023 +0000

    netfilter: nft_redir: correct length for loading protocol registers
    
    [ Upstream commit 1f617b6b4c7a3d5ea7a56abb83a4c27733b60c2f ]
    
    The values in the protocol registers are two bytes wide.  However, when
    parsing the register loads, the code currently uses the larger 16-byte
    size of a `union nf_inet_addr`.  Change it to use the (correct) size of
    a `union nf_conntrack_man_proto` instead.
    
    Fixes: d07db9884a5f ("netfilter: nf_tables: introduce nft_validate_register_load()")
    Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_redir: correct value of inet type `.maxattrs` [+ + +]
Author: Jeremy Sowden <jeremy@azazel.net>
Date:   Tue Mar 7 23:22:59 2023 +0000

    netfilter: nft_redir: correct value of inet type `.maxattrs`
    
    [ Upstream commit 493924519b1fe3faab13ee621a43b0d0939abab1 ]
    
    `nft_redir_inet_type.maxattrs` was being set, presumably because of a
    cut-and-paste error, to `NFTA_MASQ_MAX`, instead of `NFTA_REDIR_MAX`.
    
    Fixes: 63ce3940f3ab ("netfilter: nft_redir: add inet support")
    Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: pn533: initialize struct pn533_out_arg properly [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Thu Mar 9 19:50:50 2023 +0300

    nfc: pn533: initialize struct pn533_out_arg properly
    
    [ Upstream commit 484b7059796e3bc1cb527caa61dfc60da649b4f6 ]
    
    struct pn533_out_arg used as a temporary context for out_urb is not
    initialized properly. Its uninitialized 'phy' field can be dereferenced in
    error cases inside pn533_out_complete() callback function. It causes the
    following failure:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441
    Call Trace:
     <IRQ>
     __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671
     usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754
     dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988
     call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700
     expire_timers+0x234/0x330 kernel/time/timer.c:1751
     __run_timers kernel/time/timer.c:2022 [inline]
     __run_timers kernel/time/timer.c:1995 [inline]
     run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035
     __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571
     invoke_softirq kernel/softirq.c:445 [inline]
     __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
     irq_exit_rcu+0x9/0x20 kernel/softirq.c:662
     sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107
    
    Initialize the field with the pn533_usb_phy currently used.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 9dab880d675b ("nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()")
    Reported-by: syzbot+1e608ba4217c96d1952f@syzkaller.appspotmail.com
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230309165050.207390-1-pchelkin@ispras.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Mon Mar 13 00:08:37 2023 +0800

    nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition
    
    [ Upstream commit 5000fe6c27827a61d8250a7e4a1d26c3298ef4f6 ]
    
    This bug influences both st_nci_i2c_remove and st_nci_spi_remove.
    Take st_nci_i2c_remove as an example.
    
    In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work
    with llt_ndlc_sm_work.
    
    When it calls ndlc_recv or timeout handler, it will finally call
    schedule_work to start the work.
    
    When we call st_nci_i2c_remove to remove the driver, there
    may be a sequence as follows:
    
    Fix it by finishing the work before cleanup in ndlc_remove
    
    CPU0                  CPU1
    
                        |llt_ndlc_sm_work
    st_nci_i2c_remove   |
      ndlc_remove       |
         st_nci_remove  |
         nci_free_device|
         kfree(ndev)    |
    //free ndlc->ndev   |
                        |llt_ndlc_rcv_queue
                        |nci_recv_frame
                        |//use ndlc->ndev
    
    Fixes: 35630df68d60 ("NFC: st21nfcb: Add driver for STMicroelectronics ST21NFCB NFC chip")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230312160837.2040857-1-zyytlz.wz@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-pci: add NVME_QUIRK_BOGUS_NID for Netac NV3000 [+ + +]
Author: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
Date:   Wed Mar 8 19:19:29 2023 +0300

    nvme-pci: add NVME_QUIRK_BOGUS_NID for Netac NV3000
    
    commit 9630d80655bfe7e62e4aff2889dc4eae7ceeb887 upstream.
    
    Added a quirk to fix the Netac NV3000 SSD reporting duplicate NGUIDs.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvme: fix handling single range discard request [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Mar 4 07:13:45 2023 +0800

    nvme: fix handling single range discard request
    
    [ Upstream commit 37f0dc2ec78af0c3f35dd05578763de059f6fe77 ]
    
    When investigating one customer report on warning in nvme_setup_discard,
    we observed the controller(nvme/tcp) actually exposes
    queue_max_discard_segments(req->q) == 1.
    
    Obviously the current code can't handle this situation, since contiguity
    merge like normal RW request is taken.
    
    Fix the issue by building range from request sector/nr_sectors directly.
    
    Fixes: b35ba01ea697 ("nvme: support ranged discard requests")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet: avoid potential UAF in nvmet_req_complete() [+ + +]
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Mon Mar 6 10:13:13 2023 +0900

    nvmet: avoid potential UAF in nvmet_req_complete()
    
    [ Upstream commit 6173a77b7e9d3e202bdb9897b23f2a8afe7bf286 ]
    
    An nvme target ->queue_response() operation implementation may free the
    request passed as argument. Such implementation potentially could result
    in a use after free of the request pointer when percpu_ref_put() is
    called in nvmet_req_complete().
    
    Avoid such problem by using a local variable to save the sq pointer
    before calling __nvmet_req_complete(), thus avoiding dereferencing the
    req pointer after that function call.
    
    Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ocfs2: fix data corruption after failed write [+ + +]
Author: Jan Kara via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
Date:   Thu Mar 2 16:38:43 2023 +0100

    ocfs2: fix data corruption after failed write
    
    commit 90410bcf873cf05f54a32183afff0161f44f9715 upstream.
    
    When buffered write fails to copy data into underlying page cache page,
    ocfs2_write_end_nolock() just zeroes out and dirties the page.  This can
    leave dirty page beyond EOF and if page writeback tries to write this page
    before write succeeds and expands i_size, page gets into inconsistent
    state where page dirty bit is clear but buffer dirty bits stay set
    resulting in page data never getting written and so data copied to the
    page is lost.  Fix the problem by invalidating page beyond EOF after
    failed write.
    
    Link: https://lkml.kernel.org/r/20230302153843.18499-1-jack@suse.cz
    Fixes: 6dbf7bb55598 ("fs: Don't invalidate page buffers in block_write_full_page()")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: s390: Fix use-after-free of PCI resources with per-function hotplug [+ + +]
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Mon Mar 6 16:10:11 2023 +0100

    PCI: s390: Fix use-after-free of PCI resources with per-function hotplug
    
    [ Upstream commit ab909509850b27fd39b8ba99e44cda39dbc3858c ]
    
    On s390 PCI functions may be hotplugged individually even when they
    belong to a multi-function device. In particular on an SR-IOV device VFs
    may be removed and later re-added.
    
    In commit a50297cf8235 ("s390/pci: separate zbus creation from
    scanning") it was missed however that struct pci_bus and struct
    zpci_bus's resource list retained a reference to the PCI functions MMIO
    resources even though those resources are released and freed on
    hot-unplug. These stale resources may subsequently be claimed when the
    PCI function re-appears resulting in use-after-free.
    
    One idea of fixing this use-after-free in s390 specific code that was
    investigated was to simply keep resources around from the moment a PCI
    function first appeared until the whole virtual PCI bus created for
    a multi-function device disappears. The problem with this however is
    that due to the requirement of artificial MMIO addreesses (address
    cookies) extra logic is then needed to keep the address cookies
    compatible on re-plug. At the same time the MMIO resources semantically
    belong to the PCI function so tying their lifecycle to the function
    seems more logical.
    
    Instead a simpler approach is to remove the resources of an individually
    hot-unplugged PCI function from the PCI bus's resource list while
    keeping the resources of other PCI functions on the PCI bus untouched.
    
    This is done by introducing pci_bus_remove_resource() to remove an
    individual resource. Similarly the resource also needs to be removed
    from the struct zpci_bus's resource list. It turns out however, that
    there is really no need to add the MMIO resources to the struct
    zpci_bus's resource list at all and instead we can simply use the
    zpci_bar_struct's resource pointer directly.
    
    Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning")
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://lore.kernel.org/r/20230306151014.60913-2-schnelle@linux.ibm.com
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf: Fix check before add_event_to_groups() in perf_group_detach() [+ + +]
Author: Budimir Markovic <markovicbudimir@gmail.com>
Date:   Wed Mar 15 00:29:01 2023 -0700

    perf: Fix check before add_event_to_groups() in perf_group_detach()
    
    commit fd0815f632c24878e325821943edccc7fde947a2 upstream.
    
    Events should only be added to a groups rb tree if they have not been
    removed from their context by list_del_event(). Since remove_on_exec
    made it possible to call list_del_event() on individual events before
    they are detached from their group, perf_group_detach() should check each
    sibling's attach_state before calling add_event_to_groups() on it.
    
    Fixes: 2e498d0a74e5 ("perf: Add support for event removal on exec")
    Signed-off-by: Budimir Markovic <markovicbudimir@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/ZBFzvQV9tEqoHEtH@gentoo
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/64: Replace -mcpu=e500mc64 by -mcpu=e5500 [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 19 19:45:58 2022 +0100

    powerpc/64: Replace -mcpu=e500mc64 by -mcpu=e5500
    
    commit 77e82fa1f9781a958a6ea4aed7aec41239a5a22f upstream.
    
    E500MC64 is a processor pre-dating E5500 that has never been
    commercialised. Use -mcpu=e5500 for E5500 core.
    
    More details at https://gcc.gnu.org/PR108149
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Acked-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/fa71ed20d22c156225436374f0ab847daac893bc.1671475543.git.christophe.leroy@csgroup.eu
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/64: Set default CPU in Kconfig [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Jan 25 08:38:59 2023 +0100

    powerpc/64: Set default CPU in Kconfig
    
    commit 45f7091aac3546ef8112bf62836650ca0bbf0b79 upstream.
    
    Since commit 0069f3d14e7a ("powerpc/64e: Tie PPC_BOOK3E_64 to
    PPC_E500MC"), the only possible BOOK3E/64 are E500, so no need of a
    default CPU over the E5500.
    
    When the user selects book3e, they must have an e500 compatible
    compiler, and it won't work anymore with the default -mcpu=power64, see
    commit d6b551b8f90c ("powerpc/64e: Fix build failure with GCC
    12 (unrecognized opcode: `wrteei')").
    
    For book3s/64, replace GENERIC_CPU by POWERPC64_CPU to match the PPC32
    POWERPC_CPU, and set a default mpcu value in Kconfig directly.
    
    When a user selects a particular CPU, they must ensure the compiler has
    the requested capability. Therefore, remove hidden fallback, instead
    offer user the possibility to say they want to use the toolchain
    default.
    
    Fixes: d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')")
    Reported-by: Pali Rohár <pali@kernel.org>
    Tested-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/76c11197b058193dcb8e8b26adffba09cfbdab11.1674632329.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Wed Jan 25 08:39:00 2023 +0100

    powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage
    
    commit ff7c76f66d8bad4e694c264c789249e1d3a8205d upstream.
    
    When CONFIG_TARGET_CPU is specified then pass its value to the compiler
    -mcpu option. This fixes following build error when building kernel with
    powerpc e500 SPE capable cross compilers:
    
        BOOTAS  arch/powerpc/boot/crt0.o
      powerpc-linux-gnuspe-gcc: error: unrecognized argument in option ‘-mcpu=powerpc’
      powerpc-linux-gnuspe-gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548 native
      make[1]: *** [arch/powerpc/boot/Makefile:231: arch/powerpc/boot/crt0.o] Error 1
    
    Similar change was already introduced for the main powerpc Makefile in
    commit 446cda1b21d9 ("powerpc/32: Don't always pass -mcpu=powerpc to the
    compiler").
    
    Fixes: 40a75584e526 ("powerpc/boot: Build wrapper for an appropriate CPU")
    Cc: stable@vger.kernel.org # v5.19+
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/2ae3ae5887babfdacc34435bff0944b3f336100a.1674632329.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/mm: Fix false detection of read faults [+ + +]
Author: Russell Currey <ruscur@russell.cc>
Date:   Fri Mar 10 16:08:34 2023 +1100

    powerpc/mm: Fix false detection of read faults
    
    [ Upstream commit f2c7e3562b4c4f1699acc1538ebf3e75f5cced35 ]
    
    To support detection of read faults with Radix execute-only memory, the
    vma_is_accessible() check in access_error() (which checks for PROT_NONE)
    was replaced with a check to see if VM_READ was missing, and if so,
    returns true to assert the fault was caused by a bad read.
    
    This is incorrect, as it ignores that both VM_WRITE and VM_EXEC imply
    read on powerpc, as defined in protection_map[].  This causes mappings
    containing VM_WRITE or VM_EXEC without VM_READ to misreport the cause of
    page faults, since the MMU is still allowing reads.
    
    Correct this by restoring the original vma_is_accessible() check for
    PROT_NONE mappings, and adding a separate check for Radix PROT_EXEC-only
    mappings.
    
    Fixes: 395cac7752b9 ("powerpc/mm: Support execute-only memory on the Radix MMU")
    Reported-by: Michal Suchánek <msuchanek@suse.de>
    Link: https://lore.kernel.org/r/20230308152702.GR19419@kitsune.suse.cz
    Tested-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230310050834.63105-1-ruscur@russell.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: Disable CPU unknown by CLANG when CC_IS_CLANG [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Feb 2 12:01:04 2023 +0100

    powerpc: Disable CPU unknown by CLANG when CC_IS_CLANG
    
    commit 4b10306e98456aed03cad75ce467e8b1efdccca0 upstream.
    
    CLANG only knows the following CPUs:
    
    generic, 440, 450, 601, 602, 603, 603e, 603ev, 604, 604e, 620, 630,
    g3, 7400, g4, 7450, g4+, 750, 8548, 970, g5, a2, e500, e500mc, e5500,
    power3, pwr3, power4, pwr4, power5, pwr5, power5x, pwr5x, power6,
    pwr6, power6x, pwr6x, power7, pwr7, power8, pwr8, power9, pwr9,
    power10, pwr10, powerpc, ppc, ppc32, powerpc64, ppc64, powerpc64le,
    ppc64le, futur
    
    Disable other ones when CC_IS_CLANG.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/e62892e32c14a7a5738c597e39e0082cb0abf21c.1675335659.git.christophe.leroy@csgroup.eu
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc: Pass correct CPU reference to assembler [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 19 19:45:57 2022 +0100

    powerpc: Pass correct CPU reference to assembler
    
    commit bfb03af71a3798b5a88a945a9c19ad67e1c4986d upstream.
    
    Jan-Benedict reported issue with building ppc64e_defconfig
    with mainline GCC work:
    
      powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -Wa,-me500 -Wa,-me500mc -mabi=elfv1 -mbig-endian    -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S
            arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages:
            arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `stdu'
            arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `stdu'
            arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `std'
            arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `std'
            arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `ld'
            arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `ld'
            ...
            make[1]: *** [arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/gettimeofday-64.o] Error 1
            make: *** [arch/powerpc/Makefile:387: vdso_prepare] Error 2
    
    This is due to assembler being called with -me500mc which is
    a 32 bits target.
    
    The problem comes from the fact that CONFIG_PPC_E500MC is selected for
    both the e500mc (32 bits) and the e5500 (64 bits), and therefore the
    following makefile rule is wrong:
    
      cpu-as-$(CONFIG_PPC_E500MC)    += $(call as-option,-Wa$(comma)-me500mc)
    
    Today we have CONFIG_TARGET_CPU which provides the identification of the
    expected CPU, it is used for GCC. Once GCC knows the target CPU, it adds
    the correct CPU option to assembler, no need to add it explicitly.
    
    With that change (And also commit 45f7091aac35 ("powerpc/64: Set default
    CPU in Kconfig")), it now is:
    
      powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -mcpu=e500mc64 -mabi=elfv1 -mbig-endian    -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S
    
    Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Acked-by: Pali Rohár <pali@kernel.org>
    [mpe: Retain -Wa,-mpower4 -Wa,-many for Book3S 64 builds for now]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/758ad54128fa9dd2fdedc4c511592111cbded900.1671475543.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
qed/qed_dev: guard against a possible division by zero [+ + +]
Author: Daniil Tatianin <d-tatianin@yandex-team.ru>
Date:   Thu Mar 9 23:15:56 2023 +0300

    qed/qed_dev: guard against a possible division by zero
    
    [ Upstream commit 1a9dc5610ef89d807acdcfbff93a558f341a44da ]
    
    Previously we would divide total_left_rate by zero if num_vports
    happened to be 1 because non_requested_count is calculated as
    num_vports - req_count. Guard against this by validating num_vports at
    the beginning and returning an error otherwise.
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE
    static analysis tool.
    
    Fixes: bcd197c81f63 ("qed: Add vport WFQ configuration APIs")
    Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230309201556.191392-1-d-tatianin@yandex-team.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
qed/qed_mng_tlv: correctly zero out ->min instead of ->hour [+ + +]
Author: Daniil Tatianin <d-tatianin@yandex-team.ru>
Date:   Wed Mar 15 22:46:18 2023 +0300

    qed/qed_mng_tlv: correctly zero out ->min instead of ->hour
    
    [ Upstream commit 470efd68a4653d9819d391489886432cd31bcd0b ]
    
    This fixes an issue where ->hour would erroneously get zeroed out
    instead of ->min because of a bad copy paste.
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE
    static analysis tool.
    
    Fixes: f240b6882211 ("qed: Add support for processing fcoe tlv request.")
    Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
    Link: https://lore.kernel.org/r/20230315194618.579286-1-d-tatianin@yandex-team.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ravb: avoid PHY being resumed when interface is not up [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Mar 15 08:41:14 2023 +0100

    ravb: avoid PHY being resumed when interface is not up
    
    [ Upstream commit 7f5ebf5dae42e710162f1c481ebcf28ab7b741c7 ]
    
    RAVB doesn't need mdiobus suspend/resume, that's why it sets
    'mac_managed_pm'. However, setting it needs to be moved from init to
    probe, so mdiobus PM functions will really never be called (e.g. when
    the interface is not up yet during suspend/resume).
    
    Fixes: 4924c0cdce75 ("net: ravb: Fix PHY state warning splat during system resume")
    Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "riscv: mm: notify remote harts about mmu cache updates" [+ + +]
Author: Sergey Matyukevich <sergey.matyukevich@syntacore.com>
Date:   Sun Feb 26 18:01:36 2023 +0300

    Revert "riscv: mm: notify remote harts about mmu cache updates"
    
    commit e921050022f1f12d5029d1487a7dfc46cde15523 upstream.
    
    This reverts the remaining bits of commit 4bd1d80efb5a ("riscv: mm:
    notify remote harts harts about mmu cache updates").
    
    According to bug reports, suggested approach to fix stale TLB entries
    is not sufficient. It needs to be replaced by a more robust solution.
    
    Fixes: 4bd1d80efb5a ("riscv: mm: notify remote harts about mmu cache updates")
    Reported-by: Zong Li <zong.li@sifive.com>
    Reported-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Signed-off-by: Sergey Matyukevich <sergey.matyukevich@syntacore.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Link: https://lore.kernel.org/r/20230226150137.1919750-2-geomatsi@gmail.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "tty: serial: fsl_lpuart: adjust SERIAL_FSL_LPUART_CONSOLE config dependency" [+ + +]
Author: Tom Rix <trix@redhat.com>
Date:   Sun Feb 26 12:38:46 2023 -0500

    Revert "tty: serial: fsl_lpuart: adjust SERIAL_FSL_LPUART_CONSOLE config dependency"
    
    commit 2d638be71155b2e036aca1966b6129e2d661e91f upstream.
    
    This reverts commit 5779a072c248db7a40cfd0f5ea958097fd1d9a30.
    
    This results in a link error of
    
    ld: drivers/tty/serial/earlycon.o: in function `parse_options':
    drivers/tty/serial/earlycon.c:99: undefined reference to `uart_parse_earlycon'
    
    When the config is in this state
    
    CONFIG_SERIAL_CORE=m
    CONFIG_SERIAL_CORE_CONSOLE=y
    CONFIG_SERIAL_EARLYCON=y
    CONFIG_SERIAL_FSL_LPUART=m
    CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
    
    Fixes: 5779a072c248 ("tty: serial: fsl_lpuart: adjust SERIAL_FSL_LPUART_CONSOLE config dependency")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20230226173846.236691-1-trix@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: asid: Fixup stale TLB entry cause application crash [+ + +]
Author: Guo Ren <guoren@kernel.org>
Date:   Sun Feb 26 18:01:37 2023 +0300

    riscv: asid: Fixup stale TLB entry cause application crash
    
    commit 82dd33fde0268cc622d3d1ac64971f3f61634142 upstream.
    
    After use_asid_allocator is enabled, the userspace application will
    crash by stale TLB entries. Because only using cpumask_clear_cpu without
    local_flush_tlb_all couldn't guarantee CPU's TLB entries were fresh.
    Then set_mm_asid would cause the user space application to get a stale
    value by stale TLB entry, but set_mm_noasid is okay.
    
    Here is the symptom of the bug:
    unhandled signal 11 code 0x1 (coredump)
       0x0000003fd6d22524 <+4>:     auipc   s0,0x70
       0x0000003fd6d22528 <+8>:     ld      s0,-148(s0) # 0x3fd6d92490
    => 0x0000003fd6d2252c <+12>:    ld      a5,0(s0)
    (gdb) i r s0
    s0          0x8082ed1cc3198b21       0x8082ed1cc3198b21
    (gdb) x /2x 0x3fd6d92490
    0x3fd6d92490:   0xd80ac8a8      0x0000003f
    The core dump file shows that register s0 is wrong, but the value in
    memory is correct. Because 'ld s0, -148(s0)' used a stale mapping entry
    in TLB and got a wrong result from an incorrect physical address.
    
    When the task ran on CPU0, which loaded/speculative-loaded the value of
    address(0x3fd6d92490), then the first version of the mapping entry was
    PTWed into CPU0's TLB.
    When the task switched from CPU0 to CPU1 (No local_tlb_flush_all here by
    asid), it happened to write a value on the address (0x3fd6d92490). It
    caused do_page_fault -> wp_page_copy -> ptep_clear_flush ->
    ptep_get_and_clear & flush_tlb_page.
    The flush_tlb_page used mm_cpumask(mm) to determine which CPUs need TLB
    flush, but CPU0 had cleared the CPU0's mm_cpumask in the previous
    switch_mm. So we only flushed the CPU1 TLB and set the second version
    mapping of the PTE. When the task switched from CPU1 to CPU0 again, CPU0
    still used a stale TLB mapping entry which contained a wrong target
    physical address. It raised a bug when the task happened to read that
    value.
    
       CPU0                               CPU1
       - switch 'task' in
       - read addr (Fill stale mapping
         entry into TLB)
       - switch 'task' out (no tlb_flush)
                                          - switch 'task' in (no tlb_flush)
                                          - write addr cause pagefault
                                            do_page_fault() (change to
                                            new addr mapping)
                                              wp_page_copy()
                                                ptep_clear_flush()
                                                  ptep_get_and_clear()
                                                  & flush_tlb_page()
                                            write new value into addr
                                          - switch 'task' out (no tlb_flush)
       - switch 'task' in (no tlb_flush)
       - read addr again (Use stale
         mapping entry in TLB)
         get wrong value from old phyical
         addr, BUG!
    
    The solution is to keep all CPUs' footmarks of cpumask(mm) in switch_mm,
    which could guarantee to invalidate all stale TLB entries during TLB
    flush.
    
    Fixes: 65d4b9c53017 ("RISC-V: Implement ASID allocator")
    Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
    Signed-off-by: Guo Ren <guoren@kernel.org>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Tested-by: Zong Li <zong.li@sifive.com>
    Tested-by: Sergey Matyukevich <sergey.matyukevich@syntacore.com>
    Cc: Anup Patel <apatel@ventanamicro.com>
    Cc: Palmer Dabbelt <palmer@rivosinc.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Link: https://lore.kernel.org/r/20230226150137.1919750-3-geomatsi@gmail.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rust: arch/um: Disable FP/SIMD instruction to match x86 [+ + +]
Author: David Gow <davidgow@google.com>
Date:   Sat Dec 17 12:44:35 2022 +0800

    rust: arch/um: Disable FP/SIMD instruction to match x86
    
    [ Upstream commit 8849818679478933dd1d9718741f4daa3f4e8b86 ]
    
    The kernel disables all SSE and similar FP/SIMD instructions on
    x86-based architectures (partly because we shouldn't be using floats in
    the kernel, and partly to avoid the need for stack alignment, see:
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 )
    
    UML does not do the same thing, which isn't in itself a problem, but
    does add to the list of differences between UML and "normal" x86 builds.
    
    In addition, there was a crash bug with LLVM < 15 / rustc < 1.65 when
    building with SSE, so disabling it fixes rust builds with earlier
    compiler versions, see:
    https://github.com/Rust-for-Linux/linux/pull/881
    
    Signed-off-by: David Gow <davidgow@google.com>
    Reviewed-by: Sergio González Collado <sergio.collado@gmail.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/ipl: add missing intersection check to ipl_report handling [+ + +]
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Tue Mar 7 14:35:23 2023 +0100

    s390/ipl: add missing intersection check to ipl_report handling
    
    commit a52e5cdbe8016d4e3e6322fd93d71afddb9a5af9 upstream.
    
    The code which handles the ipl report is searching for a free location
    in memory where it could copy the component and certificate entries to.
    It checks for intersection between the sections required for the kernel
    and the component/certificate data area, but fails to check whether
    the data structures linking these data areas together intersect.
    
    This might cause the iplreport copy code to overwrite the iplreport
    itself. Fix this by adding two addtional intersection checks.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 9641b8cc733f ("s390/ipl: read IPL report at early boot")
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scsi: core: Add BLIST_NO_VPD_SIZE for some VDASD [+ + +]
Author: Lee Duncan <lduncan@suse.com>
Date:   Wed Sep 28 11:13:50 2022 -0700

    scsi: core: Add BLIST_NO_VPD_SIZE for some VDASD
    
    [ Upstream commit 4b1a2c2a8e0ddcb89c5f6c5003bd9b53142f69e3 ]
    
    Some storage, such as AIX VDASD (virtual storage) and IBM 2076 (front
    end), fail as a result of commit c92a6b5d6335 ("scsi: core: Query VPD
    size before getting full page").
    
    That commit changed getting SCSI VPD pages so that we now read just
    enough of the page to get the actual page size, then read the whole
    page in a second read. The problem is that the above mentioned
    hardware returns zero for the page size, because of a firmware
    error. In such cases, until the firmware is fixed, this new blacklist
    flag says to revert to the original method of reading the VPD pages,
    i.e. try to read a whole buffer's worth on the first try.
    
    [mkp: reworked somewhat]
    
    Fixes: c92a6b5d6335 ("scsi: core: Query VPD size before getting full page")
    Reported-by: Martin Wilck <mwilck@suse.com>
    Suggested-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Lee Duncan <lduncan@suse.com>
    Link: https://lore.kernel.org/r/20220928181350.9948-1-leeman.duncan@gmail.com
    Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: core: Fix a procfs host directory removal regression [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Mar 7 13:44:28 2023 -0800

    scsi: core: Fix a procfs host directory removal regression
    
    [ Upstream commit be03df3d4bfe7e8866d4aa43d62e648ffe884f5f ]
    
    scsi_proc_hostdir_rm() decreases a reference counter and hence must only be
    called once per host that is removed. This change does not require a
    scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return
    0 (success) if scsi_proc_host_add() is called.
    
    Fixes: fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier")
    Cc: John Garry <john.g.garry@oracle.com>
    Reported-by: John Garry <john.g.garry@oracle.com>
    Link: https://lore.kernel.org/all/ed6b8027-a9d9-1b45-be8e-df4e8c6c4605@oracle.com/
    Reported-by: syzbot+645a4616b87a2f10e398@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-scsi/000000000000890fab05f65342b6@google.com/
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20230307214428.3703498-1-bvanassche@acm.org
    Tested-by: John Garry <john.g.garry@oracle.com>
    Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Fix config page DMA memory leak [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Mar 3 00:43:32 2023 +0100

    scsi: mpi3mr: Fix config page DMA memory leak
    
    [ Upstream commit 7d2b02172b6a2ae6aecd7ef6480b9c4bf3dc59f4 ]
    
    A fix for:
    
    DMA-API: pci 0000:83:00.0: device driver has pending DMA allocations while released from device [count=1]
    
    Fixes: 32d457d5a2af ("scsi: mpi3mr: Add framework to issue config requests")
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20230302234336.25456-3-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Fix expander node leak in mpi3mr_remove() [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Mar 3 00:43:36 2023 +0100

    scsi: mpi3mr: Fix expander node leak in mpi3mr_remove()
    
    [ Upstream commit ce756daa36e1ba271bb3334267295e447aa57a5c ]
    
    Add a missing resource clean up in .remove.
    
    Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL")
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20230302234336.25456-7-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc() [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Mar 3 00:43:35 2023 +0100

    scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc()
    
    [ Upstream commit c798304470cab88723d895726d17fcb96472e0e9 ]
    
    Don't allocate memory again when IOC is being reinitialized.
    
    Fixes: fe6db6151565 ("scsi: mpi3mr: Handle offline FW activation in graceful manner")
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20230302234336.25456-6-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove() [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Mar 3 00:43:33 2023 +0100

    scsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove()
    
    [ Upstream commit d0f3c3728da8af76dfe435f7f0cfa2b9d9e43ef0 ]
    
    Free mpi3mr_hba_port at .remove.
    
    Fixes: 42fc9fee116f ("scsi: mpi3mr: Add helper functions to manage device's port")
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20230302234336.25456-4-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove() [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Mar 3 00:43:34 2023 +0100

    scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()
    
    [ Upstream commit d4caa1a4255cc44be56bcab3db2c97c632e6cc10 ]
    
    Free mrioc->sas_hba.phy at .remove.
    
    Fixes: 42fc9fee116f ("scsi: mpi3mr: Add helper functions to manage device's port")
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20230302234336.25456-5-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Fix throttle_groups memory leak [+ + +]
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Mar 3 00:43:31 2023 +0100

    scsi: mpi3mr: Fix throttle_groups memory leak
    
    [ Upstream commit f305a7b6ca21a665e8d0cf70b5936991a298c93c ]
    
    Add a missing kfree().
    
    Fixes: f10af057325c ("scsi: mpi3mr: Resource Based Metering")
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Link: https://lore.kernel.org/r/20230302234336.25456-2-thenzl@redhat.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: ioctl timeout when disabling/enabling interrupt [+ + +]
Author: Ranjan Kumar <ranjan.kumar@broadcom.com>
Date:   Tue Feb 28 06:08:30 2023 -0800

    scsi: mpi3mr: ioctl timeout when disabling/enabling interrupt
    
    [ Upstream commit 02ca7da2919ada525fb424640205110e24646b50 ]
    
    As part of Task Management handling, the driver will disable and enable the
    MSIx index zero which belongs to the Admin reply queue. During this
    transition the driver loses some interrupts and this leads to Admin request
    and ioctl timeouts.
    
    After enabling the interrupts, poll the Admin reply queue to avoid
    timeouts.
    
    Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
    Link: https://lore.kernel.org/r/20230228140835.4075-2-ranjan.kumar@broadcom.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Stable-dep-of: ce756daa36e1 ("scsi: mpi3mr: Fix expander node leak in mpi3mr_remove()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpi3mr: Return proper values for failures in firmware init path [+ + +]
Author: Ranjan Kumar <ranjan.kumar@broadcom.com>
Date:   Tue Feb 28 06:08:33 2023 -0800

    scsi: mpi3mr: Return proper values for failures in firmware init path
    
    [ Upstream commit ba8a9ba41fbde250fd8b0ed1e5dad0dc9318df46 ]
    
    Return proper non-zero return values for all the cases when the controller
    initialization and re-initialization fails.
    
    Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
    Link: https://lore.kernel.org/r/20230228140835.4075-5-ranjan.kumar@broadcom.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Stable-dep-of: c798304470ca ("scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add() [+ + +]
Author: Wenchao Hao <haowenchao2@huawei.com>
Date:   Sat Feb 25 18:01:36 2023 +0800

    scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add()
    
    [ Upstream commit d3c57724f1569311e4b81e98fad0931028b9bdcd ]
    
    Port is allocated by sas_port_alloc_num() and rphy is allocated by either
    sas_end_device_alloc() or sas_expander_alloc(), all of which may return
    NULL. So we need to check the rphy to avoid possible NULL pointer access.
    
    If sas_rphy_add() returned with failure, rphy is set to NULL. We would
    access the rphy in the following lines which would also result NULL pointer
    access.
    
    Fixes: 78316e9dfc24 ("scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()")
    Signed-off-by: Wenchao Hao <haowenchao2@huawei.com>
    Link: https://lore.kernel.org/r/20230225100135.2109330-1-haowenchao2@huawei.com
    Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: fix LLVM build for i386 and x86_64 [+ + +]
Author: Guillaume Tucker <guillaume.tucker@collabora.com>
Date:   Tue Aug 9 16:22:31 2022 +0200

    selftests: fix LLVM build for i386 and x86_64
    
    [ Upstream commit 624c60f326c6e5a80b008e8a5c7feffe8c27dc72 ]
    
    Add missing cases for the i386 and x86_64 architectures when
    determining the LLVM target for building kselftest.
    
    Fixes: 795285ef2425 ("selftests: Fix clang cross compilation")
    Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: devlink_port_split.py: skip test if no suitable device available [+ + +]
Author: Po-Hsu Lin <po-hsu.lin@canonical.com>
Date:   Thu Mar 16 00:53:53 2023 +0800

    selftests: net: devlink_port_split.py: skip test if no suitable device available
    
    [ Upstream commit 24994513ad13ff2c47ba91d2b5df82c3d496c370 ]
    
    The `devlink -j port show` command output may not contain the "flavour"
    key, an example from Ubuntu 22.10 s390x LPAR(5.19.0-37-generic), with
    mlx4 driver and iproute2-5.15.0:
      {"port":{"pci/0001:00:00.0/1":{"type":"eth","netdev":"ens301"},
               "pci/0001:00:00.0/2":{"type":"eth","netdev":"ens301d1"},
               "pci/0002:00:00.0/1":{"type":"eth","netdev":"ens317"},
               "pci/0002:00:00.0/2":{"type":"eth","netdev":"ens317d1"}}}
    
    This will cause a KeyError exception.
    
    Create a validate_devlink_output() to check for this "flavour" from
    devlink command output to avoid this KeyError exception. Also let
    it handle the check for `devlink -j dev show` output in main().
    
    Apart from this, if the test was not started because the max lanes of
    the designated device is 0. The script will still return 0 and thus
    causing a false-negative test result.
    
    Use a found_max_lanes flag to determine if these tests were skipped
    due to this reason and return KSFT_SKIP to make it more clear.
    
    Link: https://bugs.launchpad.net/bugs/1937133
    Fixes: f3348a82e727 ("selftests: net: Add port split test")
    Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Link: https://lore.kernel.org/r/20230315165353.229590-1-po-hsu.lin@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250: ASPEED_VUART: select REGMAP instead of depending on it [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 25 21:39:53 2023 -0800

    serial: 8250: ASPEED_VUART: select REGMAP instead of depending on it
    
    commit f8086d1a65ac693e3fd863128352b4b11ee7324d upstream.
    
    REGMAP is a hidden (not user visible) symbol. Users cannot set it
    directly thru "make *config", so drivers should select it instead of
    depending on it if they need it.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on REGMAP" to "select REGMAP".
    
    Fixes: 8d310c9107a2 ("drivers/tty/serial/8250: Make Aspeed VUART SIRQ polarity configurable")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Oskar Senft <osk@google.com>
    Cc: linux-serial@vger.kernel.org
    Link: https://lore.kernel.org/r/20230226053953.4681-9-rdunlap@infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250_em: Fix UART port type [+ + +]
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Mon Feb 27 11:41:46 2023 +0000

    serial: 8250_em: Fix UART port type
    
    commit 32e293be736b853f168cd065d9cbc1b0c69f545d upstream.
    
    As per HW manual for  EMEV2 "R19UH0040EJ0400 Rev.4.00", the UART
    IP found on EMMA mobile SoC is Register-compatible with the
    general-purpose 16750 UART chip. Fix UART port type as 16750 and
    enable 64-bytes fifo support.
    
    Fixes: 22886ee96895 ("serial8250-em: Emma Mobile UART driver V2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Link: https://lore.kernel.org/r/20230227114152.22265-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250_fsl: fix handle_irq locking [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Feb 27 09:50:46 2023 +0100

    serial: 8250_fsl: fix handle_irq locking
    
    commit 6e01f9a594ee0f69fb52cc8d11971612b4817f0b upstream.
    
    The 8250 handle_irq callback is not just called from the interrupt
    handler but also from a timer callback when polling (e.g. for ports
    without an interrupt line). Consequently the callback must explicitly
    disable interrupts to avoid a potential deadlock with another interrupt
    in polled mode.
    
    Fix up the two paths in the freescale callback that failed to re-enable
    interrupts when polling.
    
    Fixes: 853a9ae29e97 ("serial: 8250: fix handle_irq locking")
    Cc: stable@vger.kernel.org      # 5.13
    Reported-by: Dan Carpenter <error27@gmail.com>
    Link: https://lore.kernel.org/r/Y/xYzqp4ogmOF5t0@kili
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20230227085046.24282-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sh: intc: Avoid spurious sizeof-pointer-div warning [+ + +]
Author: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Date:   Tue Jan 24 22:48:16 2023 +0100

    sh: intc: Avoid spurious sizeof-pointer-div warning
    
    [ Upstream commit 250870824c1cf199b032b1ef889c8e8d69d9123a ]
    
    GCC warns about the pattern sizeof(void*)/sizeof(void), as it looks like
    the abuse of a pattern to calculate the array size. This pattern appears
    in the unevaluated part of the ternary operator in _INTC_ARRAY if the
    parameter is NULL.
    
    The replacement uses an alternate approach to return 0 in case of NULL
    which does not generate the pattern sizeof(void*)/sizeof(void), but still
    emits the warning if _INTC_ARRAY is called with a nonarray parameter.
    
    This patch is required for successful compilation with -Werror enabled.
    
    The idea to use _Generic for type distinction is taken from Comment #7
    in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek
    
    Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
    Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
    Link: https://lore.kernel.org/r/619fa552-c988-35e5-b1d7-fe256c46a272@mkarcher.dialup.fu-berlin.de
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sh_eth: avoid PHY being resumed when interface is not up [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Mar 15 08:41:15 2023 +0100

    sh_eth: avoid PHY being resumed when interface is not up
    
    [ Upstream commit c6be7136afb224a01d4cde2983ddebac8da98693 ]
    
    SH_ETH doesn't need mdiobus suspend/resume, that's why it sets
    'mac_managed_pm'. However, setting it needs to be moved from init to
    probe, so mdiobus PM functions will really never be called (e.g. when
    the interface is not up yet during suspend/resume).
    
    Fixes: 6a1dbfefdae4 ("net: sh_eth: Fix PHY state warning splat during system resume")
    Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: mediatek: mtk-svs: keep svs alive if CONFIG_DEBUG_FS not supported [+ + +]
Author: Roger Lu <roger.lu@mediatek.com>
Date:   Wed Jan 11 15:45:21 2023 +0800

    soc: mediatek: mtk-svs: keep svs alive if CONFIG_DEBUG_FS not supported
    
    [ Upstream commit 8bf305087629a98224aa97769587434ea4016767 ]
    
    Some projects might not support CONFIG_DEBUG_FS but still needs svs to be
    alive. Therefore, enclose debug cmd codes with CONFIG_DEBUG_FS to make sure
    svs can be alive when CONFIG_DEBUG_FS not supported.
    
    Signed-off-by: Roger Lu <roger.lu@mediatek.com>
    Link: https://lore.kernel.org/r/20230111074528.29354-8-roger.lu@mediatek.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: Fix bind() conflict check for dual-stack wildcard address. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sat Mar 11 19:19:03 2023 -0800

    tcp: Fix bind() conflict check for dual-stack wildcard address.
    
    [ Upstream commit d9ba9934285514f1f95d96326a82398a22dc77f2 ]
    
    Paul Holzinger reported [0] that commit 5456262d2baa ("net: Fix
    incorrect address comparison when searching for a bind2 bucket")
    introduced a bind() regression.  Paul also gave a nice repro that
    calls two types of bind() on the same port, both of which now
    succeed, but the second call should fail:
    
      bind(fd1, ::, port) + bind(fd2, 127.0.0.1, port)
    
    The cited commit added address family tests in three functions to
    fix the uninit-value KMSAN report. [1]  However, the test added to
    inet_bind2_bucket_match_addr_any() removed a necessary conflict
    check; the dual-stack wildcard address no longer conflicts with
    an IPv4 non-wildcard address.
    
    If tb->family is AF_INET6 and sk->sk_family is AF_INET in
    inet_bind2_bucket_match_addr_any(), we still need to check
    if tb has the dual-stack wildcard address.
    
    Note that the IPv4 wildcard address does not conflict with
    IPv6 non-wildcard addresses.
    
    [0]: https://lore.kernel.org/netdev/e21bf153-80b0-9ec0-15ba-e04a4ad42c34@redhat.com/
    [1]: https://lore.kernel.org/netdev/CAG_fn=Ud3zSW7AZWXc+asfMhZVL5ETnvuY44Pmyv4NPv-ijN-A@mail.gmail.com/
    
    Fixes: 5456262d2baa ("net: Fix incorrect address comparison when searching for a bind2 bucket")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reported-by: Paul Holzinger <pholzing@redhat.com>
    Link: https://lore.kernel.org/netdev/CAG_fn=Ud3zSW7AZWXc+asfMhZVL5ETnvuY44Pmyv4NPv-ijN-A@mail.gmail.com/
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Paul Holzinger <pholzing@redhat.com>
    Reviewed-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: tcp_make_synack() can be called from process context [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Wed Mar 8 11:07:45 2023 -0800

    tcp: tcp_make_synack() can be called from process context
    
    [ Upstream commit bced3f7db95ff2e6ca29dc4d1c9751ab5e736a09 ]
    
    tcp_rtx_synack() now could be called in process context as explained in
    0a375c822497 ("tcp: tcp_rtx_synack() can be called from process
    context").
    
    tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU
    variables with preemption enabled. This causes the following BUG:
    
        BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464
        caller is tcp_make_synack+0x841/0xac0
        Call Trace:
         <TASK>
         dump_stack_lvl+0x10d/0x1a0
         check_preemption_disabled+0x104/0x110
         tcp_make_synack+0x841/0xac0
         tcp_v6_send_synack+0x5c/0x450
         tcp_rtx_synack+0xeb/0x1f0
         inet_rtx_syn_ack+0x34/0x60
         tcp_check_req+0x3af/0x9e0
         tcp_rcv_state_process+0x59b/0x2030
         tcp_v6_do_rcv+0x5f5/0x700
         release_sock+0x3a/0xf0
         tcp_sendmsg+0x33/0x40
         ____sys_sendmsg+0x2f2/0x490
         __sys_sendmsg+0x184/0x230
         do_syscall_64+0x3d/0x90
    
    Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. Use
    TCP_INC_STATS() which is safe to be called from context switch.
    
    Fixes: 8336886f786f ("tcp: TCP Fast Open Server - support TFO listeners")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230308190745.780221-1-leitao@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
trace/hwlat: Do not start per-cpu thread if it is already running [+ + +]
Author: Tero Kristo <tero.kristo@linux.intel.com>
Date:   Fri Mar 10 12:04:51 2023 +0200

    trace/hwlat: Do not start per-cpu thread if it is already running
    
    commit 08697bca9bbba15f2058fdbd9f970bd5f6a8a2e8 upstream.
    
    The hwlatd tracer will end up starting multiple per-cpu threads with
    the following script:
    
        #!/bin/sh
        cd /sys/kernel/debug/tracing
        echo 0 > tracing_on
        echo hwlat > current_tracer
        echo per-cpu > hwlat_detector/mode
        echo 100000 > hwlat_detector/width
        echo 200000 > hwlat_detector/window
        echo 1 > tracing_on
    
    To fix the issue, check if the hwlatd thread for the cpu is already
    running, before starting a new one. Along with the previous patch, this
    avoids running multiple instances of the same CPU thread on the system.
    
    Link: https://lore.kernel.org/all/20230302113654.2984709-1-tero.kristo@linux.intel.com/
    Link: https://lkml.kernel.org/r/20230310100451.3948583-3-tero.kristo@linux.intel.com
    
    Cc: stable@vger.kernel.org
    Fixes: f46b16520a087 ("trace/hwlat: Implement the per-cpu mode")
    Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com>
    Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

trace/hwlat: Do not wipe the contents of per-cpu thread data [+ + +]
Author: Tero Kristo <tero.kristo@linux.intel.com>
Date:   Fri Mar 10 12:04:50 2023 +0200

    trace/hwlat: Do not wipe the contents of per-cpu thread data
    
    commit 4c42f5f0d1dd20bddd9f940beb1e6ccad60c4498 upstream.
    
    Do not wipe the contents of the per-cpu kthread data when starting the
    tracer, as this will completely forget about already running instances
    and can later start new additional per-cpu threads.
    
    Link: https://lore.kernel.org/all/20230302113654.2984709-1-tero.kristo@linux.intel.com/
    Link: https://lkml.kernel.org/r/20230310100451.3948583-2-tero.kristo@linux.intel.com
    
    Cc: stable@vger.kernel.org
    Fixes: f46b16520a087 ("trace/hwlat: Implement the per-cpu mode")
    Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com>
    Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Check field value in hist_field_name() [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Mar 1 20:00:53 2023 -0500

    tracing: Check field value in hist_field_name()
    
    commit 9f116f76fa8c04c81aef33ad870dbf9a158e5b70 upstream.
    
    The function hist_field_name() cannot handle being passed a NULL field
    parameter. It should never be NULL, but due to a previous bug, NULL was
    passed to the function and the kernel crashed due to a NULL dereference.
    Mark Rutland reported this to me on IRC.
    
    The bug was fixed, but to prevent future bugs from crashing the kernel,
    check the field and add a WARN_ON() if it is NULL.
    
    Link: https://lkml.kernel.org/r/20230302020810.762384440@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reported-by: Mark Rutland <mark.rutland@arm.com>
    Fixes: c6afad49d127f ("tracing: Add hist trigger 'sym' and 'sym-offset' modifiers")
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Make splice_read available again [+ + +]
Author: Sung-hun Kim <sfoon.kim@samsung.com>
Date:   Tue Mar 14 10:37:07 2023 +0900

    tracing: Make splice_read available again
    
    commit e400be674a1a40e9dcb2e95f84d6c1fd2d88f31d upstream.
    
    Since the commit 36e2c7421f02 ("fs: don't allow splice read/write
    without explicit ops") is applied to the kernel, splice() and
    sendfile() calls on the trace file (/sys/kernel/debug/tracing
    /trace) return EINVAL.
    
    This patch restores these system calls by initializing splice_read
    in file_operations of the trace file. This patch only enables such
    functionalities for the read case.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230314013707.28814-1-sfoon.kim@samsung.com
    
    Cc: stable@vger.kernel.org
    Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
    Signed-off-by: Sung-hun Kim <sfoon.kim@samsung.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Make tracepoint lockdep check actually test something [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Mar 10 17:28:56 2023 -0500

    tracing: Make tracepoint lockdep check actually test something
    
    commit c2679254b9c9980d9045f0f722cf093a2b1f7590 upstream.
    
    A while ago where the trace events had the following:
    
       rcu_read_lock_sched_notrace();
       rcu_dereference_sched(...);
       rcu_read_unlock_sched_notrace();
    
    If the tracepoint is enabled, it could trigger RCU issues if called in
    the wrong place. And this warning was only triggered if lockdep was
    enabled. If the tracepoint was never enabled with lockdep, the bug would
    not be caught. To handle this, the above sequence was done when lockdep
    was enabled regardless if the tracepoint was enabled or not (although the
    always enabled code really didn't do anything, it would still trigger a
    warning).
    
    But a lot has changed since that lockdep code was added. One is, that
    sequence no longer triggers any warning. Another is, the tracepoint when
    enabled doesn't even do that sequence anymore.
    
    The main check we care about today is whether RCU is "watching" or not.
    So if lockdep is enabled, always check if rcu_is_watching() which will
    trigger a warning if it is not (tracepoints require RCU to be watching).
    
    Note, that old sequence did add a bit of overhead when lockdep was enabled,
    and with the latest kernel updates, would cause the system to slow down
    enough to trigger kernel "stalled" warnings.
    
    Link: http://lore.kernel.org/lkml/20140806181801.GA4605@redhat.com
    Link: http://lore.kernel.org/lkml/20140807175204.C257CAC5@viggo.jf.intel.com
    Link: https://lore.kernel.org/lkml/20230307184645.521db5c9@gandalf.local.home/
    Link: https://lore.kernel.org/linux-trace-kernel/20230310172856.77406446@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: "Paul E. McKenney" <paulmck@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Paul E. McKenney <paulmck@kernel.org>
    Fixes: e6753f23d961 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tty: serial: fsl_lpuart: skip waiting for transmission complete when UARTCTRL_SBK is asserted [+ + +]
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Thu Feb 23 17:39:41 2023 +0800

    tty: serial: fsl_lpuart: skip waiting for transmission complete when UARTCTRL_SBK is asserted
    
    commit 2411fd94ceaa6e11326e95d6ebf876cbfed28d23 upstream.
    
    According to LPUART RM, Transmission Complete Flag becomes 0 if queuing
    a break character by writing 1 to CTRL[SBK], so here need to skip
    waiting for transmission complete when UARTCTRL_SBK is asserted,
    otherwise the kernel may stuck here.
    And actually set_termios() adds transmission completion waiting to avoid
    data loss or data breakage when changing the baud rate, but we don't
    need to worry about this when queuing break characters.
    
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20230223093941.31790-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vdpa/mlx5: should not activate virtq object when suspended [+ + +]
Author: Si-Wei Liu <si-wei.liu@oracle.com>
Date:   Tue Feb 14 17:30:40 2023 -0800

    vdpa/mlx5: should not activate virtq object when suspended
    
    [ Upstream commit 09e65ee9059d76b89cb713795748805efd3f50c6 ]
    
    Otherwise the virtqueue object to instate could point to invalid address
    that was unmapped from the MTT:
    
      mlx5_core 0000:41:04.2: mlx5_cmd_out_err:782:(pid 8321):
      CREATE_GENERAL_OBJECT(0xa00) op_mod(0xd) failed, status
      bad parameter(0x3), syndrome (0x5fa1c), err(-22)
    
    Fixes: cae15c2ed8e6 ("vdpa/mlx5: Implement susupend virtqueue callback")
    Cc: Eli Cohen <elic@nvidia.com>
    Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
    Reviewed-by: Eli Cohen <elic@nvidia.com>
    
    Message-Id: <1676424640-11673-1-git-send-email-si-wei.liu@oracle.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vdpa_sim: not reset state in vdpasim_queue_ready [+ + +]
Author: Eugenio Pérez <eperezma@redhat.com>
Date:   Wed Jan 18 17:43:58 2023 +0100

    vdpa_sim: not reset state in vdpasim_queue_ready
    
    [ Upstream commit 0e84f918fac8ae61dcb790534fad5e3555ca2930 ]
    
    vdpasim_queue_ready calls vringh_init_iotlb, which resets split indexes.
    But it can be called after setting a ring base with
    vdpasim_set_vq_state.
    
    Fix it by stashing them. They're still resetted in vdpasim_vq_reset.
    
    This was discovered and tested live migrating the vdpa_sim_net device.
    
    Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator")
    Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
    Message-Id: <20230118164359.1523760-2-eperezma@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Tested-by: Lei Yang <leiyang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

vdpa_sim: set last_used_idx as last_avail_idx in vdpasim_queue_ready [+ + +]
Author: Eugenio Pérez <eperezma@redhat.com>
Date:   Thu Mar 2 19:18:57 2023 +0100

    vdpa_sim: set last_used_idx as last_avail_idx in vdpasim_queue_ready
    
    [ Upstream commit b4cca6d48eb3fa6f0d9caba4329b1a2b0ff67a77 ]
    
    Starting from an used_idx different than 0 is needed in use cases like
    virtual machine migration.  Not doing so and letting the caller set an
    avail idx different than 0 causes destination device to try to use old
    buffers that source driver already recover and are not available
    anymore.
    
    Since vdpa_sim does not support receive inflight descriptors as a
    destination of a migration, let's set both avail_idx and used_idx the
    same at vq start.  This is how vhost-user works in a
    VHOST_SET_VRING_BASE call.
    
    Although the simple fix is to set last_used_idx at vdpasim_set_vq_state,
    it would be reset at vdpasim_queue_ready.  The last_avail_idx case is
    fixed with commit 0e84f918fac8 ("vdpa_sim: not reset state in
    vdpasim_queue_ready").  Since the only option is to make it equal to
    last_avail_idx, adding the only change needed here.
    
    This was discovered and tested live migrating the vdpa_sim_net device.
    
    Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator")
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
    Message-Id: <20230302181857.925374-1-eperezma@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
veth: Fix use after free in XDP_REDIRECT [+ + +]
Author: Shawn Bohrer <sbohrer@cloudflare.com>
Date:   Tue Mar 14 10:33:51 2023 -0500

    veth: Fix use after free in XDP_REDIRECT
    
    [ Upstream commit 7c10131803e45269ddc6c817f19ed649110f3cae ]
    
    Commit 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order
    to accept non-linear skb") introduced a bug where it tried to
    use pskb_expand_head() if the headroom was less than
    XDP_PACKET_HEADROOM.  This however uses kmalloc to expand the head,
    which will later allow consume_skb() to free the skb while is it still
    in use by AF_XDP.
    
    Previously if the headroom was less than XDP_PACKET_HEADROOM we
    continued on to allocate a new skb from pages so this restores that
    behavior.
    
    BUG: KASAN: use-after-free in __xsk_rcv+0x18d/0x2c0
    Read of size 78 at addr ffff888976250154 by task napi/iconduit-g/148640
    
    CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: loaded Tainted: G           O       6.1.4-cloudflare-kasan-2023.1.2 #1
    Hardware name: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S_3B10.03 06/21/2018
    Call Trace:
      <TASK>
      dump_stack_lvl+0x34/0x48
      print_report+0x170/0x473
      ? __xsk_rcv+0x18d/0x2c0
      kasan_report+0xad/0x130
      ? __xsk_rcv+0x18d/0x2c0
      kasan_check_range+0x149/0x1a0
      memcpy+0x20/0x60
      __xsk_rcv+0x18d/0x2c0
      __xsk_map_redirect+0x1f3/0x490
      ? veth_xdp_rcv_skb+0x89c/0x1ba0 [veth]
      xdp_do_redirect+0x5ca/0xd60
      veth_xdp_rcv_skb+0x935/0x1ba0 [veth]
      ? __netif_receive_skb_list_core+0x671/0x920
      ? veth_xdp+0x670/0x670 [veth]
      veth_xdp_rcv+0x304/0xa20 [veth]
      ? do_xdp_generic+0x150/0x150
      ? veth_xdp_rcv_one+0xde0/0xde0 [veth]
      ? _raw_spin_lock_bh+0xe0/0xe0
      ? newidle_balance+0x887/0xe30
      ? __perf_event_task_sched_in+0xdb/0x800
      veth_poll+0x139/0x571 [veth]
      ? veth_xdp_rcv+0xa20/0xa20 [veth]
      ? _raw_spin_unlock+0x39/0x70
      ? finish_task_switch.isra.0+0x17e/0x7d0
      ? __switch_to+0x5cf/0x1070
      ? __schedule+0x95b/0x2640
      ? io_schedule_timeout+0x160/0x160
      __napi_poll+0xa1/0x440
      napi_threaded_poll+0x3d1/0x460
      ? __napi_poll+0x440/0x440
      ? __kthread_parkme+0xc6/0x1f0
      ? __napi_poll+0x440/0x440
      kthread+0x2a2/0x340
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x22/0x30
      </TASK>
    
    Freed by task 148640:
      kasan_save_stack+0x23/0x50
      kasan_set_track+0x21/0x30
      kasan_save_free_info+0x2a/0x40
      ____kasan_slab_free+0x169/0x1d0
      slab_free_freelist_hook+0xd2/0x190
      __kmem_cache_free+0x1a1/0x2f0
      skb_release_data+0x449/0x600
      consume_skb+0x9f/0x1c0
      veth_xdp_rcv_skb+0x89c/0x1ba0 [veth]
      veth_xdp_rcv+0x304/0xa20 [veth]
      veth_poll+0x139/0x571 [veth]
      __napi_poll+0xa1/0x440
      napi_threaded_poll+0x3d1/0x460
      kthread+0x2a2/0x340
      ret_from_fork+0x22/0x30
    
    The buggy address belongs to the object at ffff888976250000
      which belongs to the cache kmalloc-2k of size 2048
    The buggy address is located 340 bytes inside of
      2048-byte region [ffff888976250000, ffff888976250800)
    
    The buggy address belongs to the physical page:
    page:00000000ae18262a refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x976250
    head:00000000ae18262a order:3 compound_mapcount:0 compound_pincount:0
    flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff)
    raw: 002ffff800010200 0000000000000000 dead000000000122 ffff88810004cf00
    raw: 0000000000000000 0000000080080008 00000002ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
      ffff888976250000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888976250080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    > ffff888976250100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                      ^
      ffff888976250180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888976250200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order to accept non-linear skb")
    Signed-off-by: Shawn Bohrer <sbohrer@cloudflare.com>
    Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Acked-by: Toshiaki Makita <toshiaki.makita1@gmail.com>
    Acked-by: Toke Høiland-Jørgensen <toke@kernel.org>
    Link: https://lore.kernel.org/r/20230314153351.2201328-1-sbohrer@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vhost-vdpa: free iommu domain after last use during cleanup [+ + +]
Author: Gautam Dawar <gautam.dawar@amd.com>
Date:   Wed Mar 1 22:02:01 2023 +0530

    vhost-vdpa: free iommu domain after last use during cleanup
    
    [ Upstream commit 5a522150093a0eabae9470a70a37a6e436bfad08 ]
    
    Currently vhost_vdpa_cleanup() unmaps the DMA mappings by calling
    `iommu_unmap(v->domain, map->start, map->size);`
    from vhost_vdpa_general_unmap() when the parent vDPA driver doesn't
    provide DMA config operations.
    
    However, the IOMMU domain referred to by `v->domain` is freed in
    vhost_vdpa_free_domain() before vhost_vdpa_cleanup() in
    vhost_vdpa_release() which results in NULL pointer de-reference.
    Accordingly, moving the call to vhost_vdpa_free_domain() in
    vhost_vdpa_cleanup() would makes sense. This will also help
    detaching the dma device in error handling of vhost_vdpa_alloc_domain().
    
    This issue was observed on terminating QEMU with SIGQUIT.
    
    Fixes: 037d4305569a ("vhost-vdpa: call vhost_vdpa_cleanup during the release")
    Signed-off-by: Gautam Dawar <gautam.dawar@amd.com>
    Message-Id: <20230301163203.29883-1-gautam.dawar@amd.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virt/coco/sev-guest: Add throttling awareness [+ + +]
Author: Dionna Glaze <dionnaglaze@google.com>
Date:   Thu Feb 16 11:08:02 2023 +0100

    virt/coco/sev-guest: Add throttling awareness
    
    commit 72f7754dcf31c87c92c0c353dcf747814cc5ce10 upstream.
    
    A potentially malicious SEV guest can constantly hammer the hypervisor
    using this driver to send down requests and thus prevent or at least
    considerably hinder other guests from issuing requests to the secure
    processor which is a shared platform resource.
    
    Therefore, the host is permitted and encouraged to throttle such guest
    requests.
    
    Add the capability to handle the case when the hypervisor throttles
    excessive numbers of requests issued by the guest. Otherwise, the VM
    platform communication key will be disabled, preventing the guest from
    attesting itself.
    
    Realistically speaking, a well-behaved guest should not even care about
    throttling. During its lifetime, it would end up issuing a handful of
    requests which the hardware can easily handle.
    
    This is more to address the case of a malicious guest. Such guest should
    get throttled and if its VMPCK gets disabled, then that's its own
    wrongdoing and perhaps that guest even deserves it.
    
    To the implementation: the hypervisor signals with SNP_GUEST_REQ_ERR_BUSY
    that the guest requests should be throttled. That error code is returned
    in the upper 32-bit half of exitinfo2 and this is part of the GHCB spec
    v2.
    
    So the guest is given a throttling period of 1 minute in which it
    retries the request every 2 seconds. This is a good default but if it
    turns out to not pan out in practice, it can be tweaked later.
    
    For safety, since the encryption algorithm in GHCBv2 is AES_GCM, control
    must remain in the kernel to complete the request with the current
    sequence number. Returning without finishing the request allows the
    guest to make another request but with different message contents. This
    is IV reuse, and breaks cryptographic protections.
    
      [ bp:
        - Rewrite commit message and do a simplified version.
        - The stable tags are supposed to denote that a cleanup should go
          upfront before backporting this so that any future fixes to this
          can preserve the sanity of the backporter(s). ]
    
    Fixes: d5af44dde546 ("x86/sev: Provide support for SNP guest request NAEs")
    Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
    Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: <stable@kernel.org> # d6fd48eff750 ("virt/coco/sev-guest: Check SEV_SNP attribute at probe time")
    Cc: <stable@kernel.org> # 970ab823743f (" virt/coco/sev-guest: Simplify extended guest request handling")
    Cc: <stable@kernel.org> # c5a338274bdb ("virt/coco/sev-guest: Remove the disable_vmpck label in handle_guest_request()")
    Cc: <stable@kernel.org> # 0fdb6cc7c89c ("virt/coco/sev-guest: Carve out the request issuing logic into a helper")
    Cc: <stable@kernel.org> # d25bae7dc7b0 ("virt/coco/sev-guest: Do some code style cleanups")
    Cc: <stable@kernel.org> # fa4ae42cc60a ("virt/coco/sev-guest: Convert the sw_exit_info_2 checking to a switch-case")
    Link: https://lore.kernel.org/r/20230214164638.1189804-2-dionnaglaze@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virt/coco/sev-guest: Carve out the request issuing logic into a helper [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Tue Mar 7 09:19:19 2023 -0600

    virt/coco/sev-guest: Carve out the request issuing logic into a helper
    
    commit 0fdb6cc7c89cb5e0cbc45dbdbafb8e3fb92ddc95 upstream.
    
    This makes the code flow a lot easier to follow.
    
    No functional changes.
    
      [ Tom: touchups. ]
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20230307192449.24732-6-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virt/coco/sev-guest: Check SEV_SNP attribute at probe time [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Wed Feb 15 11:01:42 2023 +0100

    virt/coco/sev-guest: Check SEV_SNP attribute at probe time
    
    commit d6fd48eff7506bb866a54e40369df8899f2078a9 upstream.
    
    No need to check it on every ioctl. And yes, this is a common SEV driver
    but it does only SNP-specific operations currently. This can be
    revisited later, when more use cases appear.
    
    No functional changes.
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Link: https://lore.kernel.org/r/20230307192449.24732-3-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virt/coco/sev-guest: Convert the sw_exit_info_2 checking to a switch-case [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Thu Feb 16 10:50:11 2023 +0100

    virt/coco/sev-guest: Convert the sw_exit_info_2 checking to a switch-case
    
    commit fa4ae42cc60a7dea30e8f2db444b808d80862345 upstream.
    
    snp_issue_guest_request() checks the value returned by the hypervisor in
    sw_exit_info_2 and returns a different error depending on it.
    
    Convert those checks into a switch-case to make it more readable when
    more error values are going to be checked in the future.
    
    No functional changes.
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Link: https://lore.kernel.org/r/20230307192449.24732-8-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virt/coco/sev-guest: Do some code style cleanups [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Wed Feb 15 11:54:59 2023 +0100

    virt/coco/sev-guest: Do some code style cleanups
    
    commit d25bae7dc7b0668cb2a1325c64eb32d5fea4e5a9 upstream.
    
    Remove unnecessary linebreaks, make the code more compact.
    
    No functional changes.
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Link: https://lore.kernel.org/r/20230307192449.24732-7-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virt/coco/sev-guest: Remove the disable_vmpck label in handle_guest_request() [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Wed Feb 15 11:43:43 2023 +0100

    virt/coco/sev-guest: Remove the disable_vmpck label in handle_guest_request()
    
    commit c5a338274bdb894f088767bea856be344d0ccaef upstream.
    
    Call the function directly instead.
    
    No functional changes.
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Link: https://lore.kernel.org/r/20230307192449.24732-5-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virt/coco/sev-guest: Simplify extended guest request handling [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Wed Feb 15 11:39:41 2023 +0100

    virt/coco/sev-guest: Simplify extended guest request handling
    
    commit 970ab823743fb54b42002ec76c51481f67436444 upstream.
    
    Return a specific error code - -ENOSPC - to signal the too small cert
    data buffer instead of checking exit code and exitinfo2.
    
    While at it, hoist the *fw_err assignment in snp_issue_guest_request()
    so that a proper error value is returned to the callers.
    
      [ Tom: check override_err instead of err. ]
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20230307192449.24732-4-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vp_vdpa: fix the crash in hot unplug with vp_vdpa [+ + +]
Author: Cindy Lu <lulu@redhat.com>
Date:   Tue Feb 14 16:09:24 2023 +0800

    vp_vdpa: fix the crash in hot unplug with vp_vdpa
    
    commit aed8efddd39b3434c96718d39009285c52b1cafc upstream.
    
    While unplugging the vp_vdpa device, it triggers a kernel panic
    The root cause is: vdpa_mgmtdev_unregister() will accesses modern
    devices which will cause a use after free.
    So need to change the sequence in vp_vdpa_remove
    
    [  195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014
    [  195.004012] #PF: supervisor read access in kernel mode
    [  195.004486] #PF: error_code(0x0000) - not-present page
    [  195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0
    [  195.005578] Oops: 0000 1 PREEMPT SMP PTI
    [  195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1
    [  195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown
    [  195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
    [  195.008059] RIP: 0010:ioread8+0x31/0x80
    [  195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7
    [  195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292
    [  195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0
    [  195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014
    [  195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68
    [  195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120
    [  195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805
    [  195.013826] FS:  0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000
    [  195.014564] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0
    [  195.015741] PKRU: 55555554
    [  195.016001] Call Trace:
    [  195.016233]  <TASK>
    [  195.016434]  vp_modern_get_status+0x12/0x20
    [  195.016823]  vp_vdpa_reset+0x1b/0x50 [vp_vdpa]
    [  195.017238]  virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa]
    [  195.017709]  remove_vq_common+0x1f/0x3a0 [virtio_net]
    [  195.018178]  virtnet_remove+0x5d/0x70 [virtio_net]
    [  195.018618]  virtio_dev_remove+0x3d/0x90
    [  195.018986]  device_release_driver_internal+0x1aa/0x230
    [  195.019466]  bus_remove_device+0xd8/0x150
    [  195.019841]  device_del+0x18b/0x3f0
    [  195.020167]  ? kernfs_find_ns+0x35/0xd0
    [  195.020526]  device_unregister+0x13/0x60
    [  195.020894]  unregister_virtio_device+0x11/0x20
    [  195.021311]  device_release_driver_internal+0x1aa/0x230
    [  195.021790]  bus_remove_device+0xd8/0x150
    [  195.022162]  device_del+0x18b/0x3f0
    [  195.022487]  device_unregister+0x13/0x60
    [  195.022852]  ? vdpa_dev_remove+0x30/0x30 [vdpa]
    [  195.023270]  vp_vdpa_dev_del+0x12/0x20 [vp_vdpa]
    [  195.023694]  vdpa_match_remove+0x2b/0x40 [vdpa]
    [  195.024115]  bus_for_each_dev+0x78/0xc0
    [  195.024471]  vdpa_mgmtdev_unregister+0x65/0x80 [vdpa]
    [  195.024937]  vp_vdpa_remove+0x23/0x40 [vp_vdpa]
    [  195.025353]  pci_device_remove+0x36/0xa0
    [  195.025719]  device_release_driver_internal+0x1aa/0x230
    [  195.026201]  pci_stop_bus_device+0x6c/0x90
    [  195.026580]  pci_stop_and_remove_bus_device+0xe/0x20
    [  195.027039]  disable_slot+0x49/0x90
    [  195.027366]  acpiphp_disable_and_eject_slot+0x15/0x90
    [  195.027832]  hotplug_event+0xea/0x210
    [  195.028171]  ? hotplug_event+0x210/0x210
    [  195.028535]  acpiphp_hotplug_notify+0x22/0x80
    [  195.028942]  ? hotplug_event+0x210/0x210
    [  195.029303]  acpi_device_hotplug+0x8a/0x1d0
    [  195.029690]  acpi_hotplug_work_fn+0x1a/0x30
    [  195.030077]  process_one_work+0x1e8/0x3c0
    [  195.030451]  worker_thread+0x50/0x3b0
    [  195.030791]  ? rescuer_thread+0x3a0/0x3a0
    [  195.031165]  kthread+0xd9/0x100
    [  195.031459]  ? kthread_complete_and_exit+0x20/0x20
    [  195.031899]  ret_from_fork+0x22/0x30
    [  195.032233]  </TASK>
    
    Fixes: ffbda8e9df10 ("vdpa/vp_vdpa : add vdpa tool support in vp_vdpa")
    Tested-by: Lei Yang <leiyang@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Cindy Lu <lulu@redhat.com>
    Message-Id: <20230214080924.131462-1-lulu@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: cfg80211: fix MLO connection ownership [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 1 12:09:33 2023 +0200

    wifi: cfg80211: fix MLO connection ownership
    
    [ Upstream commit 96c069508377547f913e7265a80fffe9355de592 ]
    
    When disconnecting from an MLO connection we need the AP
    MLD address, not an arbitrary BSSID. Fix the code to do
    that.
    
    Fixes: 9ecff10e82a5 ("wifi: nl80211: refactor BSS lookup in nl80211_associate()")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230301115906.4c1b3b18980e.I008f070c7f3b8e8bde9278101ef9e40706a82902@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: nl80211: fix NULL-ptr deref in offchan check [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 1 12:09:29 2023 +0200

    wifi: nl80211: fix NULL-ptr deref in offchan check
    
    [ Upstream commit f624bb6fad23df3270580b4fcef415c6e7bf7705 ]
    
    If, e.g. in AP mode, the link was already created by userspace
    but not activated yet, it has a chandef but the chandef isn't
    valid and has no channel. Check for this and ignore this link.
    
    Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230301115906.71bd4803fbb9.Iee39c0f6c2d3a59a8227674dc55d52e38b1090cf@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/mce: Make sure logged MCEs are processed after sysfs update [+ + +]
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Wed Mar 1 22:14:20 2023 +0000

    x86/mce: Make sure logged MCEs are processed after sysfs update
    
    commit 4783b9cb374af02d49740e00e2da19fd4ed6dec4 upstream.
    
    A recent change introduced a flag to queue up errors found during
    boot-time polling. These errors will be processed during late init once
    the MCE subsystem is fully set up.
    
    A number of sysfs updates call mce_restart() which goes through a subset
    of the CPU init flow. This includes polling MCA banks and logging any
    errors found. Since the same function is used as boot-time polling,
    errors will be queued. However, the system is now past late init, so the
    errors will remain queued until another error is found and the workqueue
    is triggered.
    
    Call mce_schedule_work() at the end of mce_restart() so that queued
    errors are processed.
    
    Fixes: 3bff147b187d ("x86/mce: Defer processing of early errors")
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230301221420.2203184-1-yazen.ghannam@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/mm: Fix use of uninitialized buffer in sme_enable() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Mon Mar 6 08:06:56 2023 -0800

    x86/mm: Fix use of uninitialized buffer in sme_enable()
    
    commit cbebd68f59f03633469f3ecf9bea99cd6cce3854 upstream.
    
    cmdline_find_option() may fail before doing any initialization of
    the buffer array. This may lead to unpredictable results when the same
    buffer is used later in calls to strncmp() function.  Fix the issue by
    returning early if cmdline_find_option() returns an error.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: aca20d546214 ("x86/mm: Add support to make use of Secure Memory Encryption")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20230306160656.14844-1-n.zhandarovich@fintech.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/resctrl: Clear staged_config[] before and after it is used [+ + +]
Author: Shawn Wang <shawnwang@linux.alibaba.com>
Date:   Tue Jan 17 13:14:50 2023 -0800

    x86/resctrl: Clear staged_config[] before and after it is used
    
    commit 0424a7dfe9129b93f29b277511a60e87f052ac6b upstream.
    
    As a temporary storage, staged_config[] in rdt_domain should be cleared
    before and after it is used. The stale value in staged_config[] could
    cause an MSR access error.
    
    Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3
    Cache (MBA should be disabled if the number of CLOSIDs for MB is less than
    16.) :
            mount -t resctrl resctrl -o cdp /sys/fs/resctrl
            mkdir /sys/fs/resctrl/p{1..7}
            umount /sys/fs/resctrl/
            mount -t resctrl resctrl /sys/fs/resctrl
            mkdir /sys/fs/resctrl/p{1..8}
    
    An error occurs when creating resource group named p8:
        unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)
        Call Trace:
         <IRQ>
         __flush_smp_call_function_queue+0x11d/0x170
         __sysvec_call_function+0x24/0xd0
         sysvec_call_function+0x89/0xc0
         </IRQ>
         <TASK>
         asm_sysvec_call_function+0x16/0x20
    
    When creating a new resource control group, hardware will be configured
    by the following process:
        rdtgroup_mkdir()
          rdtgroup_mkdir_ctrl_mon()
            rdtgroup_init_alloc()
              resctrl_arch_update_domains()
    
    resctrl_arch_update_domains() iterates and updates all resctrl_conf_type
    whose have_new_ctrl is true. Since staged_config[] holds the same values as
    when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA
    configurations. When group p8 is created, get_config_index() called in
    resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for
    CDP_CODE and CDP_DATA, which will be translated to an invalid register -
    0xca0 in this scenario.
    
    Fix it by clearing staged_config[] before and after it is used.
    
    [reinette: re-order commit tags]
    
    Fixes: 75408e43509e ("x86/resctrl: Allow different CODE/DATA configurations to be staged")
    Suggested-by: Xin Hao <xhao@linux.alibaba.com>
    Signed-off-by: Shawn Wang <shawnwang@linux.alibaba.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Tested-by: Reinette Chatre <reinette.chatre@intel.com>
    Cc:stable@vger.kernel.org
    Link: https://lore.kernel.org/all/2fad13f49fbe89687fc40e9a5a61f23a28d1507a.1673988935.git.reinette.chatre%40intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xfrm: Allow transport-mode states with AF_UNSPEC selector [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Feb 21 13:54:00 2023 +0800

    xfrm: Allow transport-mode states with AF_UNSPEC selector
    
    [ Upstream commit c276a706ea1f51cf9723ed8484feceaf961b8f89 ]
    
    xfrm state selectors are matched against the inner-most flow
    which can be of any address family.  Therefore middle states
    in nested configurations need to carry a wildcard selector in
    order to work at all.
    
    However, this is currently forbidden for transport-mode states.
    
    Fix this by removing the unnecessary check.
    
    Fixes: 13996378e658 ("[IPSEC]: Rename mode to outer_mode and add inner_mode")
    Reported-by: David George <David.George@sophos.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>