Linux 5.18.6

 
ALSA: hda/realtek - Add HW8326 support [+ + +]
Author: huangwenhui <huangwenhuia@uniontech.com>
Date:   Wed Jun 8 16:23:57 2022 +0800

    ALSA: hda/realtek - Add HW8326 support
    
    [ Upstream commit 527f4643e03c298c1e3321cfa27866b1374a55e1 ]
    
    Added the support of new Huawei codec HW8326. The HW8326 is developed
    by Huawei with Realtek's IP Core, and it's compatible with ALC256.
    
    Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
    Link: https://lore.kernel.org/r/20220608082357.26898-1-huangwenhuia@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: MTL: add HD Audio PCI ID and HDMI codec vendor ID [+ + +]
Author: Yong Zhi <yong.zhi@intel.com>
Date:   Mon Jun 6 15:42:32 2022 -0500

    ALSA: hda: MTL: add HD Audio PCI ID and HDMI codec vendor ID
    
    [ Upstream commit 2e45f2185283a2d927ef2cdbdc246cd65740c8df ]
    
    Add HD Audio PCI ID for Intel Meteorlake platform.
    
    [ corrected the hex number to lower letters by tiwai ]
    
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Signed-off-by: Yong Zhi <yong.zhi@intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220606204232.144296-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3 [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Tue Apr 26 15:51:43 2022 -0500

    arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3
    
    commit 4ce01ce36d77137cf60776b320babed89de6bd4c upstream.
    
    There is a header for a DB9 serial port, but any attempts to use
    hardware handshaking fail.  Enable RTS and CTS pin muxing and enable
    handshaking in the uart node.
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: imx8mn-beacon: Enable RTS-CTS on UART3 [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Tue Apr 26 15:51:44 2022 -0500

    arm64: dts: imx8mn-beacon: Enable RTS-CTS on UART3
    
    commit 5446ff1a67160ad92d9aae9530846aa54750be36 upstream.
    
    There is a header for a DB9 serial port, but any attempts to use
    hardware handshaking fail.  Enable RTS and CTS pin muxing and enable
    handshaking in the uart node.
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: ftrace: consistently handle PLTs. [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jun 14 09:09:43 2022 +0100

    arm64: ftrace: consistently handle PLTs.
    
    [ Upstream commit a6253579977e4c6f7818eeb05bf2bc65678a7187 ]
    
    Sometimes it is necessary to use a PLT entry to call an ftrace
    trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(),
    with each having *almost* identical logic, but this is not handled by
    ftrace_modify_call() since its introduction in commit:
    
      3b23e4991fb66f6d ("arm64: implement ftrace with regs")
    
    Due to this, if we ever were to call ftrace_modify_call() for a callsite
    which requires a PLT entry for a trampoline, then either:
    
    a) If the old addr requires a trampoline, ftrace_modify_call() will use
       an out-of-range address to generate the 'old' branch instruction.
       This will result in warnings from aarch64_insn_gen_branch_imm() and
       ftrace_modify_code(), and no instructions will be modified. As
       ftrace_modify_call() will return an error, this will result in
       subsequent internal ftrace errors.
    
    b) If the old addr does not require a trampoline, but the new addr does,
       ftrace_modify_call() will use an out-of-range address to generate the
       'new' branch instruction. This will result in warnings from
       aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace
       the 'old' branch with a BRK. This will result in a kernel panic when
       this BRK is later executed.
    
    Practically speaking, case (a) is vastly more likely than case (b), and
    typically this will result in internal ftrace errors that don't
    necessarily affect the rest of the system. This can be demonstrated with
    an out-of-tree test module which triggers ftrace_modify_call(), e.g.
    
    | # insmod test_ftrace.ko
    | test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024
    | branch_imm_common: offset out of range
    | branch_imm_common: offset out of range
    | ------------[ ftrace bug ]------------
    | ftrace failed to modify
    | [<ffffb37493992024>] test_function+0x8/0x38 [test_ftrace]
    |  actual:   1d:00:00:94
    | Updating ftrace call site to call a different ftrace function
    | ftrace record flags: e0000002
    |  (2) R
    |  expected tramp: ffffb374ae42ed54
    | ------------[ cut here ]------------
    | WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftrace_bug+0x280/0x2b0
    | Modules linked in: test_ftrace(+)
    | CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : ftrace_bug+0x280/0x2b0
    | lr : ftrace_bug+0x280/0x2b0
    | sp : ffff80000839ba00
    | x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0
    | x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000
    | x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8
    | x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff
    | x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4
    | x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666
    | x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8
    | x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167
    | x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000
    | x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022
    | Call trace:
    |  ftrace_bug+0x280/0x2b0
    |  ftrace_replace_code+0x98/0xa0
    |  ftrace_modify_all_code+0xe0/0x144
    |  arch_ftrace_update_code+0x14/0x20
    |  ftrace_startup+0xf8/0x1b0
    |  register_ftrace_function+0x38/0x90
    |  test_ftrace_init+0xd0/0x1000 [test_ftrace]
    |  do_one_initcall+0x50/0x2b0
    |  do_init_module+0x50/0x1f0
    |  load_module+0x17c8/0x1d64
    |  __do_sys_finit_module+0xa8/0x100
    |  __arm64_sys_finit_module+0x2c/0x3c
    |  invoke_syscall+0x50/0x120
    |  el0_svc_common.constprop.0+0xdc/0x100
    |  do_el0_svc+0x3c/0xd0
    |  el0_svc+0x34/0xb0
    |  el0t_64_sync_handler+0xbc/0x140
    |  el0t_64_sync+0x18c/0x190
    | ---[ end trace 0000000000000000 ]---
    
    We can solve this by consistently determining whether to use a PLT entry
    for an address.
    
    Note that since (the earlier) commit:
    
      f1a54ae9af0da4d7 ("arm64: module/ftrace: intialize PLT at load time")
    
    ... we can consistently determine the PLT address that a given callsite
    will use, and therefore ftrace_make_nop() does not need to skip
    validation when a PLT is in use.
    
    This patch factors the existing logic out of ftrace_make_call() and
    ftrace_make_nop() into a common ftrace_find_callable_addr() helper
    function, which is used by ftrace_make_call(), ftrace_make_nop(), and
    ftrace_modify_call(). In ftrace_make_nop() the patching is consistently
    validated by ftrace_modify_code() as we can always determine what the
    old instruction should have been.
    
    Fixes: 3b23e4991fb6 ("arm64: implement ftrace with regs")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
    Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20220614080944.1349146-3-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: ftrace: fix branch range checks [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jun 14 09:09:42 2022 +0100

    arm64: ftrace: fix branch range checks
    
    [ Upstream commit 3eefdf9d1e406f3da47470b2854347009ffcb6fa ]
    
    The branch range checks in ftrace_make_call() and ftrace_make_nop() are
    incorrect, erroneously permitting a forwards branch of 128M and
    erroneously rejecting a backwards branch of 128M.
    
    This is because both functions calculate the offset backwards,
    calculating the offset *from* the target *to* the branch, rather than
    the other way around as the later comparisons expect.
    
    If an out-of-range branch were erroeously permitted, this would later be
    rejected by aarch64_insn_gen_branch_imm() as branch_imm_common() checks
    the bounds correctly, resulting in warnings and the placement of a BRK
    instruction. Note that this can only happen for a forwards branch of
    exactly 128M, and so the caller would need to be exactly 128M bytes
    below the relevant ftrace trampoline.
    
    If an in-range branch were erroeously rejected, then:
    
    * For modules when CONFIG_ARM64_MODULE_PLTS=y, this would result in the
      use of a PLT entry, which is benign.
    
      Note that this is the common case, as this is selected by
      CONFIG_RANDOMIZE_BASE (and therefore RANDOMIZE_MODULE_REGION_FULL),
      which distributions typically seelct. This is also selected by
      CONFIG_ARM64_ERRATUM_843419.
    
    * For modules when CONFIG_ARM64_MODULE_PLTS=n, this would result in
      internal ftrace failures.
    
    * For core kernel text, this would result in internal ftrace failues.
    
      Note that for this to happen, the kernel text would need to be at
      least 128M bytes in size, and typical configurations are smaller tha
      this.
    
    Fix this by calculating the offset *from* the branch *to* the target in
    both functions.
    
    Fixes: f8af0b364e24 ("arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()")
    Fixes: e71a4e1bebaf ("arm64: ftrace: add support for far branches to dynamic ftrace")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
    Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20220614080944.1349146-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer [+ + +]
Author: Will Deacon <will@kernel.org>
Date:   Fri Jun 10 16:12:27 2022 +0100

    arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer
    
    commit c50f11c6196f45c92ca48b16a5071615d4ae0572 upstream.
    
    Invalidating the buffer memory in arch_sync_dma_for_device() for
    FROM_DEVICE transfers
    
    When using the streaming DMA API to map a buffer prior to inbound
    non-coherent DMA (i.e. DMA_FROM_DEVICE), we invalidate any dirty CPU
    cachelines so that they will not be written back during the transfer and
    corrupt the buffer contents written by the DMA. This, however, poses two
    potential problems:
    
      (1) If the DMA transfer does not write to every byte in the buffer,
          then the unwritten bytes will contain stale data once the transfer
          has completed.
    
      (2) If the buffer has a virtual alias in userspace, then stale data
          may be visible via this alias during the period between performing
          the cache invalidation and the DMA writes landing in memory.
    
    Address both of these issues by cleaning (aka writing-back) the dirty
    lines in arch_sync_dma_for_device(DMA_FROM_DEVICE) instead of discarding
    them using invalidation.
    
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606152150.GA31568@willie-the-truck
    Signed-off-by: Will Deacon <will@kernel.org>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20220610151228.4562-2-will@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: cs35l36: Update digital volume TLV [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:15 2022 +0100

    ASoC: cs35l36: Update digital volume TLV
    
    [ Upstream commit 5005a2345825eb8346546d99bfe669f73111b5c5 ]
    
    The digital volume TLV specifies the step as 0.25dB but the actual step
    of the control is 0.125dB. Update the TLV to correct this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-3-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs42l51: Correct minimum value for SX volume control [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:19 2022 +0100

    ASoC: cs42l51: Correct minimum value for SX volume control
    
    [ Upstream commit fcb3b5a58926d16d9a338841b74af06d4c29be15 ]
    
    The minimum value for the PGA Volume is given as 0x1A, however the
    values from there to 0x19 are all the same volume and this is not
    represented in the TLV structure. The number of volumes given is correct
    so this leads to all the volumes being shifted. Move the minimum value
    up to 0x19 to fix this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-7-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs42l52: Correct TLV for Bypass Volume [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:17 2022 +0100

    ASoC: cs42l52: Correct TLV for Bypass Volume
    
    [ Upstream commit 91e90c712fade0b69cdff7cc6512f6099bd18ae5 ]
    
    The Bypass Volume is accidentally using a -6dB minimum TLV rather than
    the correct -60dB minimum. Add a new TLV to correct this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-5-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs42l52: Fix TLV scales for mixer controls [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:14 2022 +0100

    ASoC: cs42l52: Fix TLV scales for mixer controls
    
    [ Upstream commit 8bf5aabf524eec61013e506f764a0b2652dc5665 ]
    
    The datasheet specifies the range of the mixer volumes as between
    -51.5dB and 12dB with a 0.5dB step. Update the TLVs for this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-2-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs42l56: Correct typo in minimum level for SX volume controls [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:18 2022 +0100

    ASoC: cs42l56: Correct typo in minimum level for SX volume controls
    
    [ Upstream commit a8928ada9b96944cadd8b65d191e33199fd38782 ]
    
    A couple of the SX volume controls specify 0x84 as the lowest volume
    value, however the correct value from the datasheet is 0x44. The
    datasheet don't include spaces in the value it displays as binary so
    this was almost certainly just a typo reading 1000100.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-6-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs53l30: Correct number of volume levels on SX controls [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:16 2022 +0100

    ASoC: cs53l30: Correct number of volume levels on SX controls
    
    [ Upstream commit 7fbd6dd68127927e844912a16741016d432a0737 ]
    
    This driver specified the maximum value rather than the number of volume
    levels on the SX controls, this is incorrect, so correct them.
    
    Reported-by: David Rhodes <david.rhodes@cirrus.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-4-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: es8328: Fix event generation for deemphasis control [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jun 3 14:39:37 2022 +0200

    ASoC: es8328: Fix event generation for deemphasis control
    
    [ Upstream commit 8259610c2ec01c5cbfb61882ae176aabacac9c19 ]
    
    Currently the put() method for the deemphasis control returns 0 when a new
    value is written to the control even if the value changed, meaning events
    are not generated. Fix this, skip the work of updating the value when it is
    unchanged and then return 1 after having done so.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20220603123937.4013603-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: cirrus-common: fix incorrect channel mapping [+ + +]
Author: xliu <xiang.liu@cirrus.com>
Date:   Thu Jun 2 13:19:22 2022 +0800

    ASoC: Intel: cirrus-common: fix incorrect channel mapping
    
    [ Upstream commit d69a155555c9d57463b788c400f6b452d976bacd ]
    
    The default mapping of ASPRX1 (DAC source) is slot 0. Change the slot
    mapping of right amplifiers (WR and TR) to slot 1 to receive right
    channel data. Also update the ACPI instance ID mapping according to HW
    configuration.
    
    Signed-off-by: xliu <xiang.liu@cirrus.com>
    Signed-off-by: Brent Lu <brent.lu@intel.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220602051922.1232457-1-brent.lu@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: nau8822: Add operation for internal PLL off and on [+ + +]
Author: Hui Wang <hui.wang@canonical.com>
Date:   Mon May 30 12:01:50 2022 +0800

    ASoC: nau8822: Add operation for internal PLL off and on
    
    [ Upstream commit aeca8a3295022bcec46697f16e098140423d8463 ]
    
    We tried to enable the audio on an imx6sx EVB with the codec nau8822,
    after setting the internal PLL fractional parameters, the audio still
    couldn't work and the there was no sdma irq at all.
    
    After checking with the section "8.1.1 Phase Locked Loop (PLL) Design
    Example" of "NAU88C22 Datasheet Rev 0.6", we found we need to
    turn off the PLL before programming fractional parameters and turn on
    the PLL after programming.
    
    After this change, the audio driver could record and play sound and
    the sdma's irq is triggered when playing or recording.
    
    Cc: David Lin <ctlin0@nuvoton.com>
    Cc: John Hsu <kchsu0@nuvoton.com>
    Cc: Seven Li <wtli@nuvoton.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20220530040151.95221-2-hui.wang@canonical.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: qcom: lpass-platform: Update VMA access permissions in mmap callback [+ + +]
Author: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Date:   Fri May 27 19:40:08 2022 +0530

    ASoC: qcom: lpass-platform: Update VMA access permissions in mmap callback
    
    [ Upstream commit ef8d89b83bf453ea9cc3c4873a84b50ff334f797 ]
    
    Replace page protection permissions from noncashed to writecombine,
    in lpass codec DMA path mmp callabck, to support 64 bit chromeOS.
    Avoid SIGBUS error in userspace caused by noncached permissions in
    64 bit chromeOS.
    
    Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Link: https://lore.kernel.org/r/1653660608-27245-1-git-send-email-quic_srivasam@quicinc.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm8962: Fix suspend while playing music [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Thu May 26 13:21:28 2022 -0500

    ASoC: wm8962: Fix suspend while playing music
    
    [ Upstream commit d1f5272c0f7d2e53c6f2480f46725442776f5f78 ]
    
    If the audio CODEC is playing sound when the system is suspended,
    it can be left in a state which throws the following error:
    
    wm8962 3-001a: ASoC: error at soc_component_read_no_lock on wm8962.3-001a: -16
    
    Once this error has occurred, the audio will not work again until rebooted.
    
    Fix this by configuring SET_SYSTEM_SLEEP_PM_OPS.
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220526182129.538472-1-aford173@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm_adsp: Fix event generation for wm_adsp_fw_put() [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jun 3 13:50:03 2022 +0200

    ASoC: wm_adsp: Fix event generation for wm_adsp_fw_put()
    
    [ Upstream commit 2abdf9f80019e8244d3806ed0e1c9f725e50b452 ]
    
    Currently wm_adsp_fw_put() returns 0 rather than 1 when updating the value
    of the control, meaning that no event is generated to userspace. Fix this
    by setting the default return value to 1, the code already exits early with
    a return value of 0 if the value is unchanged.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220603115003.3865834-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() [+ + +]
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sat May 21 23:34:10 2022 +0300

    ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()
    
    [ Upstream commit bf476fe22aa1851bab4728e0c49025a6a0bea307 ]
    
    In an unlikely (and probably wrong?) case that the 'ppi' parameter of
    ata_host_alloc_pinfo() points to an array starting with a NULL pointer,
    there's going to be a kernel oops as the 'pi' local variable won't get
    reassigned from the initial value of NULL. Initialize 'pi' instead to
    '&ata_dummy_port_info' to fix the possible kernel oops for good...
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE static
    analysis tool.
    
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
audit: free module name [+ + +]
Author: Christian Göttsche <cgzones@googlemail.com>
Date:   Wed Jun 15 17:44:31 2022 +0200

    audit: free module name
    
    commit ef79c396c664be99d0c5660dc75fe863c1e20315 upstream.
    
    Reset the type of the record last as the helper `audit_free_module()`
    depends on it.
    
        unreferenced object 0xffff888153b707f0 (size 16):
          comm "modprobe", pid 1319, jiffies 4295110033 (age 1083.016s)
          hex dump (first 16 bytes):
            62 69 6e 66 6d 74 5f 6d 69 73 63 00 6b 6b 6b a5  binfmt_misc.kkk.
          backtrace:
            [<ffffffffa07dbf9b>] kstrdup+0x2b/0x50
            [<ffffffffa04b0a9d>] __audit_log_kern_module+0x4d/0xf0
            [<ffffffffa03b6664>] load_module+0x9d4/0x2e10
            [<ffffffffa03b8f44>] __do_sys_finit_module+0x114/0x1b0
            [<ffffffffa1f47124>] do_syscall_64+0x34/0x80
            [<ffffffffa200007e>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Cc: stable@vger.kernel.org
    Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts beyond syscalls")
    Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: Fix handling of offline queues in blk_mq_alloc_request_hctx() [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Jun 15 14:00:04 2022 -0700

    block: Fix handling of offline queues in blk_mq_alloc_request_hctx()
    
    [ Upstream commit 14dc7a18abbe4176f5626c13c333670da8e06aa1 ]
    
    This patch prevents that test nvme/004 triggers the following:
    
    UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9
    index 512 is out of range for type 'long unsigned int [512]'
    Call Trace:
     show_stack+0x52/0x58
     dump_stack_lvl+0x49/0x5e
     dump_stack+0x10/0x12
     ubsan_epilogue+0x9/0x3b
     __ubsan_handle_out_of_bounds.cold+0x44/0x49
     blk_mq_alloc_request_hctx+0x304/0x310
     __nvme_submit_sync_cmd+0x70/0x200 [nvme_core]
     nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics]
     nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop]
     nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop]
     nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics]
     nvmf_dev_write+0xae/0x111 [nvme_fabrics]
     vfs_write+0x144/0x560
     ksys_write+0xb7/0x140
     __x64_sys_write+0x42/0x50
     do_syscall_64+0x35/0x80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Ming Lei <ming.lei@redhat.com>
    Fixes: 20e4d8139319 ("blk-mq: simplify queue mapping & schedule with each possisble CPU")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20220615210004.1031820-1-bvanassche@acm.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Use safer kvmalloc_array() where possible [+ + +]
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 26 13:24:05 2022 +0300

    bpf: Use safer kvmalloc_array() where possible
    
    commit fd58f7df2415ef747782e01f94880fefad1247cf upstream.
    
    The kvmalloc_array() function is safer because it has a check for
    integer overflows.  These sizes come from the user and I was not
    able to see any bounds checking so an integer overflow seems like a
    realistic concern.
    
    Fixes: 0dcac2725406 ("bpf: Add multi kprobe link")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/Yo9VRVMeHbALyjUH@kili
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() [+ + +]
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date:   Wed Jun 1 19:51:59 2022 +0900

    bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()
    
    commit 928ea98252ad75118950941683893cf904541da9 upstream.
    
    In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to
    fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in
    fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io
    triggers KASAN use-after-free. To avoid the use-after-free, keep the
    reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to
    fsl_destroy_mc_io().
    
    This patch needs rework to apply to kernels older than v5.15.
    
    Fixes: f93627146f0e ("staging: fsl-mc: fix asymmetry in destroy of mc_io")
    Cc: stable@vger.kernel.org # v5.15+
    Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Link: https://lore.kernel.org/r/20220601105159.87752-1-shinichiro.kawasaki@wdc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
certs/blacklist_hashes.c: fix const confusion in certs blacklist [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Jun 12 02:22:30 2022 +0900

    certs/blacklist_hashes.c: fix const confusion in certs blacklist
    
    [ Upstream commit 6a1c3767d82ed8233de1263aa7da81595e176087 ]
    
    This file fails to compile as follows:
    
      CC      certs/blacklist_hashes.o
    certs/blacklist_hashes.c:4:1: error: ignoring attribute ‘section (".init.data")’ because it conflicts with previous ‘section (".init.rodata")’ [-Werror=attributes]
        4 | const char __initdata *const blacklist_hashes[] = {
          | ^~~~~
    In file included from certs/blacklist_hashes.c:2:
    certs/blacklist.h:5:38: note: previous declaration here
        5 | extern const char __initconst *const blacklist_hashes[];
          |                                      ^~~~~~~~~~~~~~~~
    
    Apply the same fix as commit 2be04df5668d ("certs/blacklist_nohashes.c:
    fix const confusion in certs blacklist").
    
    Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Reviewed-by: Mickaël Salaün <mic@linux.microsoft.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cfi: Fix __cfi_slowpath_diag RCU usage with cpuidle [+ + +]
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Tue May 31 10:59:10 2022 -0700

    cfi: Fix __cfi_slowpath_diag RCU usage with cpuidle
    
    commit 57cd6d157eb479f0a8e820fd36b7240845c8a937 upstream.
    
    RCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalid
    RCU state in the cpuidle code path:
    
      WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138
      ...
      Call trace:
        rcu_eqs_enter+0xe4/0x138
        rcu_idle_enter+0xa8/0x100
        cpuidle_enter_state+0x154/0x3a8
        cpuidle_enter+0x3c/0x58
        do_idle.llvm.6590768638138871020+0x1f4/0x2ec
        cpu_startup_entry+0x28/0x2c
        secondary_start_kernel+0x1b8/0x220
        __secondary_switched+0x94/0x98
    
    Instead, call rcu_irq_enter/exit to wake up RCU only when needed and
    disable interrupts for the entire CFI shadow/module check when we do.
    
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Link: https://lore.kernel.org/r/20220531175910.890307-1-samitolvanen@google.com
    Fixes: cf68fffb66d6 ("add support for Clang CFI")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clk: imx8mp: fix usb_root_clk parent [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sat May 7 20:54:30 2022 +0800

    clk: imx8mp: fix usb_root_clk parent
    
    commit cf7f3f4fa9e57b8e9f594823e77e6cbb0ce2b254 upstream.
    
    According to reference mannual CCGR77(usb) sources from hsio_axi, fix
    it.
    
    Fixes: 9c140d9926761 ("clk: imx: Add support for i.MX8MP clock driver")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
    Link: https://lore.kernel.org/r/20220507125430.793287-1-peng.fan@oss.nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clocksource: hyper-v: unexport __init-annotated hv_init_clocksource() [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 14:02:38 2022 +0900

    clocksource: hyper-v: unexport __init-annotated hv_init_clocksource()
    
    [ Upstream commit 245b993d8f6c4e25f19191edfbd8080b645e12b1 ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the only in-tree call-site,
    arch/x86/kernel/cpu/mshyperv.c is never compiled as modular.
    (CONFIG_HYPERVISOR_GUEST is boolean)
    
    Fixes: dd2cb348613b ("clocksource/drivers: Continue making Hyper-V clocksource ISA agnostic")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Link: https://lore.kernel.org/r/20220606050238.4162200-1-masahiroy@kernel.org
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
comedi: vmk80xx: fix expression for tx buffer size [+ + +]
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jun 7 18:18:19 2022 +0100

    comedi: vmk80xx: fix expression for tx buffer size
    
    commit 242439f7e279d86b3f73b5de724bc67b2f8aeb07 upstream.
    
    The expression for setting the size of the allocated bulk TX buffer
    (`devpriv->usb_tx_buf`) is calling `usb_endpoint_maxp(devpriv->ep_rx)`,
    which is using the wrong endpoint (should be `devpriv->ep_tx`).  Fix it.
    
    Fixes: a23461c47482 ("comedi: vmk80xx: fix transfer-buffer overflow")
    Cc: Johan Hovold <johan@kernel.org>
    Cc: stable@vger.kernel.org # 4.9+
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20220607171819.4121-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
crypto: memneq - move into lib/ [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat May 28 12:24:29 2022 +0200

    crypto: memneq - move into lib/
    
    commit abfed87e2a12bd246047d78c01d81eb9529f1d06 upstream.
    
    This is used by code that doesn't need CONFIG_CRYPTO, so move this into
    lib/ with a Kconfig option so that it can be selected by whatever needs
    it.
    
    This fixes a linker error Zheng pointed out when
    CRYPTO_MANAGER_DISABLE_TESTS!=y and CRYPTO=m:
    
      lib/crypto/curve25519-selftest.o: In function `curve25519_selftest':
      curve25519-selftest.c:(.init.text+0x60): undefined reference to `__crypto_memneq'
      curve25519-selftest.c:(.init.text+0xec): undefined reference to `__crypto_memneq'
      curve25519-selftest.c:(.init.text+0x114): undefined reference to `__crypto_memneq'
      curve25519-selftest.c:(.init.text+0x154): undefined reference to `__crypto_memneq'
    
    Reported-by: Zheng Bin <zhengbin13@huawei.com>
    Cc: Eric Biggers <ebiggers@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: aa127963f1ca ("crypto: lib/curve25519 - re-add selftests")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm mirror log: round up region bitmap size to BITS_PER_LONG [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jun 16 13:28:57 2022 -0400

    dm mirror log: round up region bitmap size to BITS_PER_LONG
    
    commit 85e123c27d5cbc22cfdc01de1e2ca1d9003a02d0 upstream.
    
    The code in dm-log rounds up bitset_size to 32 bits. It then uses
    find_next_zero_bit_le on the allocated region. find_next_zero_bit_le
    accesses the bitmap using unsigned long pointers. So, on 64-bit
    architectures, it may access 4 bytes beyond the allocated size.
    
    Fix this bug by rounding up bitset_size to BITS_PER_LONG.
    
    This bug was found by running the lvm2 testsuite with kasan.
    
    Fixes: 29121bd0b00e ("[PATCH] dm mirror log: bitset_size fix")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm: fix bio_set allocation [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Jun 8 08:34:06 2022 +0200

    dm: fix bio_set allocation
    
    commit 29dec90a0f1d961b93f34f910e9319d8cb23edbd upstream.
    
    The use of bioset_init_from_src mean that the pre-allocated pools weren't
    used for anything except parameter passing, and the integrity pool
    creation got completely lost for the actual live mapped_device.  Fix that
    by assigning the actual preallocated dm_md_mempools to the mapped_device
    and using that for I/O instead of creating new mempools.
    
    Fixes: 2a2a4c510b76 ("dm: use bioset_init_from_src() to copy bio_set")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm: fix race in dm_start_io_acct [+ + +]
Author: Benjamin Marzinski <bmarzins@redhat.com>
Date:   Tue Jun 14 11:10:28 2022 -0500

    dm: fix race in dm_start_io_acct
    
    commit 10eb3a0d517fcc83eeea4242c149461205675eb4 upstream.
    
    After commit 82f6cdcc3676c ("dm: switch dm_io booleans over to proper
    flags") dm_start_io_acct stopped atomically checking and setting
    was_accounted, which turned into the DM_IO_ACCOUNTED flag. This opened
    the possibility for a race where IO accounting is started twice for
    duplicate bios. To remove the race, check the flag while holding the
    io->lock.
    
    Fixes: 82f6cdcc3676c ("dm: switch dm_io booleans over to proper flags")
    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dma-debug: make things less spammy under memory pressure [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Wed Jun 1 07:51:16 2022 -0700

    dma-debug: make things less spammy under memory pressure
    
    [ Upstream commit e19f8fa6ce1ca9b8b934ba7d2e8f34c95abc6e60 ]
    
    Limit the error msg to avoid flooding the console.  If you have a lot of
    threads hitting this at once, they could have already gotten passed the
    dma_debug_disabled() check before they get to the point of allocation
    failure, resulting in quite a lot of this error message spamming the
    log.  Use pr_err_once() to limit that.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Drivers: hv: vmbus: Release cpu lock in error case [+ + +]
Author: Saurabh Sengar <ssengar@linux.microsoft.com>
Date:   Thu Jun 9 10:16:36 2022 -0700

    Drivers: hv: vmbus: Release cpu lock in error case
    
    [ Upstream commit 656c5ba50b7172a0ea25dc1b37606bd51d01fe8d ]
    
    In case of invalid sub channel, release cpu lock before returning.
    
    Fixes: a949e86c0d780 ("Drivers: hv: vmbus: Resolve race between init_vp_index() and CPU hotplug")
    Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Link: https://lore.kernel.org/r/1654794996-13244-1-git-send-email-ssengar@linux.microsoft.com
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Cap OLED brightness per max frame-average luminance [+ + +]
Author: Roman Li <roman.li@amd.com>
Date:   Thu May 19 14:41:16 2022 -0400

    drm/amd/display: Cap OLED brightness per max frame-average luminance
    
    commit 4fd17f2ac0aa4e48823ac2ede5b050fb70300bf4 upstream.
    
    [Why]
    For OLED eDP the Display Manager uses max_cll value as a limit
    for brightness control.
    max_cll defines the content light luminance for individual pixel.
    Whereas max_fall defines frame-average level luminance.
    The user may not observe the difference in brightness in between
    max_fall and max_cll.
    That negatively impacts the user experience.
    
    [How]
    Use max_fall value instead of max_cll as a limit for brightness control.
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Roman Li <roman.li@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Read Golden Settings Table from VBIOS [+ + +]
Author: Sherry Wang <YAO.WANG1@amd.com>
Date:   Tue May 10 18:42:18 2022 +0800

    drm/amd/display: Read Golden Settings Table from VBIOS
    
    [ Upstream commit 4b81dd2cc6f4f4e8cea0ed6ee8d5193a8ae14a72 ]
    
    [Why]
    Dmub read AUX_DPHY_RX_CONTROL0 from Golden Setting Table,
    but driver will set it to default value 0x103d1110, which
    causes issue in some case
    
    [How]
    Remove the driver code, use the value set by dmub in
    dp_aux_init
    
    Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
    Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Sherry Wang <YAO.WANG1@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: Fix GTT size reporting in amdgpu_ioctl [+ + +]
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Jun 10 15:54:26 2022 +0200

    drm/amdgpu: Fix GTT size reporting in amdgpu_ioctl
    
    commit c904e3acbab3fd97649cd4ab1ff7f1521ad3a255 upstream.
    
    The commit below changed the TTM manager size unit from pages to
    bytes, but failed to adjust the corresponding calculations in
    amdgpu_ioctl.
    
    Fixes: dfa714b88eb0 ("drm/amdgpu: remove GTT accounting v2")
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1930
    Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6642
    Tested-by: Martin Roukala <martin.roukala@mupuf.org>
    Tested-by: Mike Lothian <mike@fireburn.co.uk>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 5.18.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Resolve RAS GFX error count issue after cold boot on Arcturus [+ + +]
Author: Candice Li <candice.li@amd.com>
Date:   Wed Jun 1 17:10:44 2022 +0800

    drm/amdgpu: Resolve RAS GFX error count issue after cold boot on Arcturus
    
    [ Upstream commit 2a460963350ec6b1534d28d7f943b5f84815aff2 ]
    
    Adjust the sequence for ras late init and separate ras reset error status
    from query status.
    
    v2: squash in fix from Candice
    
    Signed-off-by: Candice Li <candice.li@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdkfd: add pinned BOs to kfd_bo_list [+ + +]
Author: Lang Yu <Lang.Yu@amd.com>
Date:   Tue May 31 09:19:43 2022 +0800

    drm/amdkfd: add pinned BOs to kfd_bo_list
    
    [ Upstream commit 4fac4fcf4500bce515b0f32195e7bb86aa0246c6 ]
    
    The kfd_bo_list is used to restore process BOs after
    evictions. As page tables could be destroyed during
    evictions, we should also update pinned BOs' page tables
    during restoring to make sure they are valid.
    
    So for pinned BOs,
    1, Validate them and update their page tables.
    2, Don't add eviction fence for them.
    
    v2:
     - Don't handle pinned ones specially in BO validation.(Felix)
    
    Signed-off-by: Lang Yu <Lang.Yu@amd.com>
    Acked-by: Christian König <christian.koenig@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/amdkfd: Use mmget_not_zero in MMU notifier [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Thu May 26 16:15:38 2022 -0400

    drm/amdkfd: Use mmget_not_zero in MMU notifier
    
    [ Upstream commit fa582c6f3684ac0098a9d02ddf0ed52a02b37127 ]
    
    MMU notifier callback may pass in mm with mm->mm_users==0 when process
    is exiting, use mmget_no_zero to avoid accessing invalid mm in deferred
    list work after mm is gone.
    
    Signed-off-by: Philip Yang <Philip.Yang@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/i915/reset: Fix error_state_read ptr + offset use [+ + +]
Author: Alan Previn <alan.previn.teres.alexis@intel.com>
Date:   Thu Mar 10 16:43:11 2022 -0800

    drm/i915/reset: Fix error_state_read ptr + offset use
    
    [ Upstream commit c9b576d0c7bf55aeae1a736da7974fa202c4394d ]
    
    Fix our pointer offset usage in error_state_read
    when there is no i915_gpu_coredump but buf offset
    is non-zero.
    
    This fixes a kernel page fault can happen when
    multiple tests are running concurrently in a loop
    and one is producing engine resets and consuming
    the i915 error_state dump while the other is
    forcing full GT resets. (takes a while to trigger).
    
    The dmesg call trace:
    
    [ 5590.803000] BUG: unable to handle page fault for address:
                   ffffffffa0b0e000
    [ 5590.803009] #PF: supervisor read access in kernel mode
    [ 5590.803013] #PF: error_code(0x0000) - not-present page
    [ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067
                   PTE 0
    [ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [ 5590.803026] CPU: 5 PID: 13656 Comm: i915_hangman Tainted: G U
                        5.17.0-rc5-ups69-guc-err-capt-rev6+ #136
    [ 5590.803033] Hardware name: Intel Corporation Alder Lake Client
                        Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00.
                        3031.A02.2201171222 01/17/2022
    [ 5590.803039] RIP: 0010:memcpy_erms+0x6/0x10
    [ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1
                         48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3
                         66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4
                         c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20
                         72 7e 40 38 fe
    [ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282
    [ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00
                   RCX: 0000000000000f8f
    [ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000
                   RDI: ffff888107ee9071
    [ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001
                   R09: 0000000000000001
    [ 5590.803069] R10: 0000000000000001 R11: 0000000000000002
                   R12: 0000000000000019
    [ 5590.803073] R13: 0000000000174fff R14: 0000000000001000
                   R15: ffff888107ee9000
    [ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000)
                   knlGS:0000000000000000
    [ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004
                   CR4: 0000000000770ee0
    [ 5590.803089] PKRU: 55555554
    [ 5590.803091] Call Trace:
    [ 5590.803093] <TASK>
    [ 5590.803096] error_state_read+0xa1/0xd0 [i915]
    [ 5590.803175] kernfs_fop_read_iter+0xb2/0x1b0
    [ 5590.803180] new_sync_read+0x116/0x1a0
    [ 5590.803185] vfs_read+0x114/0x1b0
    [ 5590.803189] ksys_read+0x63/0xe0
    [ 5590.803193] do_syscall_64+0x38/0xc0
    [ 5590.803197] entry_SYSCALL_64_after_hwframe+0x44/0xae
    [ 5590.803201] RIP: 0033:0x7f62aaea5912
    [ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05
                         19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25
                         18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff
                         ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
    [ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246
                   ORIG_RAX: 0000000000000000
    [ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000
                   RCX: 00007f62aaea5912
    [ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f
                   RDI: 0000000000000006
    [ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010
                   R09: 0000000000101000
    [ 5590.803229] R10: 0000000000000001 R11: 0000000000000246
                   R12: 0000000000000006
    [ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010
                   R15: 0000000000200000
    [ 5590.803238] </TASK>
    [ 5590.803240] Modules linked in: i915 ttm drm_buddy drm_dp_helper
                            drm_kms_helper syscopyarea sysfillrect sysimgblt
                            fb_sys_fops prime_numbers nfnetlink br_netfilter
                            overlay mei_pxp mei_hdcp x86_pkg_temp_thermal
                            coretemp kvm_intel snd_hda_codec_hdmi snd_hda_intel
                            snd_intel_dspcfg snd_hda_codec snd_hwdep
                            snd_hda_core snd_pcm mei_me mei fuse ip_tables
                            x_tables crct10dif_pclmul e1000e crc32_pclmul ptp
                            i2c_i801 ghash_clmulni_intel i2c_smbus pps_core
                            [last unloa ded: ttm]
    [ 5590.803277] CR2: ffffffffa0b0e000
    [ 5590.803280] ---[ end trace 0000000000000000 ]---
    
    Fixes: 0e39037b3165 ("drm/i915: Cache the error string")
    Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
    Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
    Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220311004311.514198-2-alan.previn.teres.alexis@intel.com
    (cherry picked from commit 3304033a1e69cd81a2044b4422f0d7e593afb4e6)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/uc: remove accidental static from a local variable [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed May 11 12:46:19 2022 +0300

    drm/i915/uc: remove accidental static from a local variable
    
    commit 2636e008112465ca54559ac4898da5a2515e118a upstream.
    
    The arrays are static const, but the pointer shouldn't be static.
    
    Fixes: 3d832f370d16 ("drm/i915/uc: Allow platforms to have GuC but not HuC")
    Cc: John Harrison <John.C.Harrison@Intel.com>
    Cc: Lucas De Marchi <lucas.demarchi@intel.com>
    Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220511094619.27889-1-jani.nikula@intel.com
    (cherry picked from commit 5821a0bbb4c39960975d29d6b58ae290088db0ed)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dt-bindings: interrupt-controller: update brcm,l2-intc.yaml reference [+ + +]
Author: Mauro Carvalho Chehab <mchehab@kernel.org>
Date:   Mon Jun 6 16:25:24 2022 +0100

    dt-bindings: interrupt-controller: update brcm,l2-intc.yaml reference
    
    commit 7e40381d8a33e41e347cea5bdd000091653000c6 upstream.
    
    Changeset 539d25b21fe8 ("dt-bindings: interrupt-controller: Convert Broadcom STB L2 to YAML")
    renamed: Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
    to: Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.yaml.
    
    Update its cross-reference accordingly.
    
    Fixes: 539d25b21fe8 ("dt-bindings: interrupt-controller: Convert Broadcom STB L2 to YAML")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/a40c02a7aaea91ea7b6ce24b6bc574ae5bcf4cf6.1654529011.git.mchehab@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dt-bindings: mfd: bd9571mwv: update rohm,bd9571mwv.yaml reference [+ + +]
Author: Mauro Carvalho Chehab <mchehab@kernel.org>
Date:   Mon Jun 6 16:25:23 2022 +0100

    dt-bindings: mfd: bd9571mwv: update rohm,bd9571mwv.yaml reference
    
    commit e0b5c5984d4810733b7c24a3d16c904fffc086d2 upstream.
    
    Changeset 983b62975e90 ("dt-bindings: mfd: bd9571mwv: Convert to json-schema")
    renamed: Documentation/devicetree/bindings/mfd/bd9571mwv.txt
    to: Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml.
    
    Update its cross-reference accordingly.
    
    Fixes: 983b62975e90 ("dt-bindings: mfd: bd9571mwv: Convert to json-schema")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/1906a4d935eab57c10ce09358eae02175ce4abb7.1654529011.git.mchehab@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ext4: add reserved GDT blocks check [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Wed Jun 1 17:27:17 2022 +0800

    ext4: add reserved GDT blocks check
    
    commit b55c3cd102a6f48b90e61c44f7f3dda8c290c694 upstream.
    
    We capture a NULL pointer issue when resizing a corrupt ext4 image which
    is freshly clear resize_inode feature (not run e2fsck). It could be
    simply reproduced by following steps. The problem is because of the
    resize_inode feature was cleared, and it will convert the filesystem to
    meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
    not reduced to zero, so could we mistakenly call reserve_backup_gdb()
    and passing an uninitialized resize_inode to it when adding new group
    descriptors.
    
     mkfs.ext4 /dev/sda 3G
     tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
     mount /dev/sda /mnt
     resize2fs /dev/sda 8G
    
     ========
     BUG: kernel NULL pointer dereference, address: 0000000000000028
     CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
     ...
     RIP: 0010:ext4_flex_group_add+0xe08/0x2570
     ...
     Call Trace:
      <TASK>
      ext4_resize_fs+0xbec/0x1660
      __ext4_ioctl+0x1749/0x24e0
      ext4_ioctl+0x12/0x20
      __x64_sys_ioctl+0xa6/0x110
      do_syscall_64+0x3b/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f2dd739617b
     ========
    
    The fix is simple, add a check in ext4_resize_begin() to make sure that
    the es->s_reserved_gdt_blocks is zero when the resize_inode feature is
    disabled.
    
    Cc: stable@kernel.org
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220601092717.763694-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix bug_on ext4_mb_use_inode_pa [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Sat May 28 19:00:15 2022 +0800

    ext4: fix bug_on ext4_mb_use_inode_pa
    
    commit a08f789d2ab5242c07e716baf9a835725046be89 upstream.
    
    Hulk Robot reported a BUG_ON:
    ==================================================================
    kernel BUG at fs/ext4/mballoc.c:3211!
    [...]
    RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f
    [...]
    Call Trace:
     ext4_mb_new_blocks+0x9df/0x5d30
     ext4_ext_map_blocks+0x1803/0x4d80
     ext4_map_blocks+0x3a4/0x1a10
     ext4_writepages+0x126d/0x2c30
     do_writepages+0x7f/0x1b0
     __filemap_fdatawrite_range+0x285/0x3b0
     file_write_and_wait_range+0xb1/0x140
     ext4_sync_file+0x1aa/0xca0
     vfs_fsync_range+0xfb/0x260
     do_fsync+0x48/0xa0
    [...]
    ==================================================================
    
    Above issue may happen as follows:
    -------------------------------------
    do_fsync
     vfs_fsync_range
      ext4_sync_file
       file_write_and_wait_range
        __filemap_fdatawrite_range
         do_writepages
          ext4_writepages
           mpage_map_and_submit_extent
            mpage_map_one_extent
             ext4_map_blocks
              ext4_mb_new_blocks
               ext4_mb_normalize_request
                >>> start + size <= ac->ac_o_ex.fe_logical
               ext4_mb_regular_allocator
                ext4_mb_simple_scan_group
                 ext4_mb_use_best_found
                  ext4_mb_new_preallocation
                   ext4_mb_new_inode_pa
                    ext4_mb_use_inode_pa
                     >>> set ac->ac_b_ex.fe_len <= 0
               ext4_mb_mark_diskspace_used
                >>> BUG_ON(ac->ac_b_ex.fe_len <= 0);
    
    we can easily reproduce this problem with the following commands:
            `fallocate -l100M disk`
            `mkfs.ext4 -b 1024 -g 256 disk`
            `mount disk /mnt`
            `fsstress -d /mnt -l 0 -n 1000 -p 1`
    
    The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP.
    Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur
    when the size is truncated. So start should be the start position of
    the group where ac_o_ex.fe_logical is located after alignment.
    In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP
    is very large, the value calculated by start_off is more accurate.
    
    Cc: stable@kernel.org
    Fixes: cd648b8a8fd5 ("ext4: trim allocation requests to group size")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220528110017.354175-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix super block checksum incorrect after mount [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed May 25 09:29:04 2022 +0800

    ext4: fix super block checksum incorrect after mount
    
    commit 9b6641dd95a0c441b277dd72ba22fed8d61f76ad upstream.
    
    We got issue as follows:
    [home]# mount  /dev/sda  test
    EXT4-fs (sda): warning: mounting fs with errors, running e2fsck is recommended
    [home]# dmesg
    EXT4-fs (sda): warning: mounting fs with errors, running e2fsck is recommended
    EXT4-fs (sda): Errors on filesystem, clearing orphan list.
    EXT4-fs (sda): recovery complete
    EXT4-fs (sda): mounted filesystem with ordered data mode. Quota mode: none.
    [home]# debugfs /dev/sda
    debugfs 1.46.5 (30-Dec-2021)
    Checksum errors in superblock!  Retrying...
    
    Reason is ext4_orphan_cleanup will reset ‘s_last_orphan’ but not update
    super block checksum.
    
    To solve above issue, defer update super block checksum after
    ext4_orphan_cleanup.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Cc: stable@kernel.org
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220525012904.1604737-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: make variable "count" signed [+ + +]
Author: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date:   Mon May 30 18:00:47 2022 +0800

    ext4: make variable "count" signed
    
    commit bc75a6eb856cb1507fa907bf6c1eda91b3fef52f upstream.
    
    Since dx_make_map() may return -EFSCORRUPTED now, so change "count" to
    be a signed integer so we can correctly check for an error code returned
    by dx_make_map().
    
    Fixes: 46c116b920eb ("ext4: verify dir block before splitting it")
    Cc: stable@kernel.org
    Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
    Link: https://lore.kernel.org/r/20220530100047.537598-1-dingxiang@cmss.chinamobile.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
faddr2line: Fix overlapping text section failures, the sequel [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Jun 1 17:42:22 2022 -0700

    faddr2line: Fix overlapping text section failures, the sequel
    
    [ Upstream commit dcea997beed694cbd8705100ca1a6eb0d886de69 ]
    
    If a function lives in a section other than .text, but .text also exists
    in the object, faddr2line may wrongly assume .text.  This can result in
    comically wrong output.  For example:
    
      $ scripts/faddr2line vmlinux.o enter_from_user_mode+0x1c
      enter_from_user_mode+0x1c/0x30:
      find_next_bit at /home/jpoimboe/git/linux/./include/linux/find.h:40
      (inlined by) perf_clear_dirty_counters at /home/jpoimboe/git/linux/arch/x86/events/core.c:2504
    
    Fix it by passing the section name to addr2line, unless the object file
    is vmlinux, in which case the symbol table uses absolute addresses.
    
    Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures")
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Link: https://lore.kernel.org/r/7d25bc1408bd3a750ac26e60d2f2815a5f4a8363.1654130536.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: account for group membership [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Mon Jun 13 13:15:17 2022 +0200

    fs: account for group membership
    
    commit 168f912893407a5acb798a4a58613b5f1f98c717 upstream.
    
    When calling setattr_prepare() to determine the validity of the
    attributes the ia_{g,u}id fields contain the value that will be written
    to inode->i_{g,u}id. This is exactly the same for idmapped and
    non-idmapped mounts and allows callers to pass in the values they want
    to see written to inode->i_{g,u}id.
    
    When group ownership is changed a caller whose fsuid owns the inode can
    change the group of the inode to any group they are a member of. When
    searching through the caller's groups we need to use the gid mapped
    according to the idmapped mount otherwise we will fail to change
    ownership for unprivileged users.
    
    Consider a caller running with fsuid and fsgid 1000 using an idmapped
    mount that maps id 65534 to 1000 and 65535 to 1001. Consequently, a file
    owned by 65534:65535 in the filesystem will be owned by 1000:1001 in the
    idmapped mount.
    
    The caller now requests the gid of the file to be changed to 1000 going
    through the idmapped mount. In the vfs we will immediately map the
    requested gid to the value that will need to be written to inode->i_gid
    and place it in attr->ia_gid. Since this idmapped mount maps 65534 to
    1000 we place 65534 in attr->ia_gid.
    
    When we check whether the caller is allowed to change group ownership we
    first validate that their fsuid matches the inode's uid. The
    inode->i_uid is 65534 which is mapped to uid 1000 in the idmapped mount.
    Since the caller's fsuid is 1000 we pass the check.
    
    We now check whether the caller is allowed to change inode->i_gid to the
    requested gid by calling in_group_p(). This will compare the passed in
    gid to the caller's fsgid and search the caller's additional groups.
    
    Since we're dealing with an idmapped mount we need to pass in the gid
    mapped according to the idmapped mount. This is akin to checking whether
    a caller is privileged over the future group the inode is owned by. And
    that needs to take the idmapped mount into account. Note, all helpers
    are nops without idmapped mounts.
    
    New regression test sent to xfstests.
    
    Link: https://github.com/lxc/lxd/issues/10537
    Link: https://lore.kernel.org/r/20220613111517.2186646-1-brauner@kernel.org
    Fixes: 2f221d6f7b88 ("attr: handle idmapped mounts")
    Cc: Seth Forshee <sforshee@digitalocean.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Aleksa Sarai <cyphar@cyphar.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: stable@vger.kernel.org # 5.15+
    CC: linux-fsdevel@vger.kernel.org
    Reviewed-by: Seth Forshee <sforshee@digitalocean.com>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gcc-12: disable '-Warray-bounds' universally for now [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 9 10:11:12 2022 -0700

    gcc-12: disable '-Warray-bounds' universally for now
    
    [ Upstream commit f0be87c42cbd341d436d06da4792e6b0c83c3aeb ]
    
    In commit 8b202ee21839 ("s390: disable -Warray-bounds") the s390 people
    disabled the '-Warray-bounds' warning for gcc-12, because the new logic
    in gcc would cause warnings for their use of the S390_lowcore macro,
    which accesses absolute pointers.
    
    It turns out gcc-12 has many other issues in this area, so this takes
    that s390 warning disable logic, and turns it into a kernel build config
    entry instead.
    
    Part of the intent is that we can make this all much more targeted, and
    use this conflig flag to disable it in only particular configurations
    that cause problems, with the s390 case as an example:
    
            select GCC12_NO_ARRAY_BOUNDS
    
    and we could do that for other configuration cases that cause issues.
    
    Or we could possibly use the CONFIG_CC_NO_ARRAY_BOUNDS thing in a more
    targeted way, and disable the warning only for particular uses: again
    the s390 case as an example:
    
      KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)
    
    but this ends up just doing it globally in the top-level Makefile, since
    the current issues are spread fairly widely all over:
    
      KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
    
    We'll try to limit this later, since the gcc-12 problems are rare enough
    that *much* of the kernel can be built with it without disabling this
    warning.
    
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gcc-12: disable '-Wdangling-pointer' warning for now [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 9 09:41:42 2022 -0700

    gcc-12: disable '-Wdangling-pointer' warning for now
    
    [ Upstream commit 49beadbd47c270a00754c107a837b4f29df4c822 ]
    
    While the concept of checking for dangling pointers to local variables
    at function exit is really interesting, the gcc-12 implementation is not
    compatible with reality, and results in false positives.
    
    For example, gcc sees us putting things on a local list head allocated
    on the stack, which involves exactly those kinds of pointers to the
    local stack entry:
    
      In function ‘__list_add’,
          inlined from ‘list_add_tail’ at include/linux/list.h:102:2,
          inlined from ‘rebuild_snap_realms’ at fs/ceph/snap.c:434:2:
      include/linux/list.h:74:19: warning: storing the address of local variable ‘realm_queue’ in ‘*&realm_27(D)->rebuild_item.prev’ [-Wdangling-pointer=]
         74 |         new->prev = prev;
            |         ~~~~~~~~~~^~~~~~
    
    But then gcc - understandably - doesn't really understand the big
    picture how the doubly linked list works, so doesn't see how we then end
    up emptying said list head in a loop and the pointer we added has been
    removed.
    
    Gcc also complains about us (intentionally) using this as a way to store
    a kind of fake stack trace, eg
    
      drivers/acpi/acpica/utdebug.c:40:38: warning: storing the address of local variable ‘current_sp’ in ‘acpi_gbl_entry_stack_pointer’ [-Wdangling-pointer=]
         40 |         acpi_gbl_entry_stack_pointer = ¤t_sp;
            |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
    
    which is entirely reasonable from a compiler standpoint, and we may want
    to change those kinds of patterns, but not not.
    
    So this is one of those "it would be lovely if the compiler were to
    complain about us leaving dangling pointers to the stack", but not this
    way.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: dwapb: Don't print error on -EPROBE_DEFER [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 10 13:45:00 2022 +0300

    gpio: dwapb: Don't print error on -EPROBE_DEFER
    
    [ Upstream commit 77006f6edc0e0f58617eb25e53731f78641e820d ]
    
    Currently if the APB or Debounce clocks aren't yet ready to be requested
    the DW GPIO driver will correctly handle that by deferring the probe
    procedure, but the error is still printed to the system log. It needlessly
    pollutes the log since there was no real error but a request to postpone
    the clock request procedure since the clocks subsystem hasn't been fully
    initialized yet. Let's fix that by using the dev_err_probe method to print
    the APB/clock request error status. It will correctly handle the deferred
    probe situation and print the error if it actually happens.
    
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: designware: Use standard optional ref clock implementation [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 10 10:42:33 2022 +0300

    i2c: designware: Use standard optional ref clock implementation
    
    [ Upstream commit 27071b5cbca59d8e8f8750c199a6cbf8c9799963 ]
    
    Even though the DW I2C controller reference clock source is requested by
    the method devm_clk_get() with non-optional clock requirement the way the
    clock handler is used afterwards has a pure optional clock semantic
    (though in some circumstances we can get a warning about the clock missing
    printed in the system console). There is no point in reimplementing that
    functionality seeing the kernel clock framework already supports the
    optional interface from scratch. Thus let's convert the platform driver to
    using it.
    
    Note by providing this commit we get to fix two problems. The first one
    was introduced in commit c62ebb3d5f0d ("i2c: designware: Add support for
    an interface clock"). It causes not having the interface clock (pclk)
    enabled/disabled in case if the reference clock isn't provided. The second
    problem was first introduced in commit b33af11de236 ("i2c: designware: Do
    not require clock when SSCN and FFCN are provided"). Since that
    modification the deferred probe procedure has been unsupported in case if
    the interface clock isn't ready.
    
    Fixes: c62ebb3d5f0d ("i2c: designware: Add support for an interface clock")
    Fixes: b33af11de236 ("i2c: designware: Do not require clock when SSCN and FFCN are provided")
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: mediatek: Fix an error handling path in mtk_i2c_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun May 22 14:22:07 2022 +0200

    i2c: mediatek: Fix an error handling path in mtk_i2c_probe()
    
    [ Upstream commit de87b603b0919e31578c8fa312a3541f1fb37e1c ]
    
    The clsk are prepared, enabled, then disabled. So if an error occurs after
    the disable step, they are still prepared.
    
    Add an error handling path to unprepare the clks in such a case, as already
    done in the .remove function.
    
    Fixes: 8b4fc246c3ff ("i2c: mediatek: Optimize master_xfer() and avoid circular locking")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Qii Wang <qii.wang@mediatek.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: npcm7xx: Add check for platform_driver_register [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu May 26 17:41:00 2022 +0800

    i2c: npcm7xx: Add check for platform_driver_register
    
    [ Upstream commit 6ba12b56b9b844b83ed54fb7ed59fb0eb41e4045 ]
    
    As platform_driver_register() could fail, it should be better
    to deal with the return value in order to maintain the code
    consisitency.
    
    Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Tali Perry <tali.perry1@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Fix adding ADQ filter to TC0 [+ + +]
Author: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
Date:   Fri Apr 29 14:27:08 2022 +0200

    i40e: Fix adding ADQ filter to TC0
    
    [ Upstream commit c3238d36c3a2be0a29a9d848d6c51e1b14be6692 ]
    
    Procedure of configure tc flower filters erroneously allows to create
    filters on TC0 where unfiltered packets are also directed by default.
    Issue was caused by insufficient checks of hw_tc parameter specifying
    the hardware traffic class to pass matching packets to.
    
    Fix checking hw_tc parameter which blocks creation of filters on TC0.
    
    Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Fix calculating the number of queue pairs [+ + +]
Author: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
Date:   Fri Apr 29 14:40:23 2022 +0200

    i40e: Fix calculating the number of queue pairs
    
    [ Upstream commit 0bb050670ac90a167ecfa3f9590f92966c9a3677 ]
    
    If ADQ is enabled for a VF, then actual number of queue pair
    is a number of currently available traffic classes for this VF.
    
    Without this change the configuration of the Rx/Tx queues
    fails with error.
    
    Fixes: d29e0d233e0d ("i40e: missing input validation on VF message handling by the PF")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Fix call trace in setup_tx_descriptors [+ + +]
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Thu May 19 16:01:45 2022 +0200

    i40e: Fix call trace in setup_tx_descriptors
    
    [ Upstream commit fd5855e6b1358e816710afee68a1d2bc685176ca ]
    
    After PF reset and ethtool -t there was call trace in dmesg
    sometimes leading to panic. When there was some time, around 5
    seconds, between reset and test there were no errors.
    
    Problem was that pf reset calls i40e_vsi_close in prep_for_reset
    and ethtool -t calls i40e_vsi_close in diag_test. If there was not
    enough time between those commands the second i40e_vsi_close starts
    before previous i40e_vsi_close was done which leads to crash.
    
    Add check to diag_test if pf is in reset and don't start offline
    tests if it is true.
    Add netif_info("testing failed") into unhappy path of i40e_diag_test()
    
    Fixes: e17bc411aea8 ("i40e: Disable offline diagnostics if VFs are enabled")
    Fixes: 510efb2682b3 ("i40e: Fix ethtool offline diagnostic with netqueues")
    Signed-off-by: Michal Jaron <michalx.jaron@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iavf: Fix issue with MAC address of VF shown as zero [+ + +]
Author: Michal Wilczynski <michal.wilczynski@intel.com>
Date:   Fri May 20 13:19:27 2022 +0200

    iavf: Fix issue with MAC address of VF shown as zero
    
    [ Upstream commit 645603844270b69175899268be68b871295764fe ]
    
    After reinitialization of iavf, ice driver gets VIRTCHNL_OP_ADD_ETH_ADDR
    message with incorrectly set type of MAC address. Hardware address should
    have is_primary flag set as true. This way ice driver knows what it has
    to set as a MAC address.
    
    Check if the address is primary in iavf_add_filter function and set flag
    accordingly.
    
    To test set all-zero MAC on a VF. This triggers iavf re-initialization
    and VIRTCHNL_OP_ADD_ETH_ADDR message gets sent to PF.
    For example:
    
    ip link set dev ens785 vf 0 mac 00:00:00:00:00:00
    
    This triggers re-initialization of iavf. New MAC should be assigned.
    Now check if MAC is non-zero:
    
    ip link show dev ens785
    
    Fixes: a3e839d539e0 ("iavf: Add usage of new virtchnl format to set default MAC")
    Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
    Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: Fix memory corruption in VF driver [+ + +]
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Thu Jun 2 12:09:17 2022 +0200

    ice: Fix memory corruption in VF driver
    
    [ Upstream commit efe41860008e57fb6b69855b4b93fdf34bc42798 ]
    
    Disable VF's RX/TX queues, when it's disabled. VF can have queues enabled,
    when it requests a reset. If PF driver assumes that VF is disabled,
    while VF still has queues configured, VF may unmap DMA resources.
    In such scenario device still can map packets to memory, which ends up
    silently corrupting it.
    Previously, VF driver could experience memory corruption, which lead to
    crash:
    [ 5119.170157] BUG: unable to handle kernel paging request at 00001b9780003237
    [ 5119.170166] PGD 0 P4D 0
    [ 5119.170173] Oops: 0002 [#1] PREEMPT_RT SMP PTI
    [ 5119.170181] CPU: 30 PID: 427592 Comm: kworker/u96:2 Kdump: loaded Tainted: G        W I      --------- -  - 4.18.0-372.9.1.rt7.166.el8.x86_64 #1
    [ 5119.170189] Hardware name: Dell Inc. PowerEdge R740/014X06, BIOS 2.3.10 08/15/2019
    [ 5119.170193] Workqueue: iavf iavf_adminq_task [iavf]
    [ 5119.170219] RIP: 0010:__page_frag_cache_drain+0x5/0x30
    [ 5119.170238] Code: 0f 0f b6 77 51 85 f6 74 07 31 d2 e9 05 df ff ff e9 90 fe ff ff 48 8b 05 49 db 33 01 eb b4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 <f0> 29 77 34 74 01 c3 48 8b 07 f6 c4 80 74 0f 0f b6 77 51 85 f6 74
    [ 5119.170244] RSP: 0018:ffffa43b0bdcfd78 EFLAGS: 00010282
    [ 5119.170250] RAX: ffffffff896b3e40 RBX: ffff8fb282524000 RCX: 0000000000000002
    [ 5119.170254] RDX: 0000000049000000 RSI: 0000000000000000 RDI: 00001b9780003203
    [ 5119.170259] RBP: ffff8fb248217b00 R08: 0000000000000022 R09: 0000000000000009
    [ 5119.170262] R10: 2b849d6300000000 R11: 0000000000000020 R12: 0000000000000000
    [ 5119.170265] R13: 0000000000001000 R14: 0000000000000009 R15: 0000000000000000
    [ 5119.170269] FS:  0000000000000000(0000) GS:ffff8fb1201c0000(0000) knlGS:0000000000000000
    [ 5119.170274] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 5119.170279] CR2: 00001b9780003237 CR3: 00000008f3e1a003 CR4: 00000000007726e0
    [ 5119.170283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 5119.170286] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 5119.170290] PKRU: 55555554
    [ 5119.170292] Call Trace:
    [ 5119.170298]  iavf_clean_rx_ring+0xad/0x110 [iavf]
    [ 5119.170324]  iavf_free_rx_resources+0xe/0x50 [iavf]
    [ 5119.170342]  iavf_free_all_rx_resources.part.51+0x30/0x40 [iavf]
    [ 5119.170358]  iavf_virtchnl_completion+0xd8a/0x15b0 [iavf]
    [ 5119.170377]  ? iavf_clean_arq_element+0x210/0x280 [iavf]
    [ 5119.170397]  iavf_adminq_task+0x126/0x2e0 [iavf]
    [ 5119.170416]  process_one_work+0x18f/0x420
    [ 5119.170429]  worker_thread+0x30/0x370
    [ 5119.170437]  ? process_one_work+0x420/0x420
    [ 5119.170445]  kthread+0x151/0x170
    [ 5119.170452]  ? set_kthread_struct+0x40/0x40
    [ 5119.170460]  ret_from_fork+0x35/0x40
    [ 5119.170477] Modules linked in: iavf sctp ip6_udp_tunnel udp_tunnel mlx4_en mlx4_core nfp tls vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support dell_smbios wmi_bmof dell_wmi_descriptor dcdbas kvm_intel kvm irqbypass intel_rapl_common isst_if_common skx_edac irdma nfit libnvdimm x86_pkg_temp_thermal i40e intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ib_uverbs rapl ipmi_ssif intel_cstate intel_uncore mei_me pcspkr acpi_ipmi ib_core mei lpc_ich i2c_i801 ipmi_si ipmi_devintf wmi ipmi_msghandler acpi_power_meter xfs libcrc32c sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ice ahci drm libahci crc32c_intel libata tg3 megaraid_sas
    [ 5119.170613]  i2c_algo_bit dm_mirror dm_region_hash dm_log dm_mod fuse [last unloaded: iavf]
    [ 5119.170627] CR2: 00001b9780003237
    
    Fixes: ec4f5a436bdf ("ice: Check if VF is disabled for Opcode and other operations")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Co-developed-by: Slawomir Laba <slawomirx.laba@intel.com>
    Signed-off-by: Slawomir Laba <slawomirx.laba@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Fix PTP TX timestamp offset calculation [+ + +]
Author: Michal Michalik <michal.michalik@intel.com>
Date:   Tue May 10 13:03:43 2022 +0200

    ice: Fix PTP TX timestamp offset calculation
    
    [ Upstream commit 71a579f0d3777a704355e6f1572dfba92a9b58b2 ]
    
    The offset was being incorrectly calculated for E822 - that led to
    collisions in choosing TX timestamp register location when more than
    one port was trying to use timestamping mechanism.
    
    In E822 one quad is being logically split between ports, so quad 0 is
    having trackers for ports 0-3, quad 1 ports 4-7 etc. Each port should
    have separate memory location for tracking timestamps. Due to error for
    example ports 1 and 2 had been assigned to quad 0 with same offset (0),
    while port 1 should have offset 0 and 1 offset 16.
    
    Fix it by correctly calculating quad offset.
    
    Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support")
    Signed-off-by: Michal Michalik <michal.michalik@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Fix queue config fail handling [+ + +]
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Thu Jun 2 12:09:04 2022 +0200

    ice: Fix queue config fail handling
    
    [ Upstream commit be2af71496a54a7195ac62caba6fab49cfe5006c ]
    
    Disable VF's RX/TX queues, when VIRTCHNL_OP_CONFIG_VSI_QUEUES fail.
    Not disabling them might lead to scenario, where PF driver leaves VF
    queues enabled, when VF's VSI failed queue config.
    In this scenario VF should not have RX/TX queues enabled. If PF failed
    to set up VF's queues, VF will reset due to TX timeouts in VF driver.
    Initialize iterator 'i' to -1, so if error happens prior to configuring
    queues then error path code will not disable queue 0. Loop that
    configures queues will is using same iterator, so error path code will
    only disable queues that were configured.
    
    Fixes: 77ca27c41705 ("ice: add support for virtchnl_queue_select.[tx|rx]_queues bitmap")
    Suggested-by: Slawomir Laba <slawomirx.laba@intel.com>
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Sync VLAN filtering features for DVM [+ + +]
Author: Roman Storozhenko <roman.storozhenko@intel.com>
Date:   Tue Jun 7 08:54:57 2022 +0200

    ice: Sync VLAN filtering features for DVM
    
    [ Upstream commit 9542ef4fba8c73e176b8aa18a8adf04aecb889e5 ]
    
    VLAN filtering features, that is C-Tag and S-Tag, in DVM mode must be
    both enabled or disabled.
    In case of turning off/on only one of the features, another feature must
    be turned off/on automatically with issuing an appropriate message to
    the kernel log.
    
    Fixes: 1babaf77f49d ("ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev")
    Signed-off-by: Roman Storozhenko <roman.storozhenko@intel.com>
    Co-developed-by: Anatolii Gerasymenko <anatolii.gerasymenko@intel.com>
    Signed-off-by: Anatolii Gerasymenko <anatolii.gerasymenko@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
init: Initialize noop_backing_dev_info early [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 15 15:22:29 2022 +0200

    init: Initialize noop_backing_dev_info early
    
    [ Upstream commit 4bca7e80b6455772b4bf3f536dcbc19aac424d6a ]
    
    noop_backing_dev_info is used by superblocks of various
    pseudofilesystems such as kdevtmpfs. After commit 10e14073107d
    ("writeback: Fix inode->i_io_list not be protected by inode->i_lock
    error") this broke because __mark_inode_dirty() started to access more
    fields from noop_backing_dev_info and this led to crashes inside
    locked_inode_to_wb_and_lock_list() called from __mark_inode_dirty().
    Fix the problem by initializing noop_backing_dev_info before the
    filesystems get mounted.
    
    Fixes: 10e14073107d ("writeback: Fix inode->i_io_list not be protected by inode->i_lock error")
    Reported-and-tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reported-and-tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
    Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: soc_button_array - also add Lenovo Yoga Tablet2 1051F to dmi_use_low_level_irq [+ + +]
Author: Marius Hoch <mail@mariushoch.de>
Date:   Tue Jun 7 12:10:52 2022 -0700

    Input: soc_button_array - also add Lenovo Yoga Tablet2 1051F to dmi_use_low_level_irq
    
    [ Upstream commit 6ab2e51898cd4343bbdf8587af8ce8fbabddbcb5 ]
    
    Commit 223f61b8c5ad ("Input: soc_button_array - add Lenovo Yoga Tablet2
    1051L to the dmi_use_low_level_irq list") added the 1051L to this list
    already, but the same problem applies to the 1051F. As there are no
    further 1051 variants (just the F/L), we can just DMI match 1051.
    
    Tested on a Lenovo Yoga Tablet2 1051F: Without this patch the
    home-button stops working after a wakeup from suspend.
    
    Signed-off-by: Marius Hoch <mail@mariushoch.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220603120246.3065-1-mail@mariushoch.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring: fix races with buffer table unregister [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Jun 13 06:30:06 2022 +0100

    io_uring: fix races with buffer table unregister
    
    [ Upstream commit d11d31fc5d8a96f707facee0babdcffaafa38de2 ]
    
    Fixed buffer table quiesce might unlock ->uring_lock, potentially
    letting new requests to be submitted, don't allow those requests to
    use the table as they will race with unregistration.
    
    Reported-and-tested-by: van fantasy <g1042620637@gmail.com>
    Fixes: bd54b6fe3316ec ("io_uring: implement fixed buffers registration similar to fixed files")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: fix races with file table unregister [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Jun 13 06:32:44 2022 +0100

    io_uring: fix races with file table unregister
    
    [ Upstream commit b0380bf6dad4601d92025841e2b7a135d566c6e3 ]
    
    Fixed file table quiesce might unlock ->uring_lock, potentially letting
    new requests to be submitted, don't allow those requests to use the
    table as they will race with unregistration.
    
    Reported-and-tested-by: van fantasy <g1042620637@gmail.com>
    Fixes: 05f3fb3c53975 ("io_uring: avoid ring quiesce for fixed file set unregister and update")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: reinstate the inflight tracking [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Jun 1 23:57:02 2022 -0600

    io_uring: reinstate the inflight tracking
    
    commit 9cae36a094e7e9d6e5fe8b6dcd4642138b3eb0c7 upstream.
    
    After some debugging, it was realized that we really do still need the
    old inflight tracking for any file type that has io_uring_fops assigned.
    If we don't, then trivial circular references will mean that we never get
    the ctx cleaned up and hence it'll leak.
    
    Just bring back the inflight tracking, which then also means we can
    eliminate the conditional dropping of the file when task_work is queued.
    
    Fixes: d5361233e9ab ("io_uring: drop the old style inflight file tracking")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ipv6: Fix signed integer overflow in __ip6_append_data [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Tue Jun 7 20:00:27 2022 +0800

    ipv6: Fix signed integer overflow in __ip6_append_data
    
    [ Upstream commit f93431c86b631bbca5614c66f966bf3ddb3c2803 ]
    
    Resurrect ubsan overflow checks and ubsan report this warning,
    fix it by change the variable [length] type to size_t.
    
    UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19
    2147479552 + 8567 cannot be represented in type 'int'
    CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1
    Hardware name: linux,dummy-virt (DT)
    Call trace:
      dump_backtrace+0x214/0x230
      show_stack+0x30/0x78
      dump_stack_lvl+0xf8/0x118
      dump_stack+0x18/0x30
      ubsan_epilogue+0x18/0x60
      handle_overflow+0xd0/0xf0
      __ubsan_handle_add_overflow+0x34/0x44
      __ip6_append_data.isra.48+0x1598/0x1688
      ip6_append_data+0x128/0x260
      udpv6_sendmsg+0x680/0xdd0
      inet6_sendmsg+0x54/0x90
      sock_sendmsg+0x70/0x88
      ____sys_sendmsg+0xe8/0x368
      ___sys_sendmsg+0x98/0xe0
      __sys_sendmmsg+0xf4/0x3b8
      __arm64_sys_sendmmsg+0x34/0x48
      invoke_syscall+0x64/0x160
      el0_svc_common.constprop.4+0x124/0x300
      do_el0_svc+0x44/0xc8
      el0_svc+0x3c/0x1e8
      el0t_64_sync_handler+0x88/0xb0
      el0t_64_sync+0x16c/0x170
    
    Changes since v1:
    -Change the variable [length] type to unsigned, as Eric Dumazet suggested.
    Changes since v2:
    -Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.
    Changes since v3:
    -Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as
    Jakub Kicinski suggested.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Link: https://lore.kernel.org/r/20220607120028.845916-1-wangyufen@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Tue Jun 7 20:00:28 2022 +0800

    ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg
    
    [ Upstream commit f638a84afef3dfe10554c51820c16e39a278c915 ]
    
    When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be
    overflow. To fix, we can follow what udpv6 does and subtract the
    transhdrlen from the max.
    
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Link: https://lore.kernel.org/r/20220607120028.845916-2-wangyufen@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/apple-aic: Fix refcount leak in aic_of_ic_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:27 2022 +0400

    irqchip/apple-aic: Fix refcount leak in aic_of_ic_init
    
    [ Upstream commit 3d45670fab3c25a7452721e4588cc95c51cda134 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: a5e8801202b3 ("irqchip/apple-aic: Parse FIQ affinities from device-tree")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-4-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

irqchip/apple-aic: Fix refcount leak in build_fiq_affinity [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:26 2022 +0400

    irqchip/apple-aic: Fix refcount leak in build_fiq_affinity
    
    [ Upstream commit b1ac803f47cb1615468f35cf1ccb553c52087301 ]
    
    of_find_node_by_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: a5e8801202b3 ("irqchip/apple-aic: Parse FIQ affinities from device-tree")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-3-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:28 2022 +0400

    irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions
    
    [ Upstream commit ec8401a429ffee34ccf38cebf3443f8d5ae6cb0d ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    When kcalloc fails, it missing of_node_put() and results in refcount
    leak. Fix this by goto out_put_node label.
    
    Fixes: 52085d3f2028 ("irqchip/gic-v3: Dynamically allocate PPI partition descriptors")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-5-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:29 2022 +0400

    irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions
    
    [ Upstream commit fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b ]
    
    of_find_node_by_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-6-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic/realview: Fix refcount leak in realview_gic_of_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:25 2022 +0400

    irqchip/gic/realview: Fix refcount leak in realview_gic_of_init
    
    [ Upstream commit f4b98e314888cc51486421bcf6d52852452ea48b ]
    
    of_find_matching_node_and_match() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 82b0a434b436 ("irqchip/gic/realview: Support more RealView DCC variants")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-2-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/realtek-rtl: Fix refcount leak in map_interrupts [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:30 2022 +0400

    irqchip/realtek-rtl: Fix refcount leak in map_interrupts
    
    [ Upstream commit eff4780f83d0ae3e5b6c02ff5d999dc4c1c5c8ce ]
    
    of_find_node_by_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    This function doesn't call of_node_put() in error path.
    Call of_node_put() directly after of_property_read_u32() to cover
    both normal path and error path.
    
    Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-7-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: arm64: Always start with clearing SVE flag on load [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Sat May 28 12:38:11 2022 +0100

    KVM: arm64: Always start with clearing SVE flag on load
    
    commit d52d165d67c5aa26c8c89909003c94a66492d23d upstream.
    
    On each vcpu load, we set the KVM_ARM64_HOST_SVE_ENABLED
    flag if SVE is enabled for EL0 on the host. This is used to restore
    the correct state on vpcu put.
    
    However, it appears that nothing ever clears this flag. Once
    set, it will stick until the vcpu is destroyed, which has the
    potential to spuriously enable SVE for userspace.
    
    We probably never saw the issue because no VMM uses SVE, but
    that's still pretty bad. Unconditionally clearing the flag
    on vcpu load addresses the issue.
    
    Fixes: 8383741ab2e7 ("KVM: arm64: Get rid of host SVE tracking/saving")
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20220528113829.1043361-2-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: arm64: Don't read a HW interrupt pending state in user context [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Jun 7 14:14:25 2022 +0100

    KVM: arm64: Don't read a HW interrupt pending state in user context
    
    commit 2cdea19a34c2340b3aa69508804efe4e3750fcec upstream.
    
    Since 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state
    from the HW"), we're able to source the pending bit for an interrupt
    that is stored either on the physical distributor or on a device.
    
    However, this state is only available when the vcpu is loaded,
    and is not intended to be accessed from userspace. Unfortunately,
    the GICv2 emulation doesn't provide specific userspace accessors,
    and we fallback with the ones that are intended for the guest,
    with fatal consequences.
    
    Add a new vgic_uaccess_read_pending() accessor for userspace
    to use, build on top of the existing vgic_mmio_read_pending().
    
    Reported-by: Eric Auger <eric.auger@redhat.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Tested-by: Eric Auger <eric.auger@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Fixes: 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state from the HW")
    Link: https://lore.kernel.org/r/20220607131427.1164881-2-maz@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.18.6 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 22 14:28:13 2022 +0200

    Linux 5.18.6
    
    Link: https://lore.kernel.org/r/20220620124729.509745706@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Zan Aziz <zanaziz313@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md/raid5-ppl: Fix argument order in bio_alloc_bioset() [+ + +]
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Wed Jun 8 10:27:46 2022 -0600

    md/raid5-ppl: Fix argument order in bio_alloc_bioset()
    
    commit f34fdcd4a0e7a0b92340ad7e48e7bcff9393fab5 upstream.
    
    bio_alloc_bioset() takes a block device, number of vectors, the
    OP flags, the GFP mask and the bio set. However when the prototype
    was changed, the callisite in ppl_do_flush() had the OP flags and
    the GFP flags reversed. This introduced some sparse error:
    
      drivers/md/raid5-ppl.c:632:57: warning: incorrect type in argument 3
                                        (different base types)
      drivers/md/raid5-ppl.c:632:57:    expected unsigned int opf
      drivers/md/raid5-ppl.c:632:57:    got restricted gfp_t [usertype]
      drivers/md/raid5-ppl.c:633:61: warning: incorrect type in argument 4
                                        (different base types)
      drivers/md/raid5-ppl.c:633:61:    expected restricted gfp_t [usertype]
                                        gfp_mask
      drivers/md/raid5-ppl.c:633:61:    got unsigned long long
    
    The sparse error introduction may not have been reported correctly by
    0day due to other work that was cleaning up other sparse errors in this
    area.
    
    Fixes: 609be1066731 ("block: pass a block_device and opf to bio_alloc_bioset")
    Cc: stable@vger.kernel.org # 5.18+
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mei: hbm: drop capability response on early shutdown [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Mon Jun 6 17:42:24 2022 +0300

    mei: hbm: drop capability response on early shutdown
    
    commit 68553650bc9c57c7e530c84e5b2945e9dfe1a560 upstream.
    
    Drop HBM responses also in the early shutdown phase where
    the usual traffic is allowed.
    Extend the rule that drop HBM responses received during the shutdown
    phase by also in MEI_DEV_POWERING_DOWN state.
    This resolves the stall if the driver is stopping in the middle
    of the link initialization or link reset.
    
    Drop the capabilities response on early shutdown.
    
    Fixes: 6d7163f2c49f ("mei: hbm: drop hbm responses on early shutdown")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20220606144225.282375-2-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: me: add raptor lake point S DID [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Mon Jun 6 17:42:25 2022 +0300

    mei: me: add raptor lake point S DID
    
    commit 3ed8c7d39cfef831fe508fc1308f146912fa72e6 upstream.
    
    Add Raptor (Point) Lake S device id.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20220606144225.282375-3-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mellanox: mlx5: avoid uninitialized variable warning with gcc-12 [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 9 10:03:28 2022 -0700

    mellanox: mlx5: avoid uninitialized variable warning with gcc-12
    
    [ Upstream commit 842c3b3ddc5f4d17275edbaa09e23d712bf8b915 ]
    
    gcc-12 started warning about 'tracker' being used uninitialized:
    
      drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c: In function ‘mlx5_do_bond’:
      drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c:786:28: warning: ‘tracker’ is used uninitialized [-Wuninitialized]
        786 |         struct lag_tracker tracker;
            |                            ^~~~~~~
    
    which seems to be because it doesn't track how the use (and
    initialization) is bound by the 'do_bond' flag.
    
    But admittedly that 'do_bond' usage is fairly complicated, and involves
    passing it around as an argument to helper functions, so it's somewhat
    understandable that gcc doesn't see how that all works.
    
    This function could be rewritten to make the use of that tracker
    variable more obviously safe, but for now I'm just adding the forced
    initialization of it.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: Loongson-3: fix compile mips cpu_hwmon as module build error. [+ + +]
Author: Yupeng Li <liyupeng@zbhlos.com>
Date:   Wed Jun 8 09:12:29 2022 +0800

    MIPS: Loongson-3: fix compile mips cpu_hwmon as module build error.
    
    [ Upstream commit 41e456400212803704e82691716e1d7b0865114a ]
    
      set cpu_hwmon as a module build with loongson_sysconf, loongson_chiptemp
      undefined error,fix cpu_hwmon compile options to be bool.Some kernel
      compilation error information is as follows:
    
      Checking missing-syscalls for N32
      CALL    scripts/checksyscalls.sh
      Checking missing-syscalls for O32
      CALL    scripts/checksyscalls.sh
      CALL    scripts/checksyscalls.sh
      CHK     include/generated/compile.h
      CC [M]  drivers/platform/mips/cpu_hwmon.o
      Building modules, stage 2.
      MODPOST 200 modules
    ERROR: "loongson_sysconf" [drivers/platform/mips/cpu_hwmon.ko] undefined!
    ERROR: "loongson_chiptemp" [drivers/platform/mips/cpu_hwmon.ko] undefined!
    make[1]: *** [scripts/Makefile.modpost:92:__modpost] 错误 1
    make: *** [Makefile:1261:modules] 错误 2
    
    Signed-off-by: Yupeng Li <liyupeng@zbhlos.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: atmel-ssc: Fix IRQ check in ssc_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 16:30:26 2022 +0400

    misc: atmel-ssc: Fix IRQ check in ssc_probe
    
    [ Upstream commit 1c245358ce0b13669f6d1625f7a4e05c41f28980 ]
    
    platform_get_irq() returns negative error number instead 0 on failure.
    And the doc of platform_get_irq() provides a usage example:
    
        int irq = platform_get_irq(pdev, 0);
        if (irq < 0)
            return irq;
    
    Fix the check of return value to catch errors correctly.
    
    Fixes: eb1f2930609b ("Driver for the Atmel on-chip SSC on AT32AP and AT91")
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220601123026.7119-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mlxsw: spectrum_cnt: Reorder counter pools [+ + +]
Author: Petr Machata <petrm@nvidia.com>
Date:   Mon Jun 13 15:50:17 2022 +0300

    mlxsw: spectrum_cnt: Reorder counter pools
    
    [ Upstream commit 4b7a632ac4e7101ceefee8484d5c2ca505d347b3 ]
    
    Both RIF and ACL flow counters use a 24-bit SW-managed counter address to
    communicate which counter they want to bind.
    
    In a number of Spectrum FW releases, binding a RIF counter is broken and
    slices the counter index to 16 bits. As a result, on Spectrum-2 and above,
    no more than about 410 RIF counters can be effectively used. This
    translates to 205 netdevices for which L3 HW stats can be enabled. (This
    does not happen on Spectrum-1, because there are fewer counters available
    overall and the counter index never exceeds 16 bits.)
    
    Binding counters to ACLs does not have this issue. Therefore reorder the
    counter allocation scheme so that RIF counters come first and therefore get
    lower indices that are below the 16-bit barrier.
    
    Fixes: 98e60dce4da1 ("Merge branch 'mlxsw-Introduce-initial-Spectrum-2-support'")
    Reported-by: Maksym Yaremchuk <maksymy@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://lore.kernel.org/r/20220613125017.2018162-1-idosch@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: ax25: Fix deadlock caused by skb_recv_datagram in ax25_recvmsg [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue Jun 14 17:25:57 2022 +0800

    net: ax25: Fix deadlock caused by skb_recv_datagram in ax25_recvmsg
    
    [ Upstream commit 219b51a6f040fa5367adadd7d58c4dda0896a01d ]
    
    The skb_recv_datagram() in ax25_recvmsg() will hold lock_sock
    and block until it receives a packet from the remote. If the client
    doesn`t connect to server and calls read() directly, it will not
    receive any packets forever. As a result, the deadlock will happen.
    
    The fail log caused by deadlock is shown below:
    
    [  369.606973] INFO: task ax25_deadlock:157 blocked for more than 245 seconds.
    [  369.608919] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  369.613058] Call Trace:
    [  369.613315]  <TASK>
    [  369.614072]  __schedule+0x2f9/0xb20
    [  369.615029]  schedule+0x49/0xb0
    [  369.615734]  __lock_sock+0x92/0x100
    [  369.616763]  ? destroy_sched_domains_rcu+0x20/0x20
    [  369.617941]  lock_sock_nested+0x6e/0x70
    [  369.618809]  ax25_bind+0xaa/0x210
    [  369.619736]  __sys_bind+0xca/0xf0
    [  369.620039]  ? do_futex+0xae/0x1b0
    [  369.620387]  ? __x64_sys_futex+0x7c/0x1c0
    [  369.620601]  ? fpregs_assert_state_consistent+0x19/0x40
    [  369.620613]  __x64_sys_bind+0x11/0x20
    [  369.621791]  do_syscall_64+0x3b/0x90
    [  369.622423]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [  369.623319] RIP: 0033:0x7f43c8aa8af7
    [  369.624301] RSP: 002b:00007f43c8197ef8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
    [  369.625756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f43c8aa8af7
    [  369.626724] RDX: 0000000000000010 RSI: 000055768e2021d0 RDI: 0000000000000005
    [  369.628569] RBP: 00007f43c8197f00 R08: 0000000000000011 R09: 00007f43c8198700
    [  369.630208] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff845e6afe
    [  369.632240] R13: 00007fff845e6aff R14: 00007f43c8197fc0 R15: 00007f43c8198700
    
    This patch replaces skb_recv_datagram() with an open-coded variant of it
    releasing the socket lock before the __skb_wait_for_more_packets() call
    and re-acquiring it after such call in order that other functions that
    need socket lock could be executed.
    
    what's more, the socket lock will be released only when recvmsg() will
    block and that should produce nicer overall behavior.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Suggested-by: Thomas Osterried <thomas@osterried.de>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reported-by: Thomas Habets <thomas@@habets.se>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bgmac: Fix an erroneous kfree() in bgmac_remove() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Jun 13 22:53:50 2022 +0200

    net: bgmac: Fix an erroneous kfree() in bgmac_remove()
    
    [ Upstream commit d7dd6eccfbc95ac47a12396f84e7e1b361db654b ]
    
    'bgmac' is part of a managed resource allocated with bgmac_alloc(). It
    should not be freed explicitly.
    
    Remove the erroneous kfree() from the .remove() function.
    
    Fixes: 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/a026153108dd21239036a032b95c25b5cece253b.1655153616.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: mtk_eth_soc: fix misuse of mem alloc interface netdev[napi]_alloc_frag [+ + +]
Author: Chen Lin <chen45464546@163.com>
Date:   Wed Jun 8 20:46:53 2022 +0800

    net: ethernet: mtk_eth_soc: fix misuse of mem alloc interface netdev[napi]_alloc_frag
    
    [ Upstream commit 2f2c0d2919a14002760f89f4e02960c735a316d2 ]
    
    When rx_flag == MTK_RX_FLAGS_HWLRO,
    rx_data_len = MTK_MAX_LRO_RX_LENGTH(4096 * 3) > PAGE_SIZE.
    netdev_alloc_frag is for alloction of page fragment only.
    Reference to other drivers and Documentation/vm/page_frags.rst
    
    Branch to use __get_free_pages when ring->frag_size > PAGE_SIZE.
    
    Signed-off-by: Chen Lin <chen45464546@163.com>
    Link: https://lore.kernel.org/r/1654692413-2598-1-git-send-email-chen45464546@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: don't push link state to VF if unalive [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Sat Jun 11 20:25:25 2022 +0800

    net: hns3: don't push link state to VF if unalive
    
    [ Upstream commit 283847e3ef6dbf79bf67083b5ce7b8033e8b6f34 ]
    
    It's unnecessary to push link state to unalive VF, and the VF will
    query link state from PF when it being start works.
    
    Fixes: 18b6e31f8bf4 ("net: hns3: PF add support for pushing link status to VFs")
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix PF rss size initialization bug [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Sat Jun 11 20:25:28 2022 +0800

    net: hns3: fix PF rss size initialization bug
    
    [ Upstream commit 71b215f36dca1a3d5d1c576b2099e6d7ea03047e ]
    
    Currently hns3 driver misuses the VF rss size to initialize the PF rss size
    in hclge_tm_vport_tc_info_update. So this patch fix it by checking the
    vport id before initialization.
    
    Fixes: 7347255ea389 ("net: hns3: refactor PF rss get APIs with new common rss get APIs")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix tm port shapping of fibre port is incorrect after driver initialization [+ + +]
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Sat Jun 11 20:25:29 2022 +0800

    net: hns3: fix tm port shapping of fibre port is incorrect after driver initialization
    
    [ Upstream commit 12a3670887725df364cc3e030cf3bede6f13b364 ]
    
    Currently in driver initialization process, driver will set shapping
    parameters of tm port to default speed read from firmware. However, the
    speed of SFP module may not be default speed, so shapping parameters of
    tm port may be incorrect.
    
    To fix this problem, driver sets new shapping parameters for tm port
    after getting exact speed of SFP module in this case.
    
    Fixes: 88d10bd6f730 ("net: hns3: add support for multiple media type")
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: restore tm priority/qset to default settings when tc disabled [+ + +]
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Sat Jun 11 20:25:27 2022 +0800

    net: hns3: restore tm priority/qset to default settings when tc disabled
    
    [ Upstream commit e93530ae0e5d8fcf2d908933d206e0c93bc3c09b ]
    
    Currently, settings parameters of schedule mode, dwrr, shaper of tm
    priority or qset of one tc are only be set when tc is enabled, they are
    not restored to the default settings when tc is disabled. It confuses
    users when they cat tm_priority or tm_qset files of debugfs. So this
    patch fixes it.
    
    Fixes: 848440544b41 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver")
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: set port base vlan tbl_sta to false before removing old vlan [+ + +]
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Sat Jun 11 20:25:24 2022 +0800

    net: hns3: set port base vlan tbl_sta to false before removing old vlan
    
    [ Upstream commit 9eda7d8bcbdb6909f202edeedff51948f1cad1e5 ]
    
    When modify port base vlan, the port base vlan tbl_sta needs to set to
    false before removing old vlan, to indicate this operation is not finish.
    
    Fixes: c0f46de30c96 ("net: hns3: fix port base vlan add fail when concurrent with reset")
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: remove noblock parameter from skb_recv_datagram() [+ + +]
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Mon Apr 4 18:30:22 2022 +0200

    net: remove noblock parameter from skb_recv_datagram()
    
    [ Upstream commit f4b41f062c424209e3939a81e6da022e049a45f2 ]
    
    skb_recv_datagram() has two parameters 'flags' and 'noblock' that are
    merged inside skb_recv_datagram() by 'flags | (noblock ? MSG_DONTWAIT : 0)'
    
    As 'flags' may contain MSG_DONTWAIT as value most callers split the 'flags'
    into 'flags' and 'noblock' with finally obsolete bit operations like this:
    
    skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &rc);
    
    And this is not even done consistently with the 'flags' parameter.
    
    This patch removes the obsolete and costly splitting into two parameters
    and only performs bit operations when really needed on the caller side.
    
    One missing conversion thankfully reported by kernel test robot. I missed
    to enable kunit tests to build the mctp code.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfs: Fix gcc-12 warning by embedding vfs inode in netfs_i_context [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 9 21:46:04 2022 +0100

    netfs: Fix gcc-12 warning by embedding vfs inode in netfs_i_context
    
    commit 874c8ca1e60b2c564a48f7e7acc40d328d5c8733 upstream.
    
    While randstruct was satisfied with using an open-coded "void *" offset
    cast for the netfs_i_context <-> inode casting, __builtin_object_size() as
    used by FORTIFY_SOURCE was not as easily fooled.  This was causing the
    following complaint[1] from gcc v12:
    
      In file included from include/linux/string.h:253,
                       from include/linux/ceph/ceph_debug.h:7,
                       from fs/ceph/inode.c:2:
      In function 'fortify_memset_chk',
          inlined from 'netfs_i_context_init' at include/linux/netfs.h:326:2,
          inlined from 'ceph_alloc_inode' at fs/ceph/inode.c:463:2:
      include/linux/fortify-string.h:242:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
        242 |                         __write_overflow_field(p_size_field, size);
            |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix this by embedding a struct inode into struct netfs_i_context (which
    should perhaps be renamed to struct netfs_inode).  The struct inode
    vfs_inode fields are then removed from the 9p, afs, ceph and cifs inode
    structs and vfs_inode is then simply changed to "netfs.inode" in those
    filesystems.
    
    Further, rename netfs_i_context to netfs_inode, get rid of the
    netfs_inode() function that converted a netfs_i_context pointer to an
    inode pointer (that can now be done with &ctx->inode) and rename the
    netfs_i_context() function to netfs_inode() (which is now a wrapper
    around container_of()).
    
    Most of the changes were done with:
    
      perl -p -i -e 's/vfs_inode/netfs.inode/'g \
            `git grep -l 'vfs_inode' -- fs/{9p,afs,ceph,cifs}/*.[ch]`
    
    Kees suggested doing it with a pair structure[2] and a special
    declarator to insert that into the network filesystem's inode
    wrapper[3], but I think it's cleaner to embed it - and then it doesn't
    matter if struct randomisation reorders things.
    
    Dave Chinner suggested using a filesystem-specific VFS_I() function in
    each filesystem to convert that filesystem's own inode wrapper struct
    into the VFS inode struct[4].
    
    Version #2:
     - Fix a couple of missed name changes due to a disabled cifs option.
     - Rename nfs_i_context to nfs_inode
     - Use "netfs" instead of "nic" as the member name in per-fs inode wrapper
       structs.
    
    [ This also undoes commit 507160f46c55 ("netfs: gcc-12: temporarily
      disable '-Wattribute-warning' for now") that is no longer needed ]
    
    Fixes: bc899ee1c898 ("netfs: Add a netfs inode context")
    Reported-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    cc: Jonathan Corbet <corbet@lwn.net>
    cc: Eric Van Hensbergen <ericvh@gmail.com>
    cc: Latchesar Ionkov <lucho@ionkov.net>
    cc: Dominique Martinet <asmadeus@codewreck.org>
    cc: Christian Schoenebeck <linux_oss@crudebyte.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: Ilya Dryomov <idryomov@gmail.com>
    cc: Steve French <smfrench@gmail.com>
    cc: William Kucharski <william.kucharski@oracle.com>
    cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
    cc: Dave Chinner <david@fromorbit.com>
    cc: linux-doc@vger.kernel.org
    cc: v9fs-developer@lists.sourceforge.net
    cc: linux-afs@lists.infradead.org
    cc: ceph-devel@vger.kernel.org
    cc: linux-cifs@vger.kernel.org
    cc: samba-technical@lists.samba.org
    cc: linux-fsdevel@vger.kernel.org
    cc: linux-hardening@vger.kernel.org
    Link: https://lore.kernel.org/r/d2ad3a3d7bdd794c6efb562d2f2b655fb67756b9.camel@kernel.org/ [1]
    Link: https://lore.kernel.org/r/20220517210230.864239-1-keescook@chromium.org/ [2]
    Link: https://lore.kernel.org/r/20220518202212.2322058-1-keescook@chromium.org/ [3]
    Link: https://lore.kernel.org/r/20220524101205.GI2306852@dread.disaster.area/ [4]
    Link: https://lore.kernel.org/r/165296786831.3591209.12111293034669289733.stgit@warthog.procyon.org.uk/ # v1
    Link: https://lore.kernel.org/r/165305805651.4094995.7763502506786714216.stgit@warthog.procyon.org.uk # v2
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfs: gcc-12: temporarily disable '-Wattribute-warning' for now [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 9 11:29:36 2022 -0700

    netfs: gcc-12: temporarily disable '-Wattribute-warning' for now
    
    [ Upstream commit 507160f46c55913955d272ebf559d63809a8e560 ]
    
    This is a pure band-aid so that I can continue merging stuff from people
    while some of the gcc-12 fallout gets sorted out.
    
    In particular, gcc-12 is very unhappy about the kinds of pointer
    arithmetic tricks that netfs does, and that makes the fortify checks
    trigger in afs and ceph:
    
      In function ‘fortify_memset_chk’,
          inlined from ‘netfs_i_context_init’ at include/linux/netfs.h:327:2,
          inlined from ‘afs_set_netfs_context’ at fs/afs/inode.c:61:2,
          inlined from ‘afs_root_iget’ at fs/afs/inode.c:543:2:
      include/linux/fortify-string.h:258:25: warning: call to ‘__write_overflow_field’ declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
        258 |                         __write_overflow_field(p_size_field, size);
            |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    and the reason is that netfs_i_context_init() is passed a 'struct inode'
    pointer, and then it does
    
            struct netfs_i_context *ctx = netfs_i_context(inode);
    
            memset(ctx, 0, sizeof(*ctx));
    
    where that netfs_i_context() function just does pointer arithmetic on
    the inode pointer, knowing that the netfs_i_context is laid out
    immediately after it in memory.
    
    This is all truly disgusting, since the whole "netfs_i_context is laid
    out immediately after it in memory" is not actually remotely true in
    general, but is just made to be that way for afs and ceph.
    
    See for example fs/cifs/cifsglob.h:
    
      struct cifsInodeInfo {
            struct {
                    /* These must be contiguous */
                    struct inode    vfs_inode;      /* the VFS's inode record */
                    struct netfs_i_context netfs_ctx; /* Netfslib context */
            };
            [...]
    
    and realize that this is all entirely wrong, and the pointer arithmetic
    that netfs_i_context() is doing is also very very wrong and wouldn't
    give the right answer if netfs_ctx had different alignment rules from a
    'struct inode', for example).
    
    Anyway, that's just a long-winded way to say "the gcc-12 warning is
    actually quite reasonable, and our code happens to work but is pretty
    disgusting".
    
    This is getting fixed properly, but for now I made the mistake of
    thinking "the week right after the merge window tends to be calm for me
    as people take a breather" and I did a sustem upgrade.  And I got gcc-12
    as a result, so to continue merging fixes from people and not have the
    end result drown in warnings, I am fixing all these gcc-12 issues I hit.
    
    Including with these kinds of temporary fixes.
    
    Cc: Kees Cook <keescook@chromium.org>
    Cc: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/all/AEEBCF5D-8402-441D-940B-105AA718C71F@chromium.org/
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred [+ + +]
Author: Xiaohui Zhang <xiaohuizhang@ruc.edu.cn>
Date:   Tue Jun 7 16:32:30 2022 +0800

    nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
    
    [ Upstream commit 8a4d480702b71184fabcf379b80bf7539716752e ]
    
    Similar to the handling of play_deferred in commit 19cfe912c37b
    ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought
    a patch might be needed here as well.
    
    Currently usb_submit_urb is called directly to submit deferred tx
    urbs after unanchor them.
    
    So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
    and cause memory leak.
    
    Put those urbs in tx_anchor to avoid the leak, and also fix the error
    handling.
    
    Signed-off-by: Xiaohui Zhang <xiaohuizhang@ruc.edu.cn>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220607083230.6182-1-xiaohuizhang@ruc.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: add device name to warning in uuid_show() [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Tue Jun 7 17:55:55 2022 +0200

    nvme: add device name to warning in uuid_show()
    
    [ Upstream commit 1fc766b5c08417248e0008bca14c3572ac0f1c26 ]
    
    This provides more context to users.
    
    Old message:
    
    [   00.000000] No UUID available providing old NGUID
    
    New message:
    
    [   00.000000] block nvme0n1: No UUID available providing old NGUID
    
    Fixes: d934f9848a77 ("nvme: provide UUID value to userspace")
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86/intel: Fix pmt_crashlog array reference [+ + +]
Author: David Arcari <darcari@redhat.com>
Date:   Thu May 26 16:31:40 2022 -0400

    platform/x86/intel: Fix pmt_crashlog array reference
    
    [ Upstream commit 66cb3a2d7ad0d0e9af4d3430a4f2a32ffb9ac098 ]
    
    The probe function pmt_crashlog_probe() may incorrectly reference
    the 'priv->entry array' as it uses 'i' to reference the array instead
    of 'priv->num_entries' as it should.  This is similar to the problem
    that was addressed in pmt_telemetry_probe via commit 2cdfa0c20d58
    ("platform/x86/intel: Fix 'rmmod pmt_telemetry' panic").
    
    Cc: "David E. Box" <david.e.box@linux.intel.com>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Mark Gross <markgross@kernel.org>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: David Arcari <darcari@redhat.com>
    Reviewed-by: David E. Box <david.e.box@linux.intel.com>
    Link: https://lore.kernel.org/r/20220526203140.339120-1-darcari@redhat.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86/intel: hid: Add Surface Go to VGBS allow list [+ + +]
Author: Duke Lee <krnhotwings@gmail.com>
Date:   Tue Jun 7 14:36:54 2022 -0700

    platform/x86/intel: hid: Add Surface Go to VGBS allow list
    
    [ Upstream commit d4fe9cc4ff8656704b58cfd9363d7c3c9d65e519 ]
    
    The Surface Go reports Chassis Type 9 (Laptop,) so the device needs to be
    added to dmi_vgbs_allow_list to enable tablet mode when an attached Type
    Cover is folded back.
    
    BugLink: https://github.com/linux-surface/linux-surface/issues/837
    Signed-off-by: Duke Lee <krnhotwings@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220607213654.5567-1-krnhotwings@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86/intel: pmc: Support Intel Raptorlake P [+ + +]
Author: George D Sworo <george.d.sworo@intel.com>
Date:   Wed Jun 1 18:26:17 2022 -0700

    platform/x86/intel: pmc: Support Intel Raptorlake P
    
    [ Upstream commit 552f3b801de6eb062b225a76e140995483a0609c ]
    
    Add Raptorlake P to the list of the platforms that intel_pmc_core driver
    supports for pmc_core device. Raptorlake P PCH is based on Alderlake P
    PCH.
    
    Signed-off-by: George D Sworo <george.d.sworo@intel.com>
    Reviewed-by: David E. Box <david.e.box@linux.intel.com>
    Link: https://lore.kernel.org/r/20220602012617.20100-1-george.d.sworo@intel.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: gigabyte-wmi: Add support for B450M DS3H-CF [+ + +]
Author: August Wikerfors <git@augustwikerfors.se>
Date:   Wed Jun 8 23:20:28 2022 +0200

    platform/x86: gigabyte-wmi: Add support for B450M DS3H-CF
    
    [ Upstream commit c6bc7e8ee90845556a90faf8b043cbefd77b8903 ]
    
    Tested and works on my system.
    
    Signed-off-by: August Wikerfors <git@augustwikerfors.se>
    Link: https://lore.kernel.org/r/20220608212028.28307-1-git@augustwikerfors.se
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: gigabyte-wmi: Add Z690M AORUS ELITE AX DDR4 support [+ + +]
Author: Piotr Chmura <chmooreck@gmail.com>
Date:   Mon Jun 6 19:15:13 2022 +0200

    platform/x86: gigabyte-wmi: Add Z690M AORUS ELITE AX DDR4 support
    
    [ Upstream commit 8a041afe3e774bedd3e0a9b96f65e48a1299a595 ]
    
    Add dmi_system_id of Gigabyte Z690M AORUS ELITE AX DDR4 board.
    Tested on my PC.
    
    Signed-off-by: Piotr Chmura <chmooreck@gmail.com>
    Link: https://lore.kernel.org/r/bd83567e-ebf5-0b31-074b-5f6dc7f7c147@gmail.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pNFS: Avoid a live lock condition in pnfs_update_layout() [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue May 31 11:03:07 2022 -0400

    pNFS: Avoid a live lock condition in pnfs_update_layout()
    
    [ Upstream commit 880265c77ac415090090d1fe72a188fee71cb458 ]
    
    If we're about to send the first layoutget for an empty layout, we want
    to make sure that we drain out the existing pending layoutget calls
    first. The reason is that these layouts may have been already implicitly
    returned to the server by a recall to which the client gave a
    NFS4ERR_NOMATCHING_LAYOUT response.
    
    The problem is that wait_var_event_killable() could in principle see the
    plh_outstanding count go back to '1' when the first process to wake up
    starts sending a new layoutget. If it fails to get a layout, then this
    loop can continue ad infinitum...
    
    Fixes: 0b77f97a7e42 ("NFSv4/pnfs: Fix layoutget behaviour after invalidation")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pNFS: Don't keep retrying if the server replied NFS4ERR_LAYOUTUNAVAILABLE [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue May 31 11:03:06 2022 -0400

    pNFS: Don't keep retrying if the server replied NFS4ERR_LAYOUTUNAVAILABLE
    
    [ Upstream commit fe44fb23d6ccde4c914c44ef74ab8d9d9ba02bea ]
    
    If the server tells us that a pNFS layout is not available for a
    specific file, then we should not keep pounding it with further
    layoutget requests.
    
    Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/book3e: get rid of #include [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Jun 4 17:50:50 2022 +0900

    powerpc/book3e: get rid of #include <generated/compile.h>
    
    commit 7ad4bd887d27c6b6ffbef216f19c19f8fe2b8f52 upstream.
    
    You cannot include <generated/compile.h> here because it is generated
    in init/Makefile but there is no guarantee that it happens before
    arch/powerpc/mm/nohash/kaslr_booke.c is compiled for parallel builds.
    
    The places where you can reliably include <generated/compile.h> are:
    
      - init/          (because init/Makefile can specify the dependency)
      - arch/*/boot/   (because it is compiled after vmlinux)
    
    Commit f231e4333312 ("hexagon: get rid of #include <generated/compile.h>")
    fixed the last breakage at that time, but powerpc re-added this.
    
    <generated/compile.h> was unneeded because 'build_str' is almost the
    same as 'linux_banner' defined in init/version.c
    
    Let's copy the solution from MIPS.
    (get_random_boot() in arch/mips/kernel/relocate.c)
    
    Fixes: 6a38ea1d7b94 ("powerpc/fsl_booke/32: randomize the kernel image offset")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Scott Wood <oss@buserror.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220604085050.4078927-1-masahiroy@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/kasan: Silence KASAN warnings in __get_wchan() [+ + +]
Author: He Ying <heying24@huawei.com>
Date:   Thu Jan 20 20:44:18 2022 -0500

    powerpc/kasan: Silence KASAN warnings in __get_wchan()
    
    [ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
    
    The following KASAN warning was reported in our kernel.
    
      BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
      Read of size 4 at addr d216f958 by task ps/14437
    
      CPU: 3 PID: 14437 Comm: ps Tainted: G           O      5.10.0 #1
      Call Trace:
      [daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
      [daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
      [daa63908] [c035d6bc] kasan_report+0x1ac/0x218
      [daa63948] [c00496e8] get_wchan+0x188/0x250
      [daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
      [daa63b98] [c0455ac8] proc_single_show+0x98/0x170
      [daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
      [daa63c38] [c03cb47c] seq_read+0x1dc/0x290
      [daa63d68] [c037fc94] vfs_read+0x164/0x510
      [daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
      [daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
      --- interrupt: c00 at 0x8fa8f4
          LR = 0x8fa8cc
    
      The buggy address belongs to the page:
      page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
      flags: 0x0()
      raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
      raw: 00000000
      page dumped because: kasan: bad access detected
    
      Memory state around the buggy address:
       d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
       d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
                                                ^
       d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
       d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    After looking into this issue, I find the buggy address belongs
    to the task stack region. It seems KASAN has something wrong.
    I look into the code of __get_wchan in x86 architecture and
    find the same issue has been resolved by the commit
    f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
    The solution could be applied to powerpc architecture too.
    
    As Andrey Ryabinin said, get_wchan() is racy by design, it may
    access volatile stack of running task, thus it may access
    redzone in a stack frame and cause KASAN to warn about this.
    
    Use READ_ONCE_NOCHECK() to silence these warnings.
    
    Reported-by: Wanming Hu <huwanming@huaweil.com>
    Signed-off-by: He Ying <heying24@huawei.com>
    Signed-off-by: Chen Jingwen <chenjingwen6@huawei.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
quota: Prevent memory allocation recursion while holding dq_lock [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Sun Jun 5 15:38:13 2022 +0100

    quota: Prevent memory allocation recursion while holding dq_lock
    
    [ Upstream commit 537e11cdc7a6b3ce94fa25ed41306193df9677b7 ]
    
    As described in commit 02117b8ae9c0 ("f2fs: Set GF_NOFS in
    read_cache_page_gfp while doing f2fs_quota_read"), we must not enter
    filesystem reclaim while holding the dq_lock.  Prevent this more generally
    by using memalloc_nofs_save() while holding the lock.
    
    Link: https://lore.kernel.org/r/20220605143815.2330891-2-willy@infradead.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
random: credit cpu and bootloader seeds by default [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Jun 5 18:30:46 2022 +0200

    random: credit cpu and bootloader seeds by default
    
    [ Upstream commit 846bb97e131d7938847963cca00657c995b1fce1 ]
    
    This commit changes the default Kconfig values of RANDOM_TRUST_CPU and
    RANDOM_TRUST_BOOTLOADER to be Y by default. It does not change any
    existing configs or change any kernel behavior. The reason for this is
    several fold.
    
    As background, I recently had an email thread with the kernel
    maintainers of Fedora/RHEL, Debian, Ubuntu, Gentoo, Arch, NixOS, Alpine,
    SUSE, and Void as recipients. I noted that some distros trust RDRAND,
    some trust EFI, and some trust both, and I asked why or why not. There
    wasn't really much of a "debate" but rather an interesting discussion of
    what the historical reasons have been for this, and it came up that some
    distros just missed the introduction of the bootloader Kconfig knob,
    while another didn't want to enable it until there was a boot time
    switch to turn it off for more concerned users (which has since been
    added). The result of the rather uneventful discussion is that every
    major Linux distro enables these two options by default.
    
    While I didn't have really too strong of an opinion going into this
    thread -- and I mostly wanted to learn what the distros' thinking was
    one way or another -- ultimately I think their choice was a decent
    enough one for a default option (which can be disabled at boot time).
    I'll try to summarize the pros and cons:
    
    Pros:
    
    - The RNG machinery gets initialized super quickly, and there's no
      messing around with subsequent blocking behavior.
    
    - The bootloader mechanism is used by kexec in order for the prior
      kernel to initialize the RNG of the next kernel, which increases
      the entropy available to early boot daemons of the next kernel.
    
    - Previous objections related to backdoors centered around
      Dual_EC_DRBG-like kleptographic systems, in which observing some
      amount of the output stream enables an adversary holding the right key
      to determine the entire output stream.
    
      This used to be a partially justified concern, because RDRAND output
      was mixed into the output stream in varying ways, some of which may
      have lacked pre-image resistance (e.g. XOR or an LFSR).
    
      But this is no longer the case. Now, all usage of RDRAND and
      bootloader seeds go through a cryptographic hash function. This means
      that the CPU would have to compute a hash pre-image, which is not
      considered to be feasible (otherwise the hash function would be
      terribly broken).
    
    - More generally, if the CPU is backdoored, the RNG is probably not the
      realistic vector of choice for an attacker.
    
    - These CPU or bootloader seeds are far from being the only source of
      entropy. Rather, there is generally a pretty huge amount of entropy,
      not all of which is credited, especially on CPUs that support
      instructions like RDRAND. In other words, assuming RDRAND outputs all
      zeros, an attacker would *still* have to accurately model every single
      other entropy source also in use.
    
    - The RNG now reseeds itself quite rapidly during boot, starting at 2
      seconds, then 4, then 8, then 16, and so forth, so that other sources
      of entropy get used without much delay.
    
    - Paranoid users can set random.trust_{cpu,bootloader}=no in the kernel
      command line, and paranoid system builders can set the Kconfig options
      to N, so there's no reduction or restriction of optionality.
    
    - It's a practical default.
    
    - All the distros have it set this way. Microsoft and Apple trust it
      too. Bandwagon.
    
    Cons:
    
    - RDRAND *could* still be backdoored with something like a fixed key or
      limited space serial number seed or another indexable scheme like
      that. (However, it's hard to imagine threat models where the CPU is
      backdoored like this, yet people are still okay making *any*
      computations with it or connecting it to networks, etc.)
    
    - RDRAND *could* be defective, rather than backdoored, and produce
      garbage that is in one way or another insufficient for crypto.
    
    - Suggesting a *reduction* in paranoia, as this commit effectively does,
      may cause some to question my personal integrity as a "security
      person".
    
    - Bootloader seeds and RDRAND are generally very difficult if not all
      together impossible to audit.
    
    Keep in mind that this doesn't actually change any behavior. This
    is just a change in the default Kconfig value. The distros already are
    shipping kernels that set things this way.
    
    Ard made an additional argument in [1]:
    
        We're at the mercy of firmware and micro-architecture anyway, given
        that we are also relying on it to ensure that every instruction in
        the kernel's executable image has been faithfully copied to memory,
        and that the CPU implements those instructions as documented. So I
        don't think firmware or ISA bugs related to RNGs deserve special
        treatment - if they are broken, we should quirk around them like we
        usually do. So enabling these by default is a step in the right
        direction IMHO.
    
    In [2], Phil pointed out that having this disabled masked a bug that CI
    otherwise would have caught:
    
        A clean 5.15.45 boots cleanly, whereas a downstream kernel shows the
        static key warning (but it does go on to boot). The significant
        difference is that our defconfigs set CONFIG_RANDOM_TRUST_BOOTLOADER=y
        defining that on top of multi_v7_defconfig demonstrates the issue on
        a clean 5.15.45. Conversely, not setting that option in a
        downstream kernel build avoids the warning
    
    [1] https://lore.kernel.org/lkml/CAMj1kXGi+ieviFjXv9zQBSaGyyzeGW_VpMpTLJK8PJb2QHEQ-w@mail.gmail.com/
    [2] https://lore.kernel.org/lkml/c47c42e3-1d56-5859-a6ad-976a1a3381c6@raspberrypi.com/
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "drm/amd/display: Fix DCN3 B0 DP Alt Mapping" [+ + +]
Author: Stylon Wang <stylon.wang@amd.com>
Date:   Wed May 4 18:09:44 2022 +0800

    Revert "drm/amd/display: Fix DCN3 B0 DP Alt Mapping"
    
    commit 1039188806d4cfdf9c412bb4ddb51b4d8cd15478 upstream.
    
    This reverts commit 4b7786d87fb3adf3e534c4f1e4f824d8700b786b.
    
    Commit 4b7786d87fb3 ("drm/amd/display: Fix DCN3 B0 DP Alt Mapping")
    is causing 2nd USB-C display not lighting up.
    Phy id remapping is done differently than is assumed in this
    patch.
    
    Signed-off-by: Stylon Wang <stylon.wang@amd.com>
    Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
riscv: dts: microchip: re-add pdma to mpfs device tree [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Fri Jun 3 09:38:26 2022 +0100

    riscv: dts: microchip: re-add pdma to mpfs device tree
    
    [ Upstream commit 5e757deddd918edb8cb2fdb56eb79656ffc6dade ]
    
    PolarFire SoC /does/ have a SiFive pdma, despite what I suggested as a
    conflict resolution to Zong. Somehow the entry fell through the cracks
    between versions of my dt patches, so re-add it with Zong's updated
    compatible & dma-channels property.
    
    Fixes: c5094f371008 ("riscv: dts: microchip: refactor icicle kit device tree")
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched: Fix balance_push() vs __sched_setscheduler() [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jun 7 22:41:55 2022 +0200

    sched: Fix balance_push() vs __sched_setscheduler()
    
    [ Upstream commit 04193d590b390ec7a0592630f46d559ec6564ba1 ]
    
    The purpose of balance_push() is to act as a filter on task selection
    in the case of CPU hotplug, specifically when taking the CPU out.
    
    It does this by (ab)using the balance callback infrastructure, with
    the express purpose of keeping all the unlikely/odd cases in a single
    place.
    
    In order to serve its purpose, the balance_push_callback needs to be
    (exclusively) on the callback list at all times (noting that the
    callback always places itself back on the list the moment it runs,
    also noting that when the CPU goes down, regular balancing concerns
    are moot, so ignoring them is fine).
    
    And here-in lies the problem, __sched_setscheduler()'s use of
    splice_balance_callbacks() takes the callbacks off the list across a
    lock-break, making it possible for, an interleaving, __schedule() to
    see an empty list and not get filtered.
    
    Fixes: ae7927023243 ("sched: Optimize finish_lock_switch()")
    Reported-by: Jing-Ting Wu <jing-ting.wu@mediatek.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Jing-Ting Wu <jing-ting.wu@mediatek.com>
    Link: https://lkml.kernel.org/r/20220519134706.GH2578@worktop.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: ipr: Fix missing/incorrect resource cleanup in error case [+ + +]
Author: Chengguang Xu <cgxu519@mykernel.net>
Date:   Sun May 29 23:34:53 2022 +0800

    scsi: ipr: Fix missing/incorrect resource cleanup in error case
    
    [ Upstream commit d64c491911322af1dcada98e5b9ee0d87e8c8fee ]
    
    Fix missing resource cleanup (when '(--i) == 0') for error case in
    ipr_alloc_mem() and skip incorrect resource cleanup (when '(--i) == 0') for
    error case in ipr_request_other_msi_irqs() because variable i started from
    1.
    
    Link: https://lore.kernel.org/r/20220529153456.4183738-4-cgxu519@mykernel.net
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Allow reduced polling rate for nvme_admin_async_event cmd completion [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:28 2022 -0700

    scsi: lpfc: Allow reduced polling rate for nvme_admin_async_event cmd completion
    
    [ Upstream commit 2e7e9c0c1ec05f18d320ecc8a31eec59d2af1af9 ]
    
    NVMe Asynchronous Event Request commands have no command timeout value per
    specifications.
    
    Set WQE option to allow a reduced FLUSH polling rate for I/O error
    detection specifically for nvme_admin_async_event commands.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-9-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Fix port stuck in bypassed state after LIP in PT2PT topology [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:26 2022 -0700

    scsi: lpfc: Fix port stuck in bypassed state after LIP in PT2PT topology
    
    [ Upstream commit 336d63615466b4c06b9401c987813fd19bdde39b ]
    
    After issuing a LIP, a specific target vendor does not ACC the FLOGI that
    lpfc sends.  However, it does send its own FLOGI that lpfc ACCs.  The
    target then establishes the port IDs by sending a PLOGI.  lpfc PLOGI_ACCs
    and starts the RPI registration for DID 0x000001.  The target then sends a
    LOGO to the fabric DID.  lpfc is currently treating the LOGO from the
    fabric DID as a link down and cleans up all the ndlps.  The ndlp for DID
    0x000001 is put back into NPR and discovery stops, leaving the port in
    stuck in bypassed mode.
    
    Change lpfc behavior such that if a LOGO is received for the fabric DID in
    PT2PT topology skip the lpfc_linkdown_port() routine and just move the
    fabric DID back to NPR.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-7-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is aborted [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:25 2022 -0700

    scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is aborted
    
    [ Upstream commit b1b3440f437b75fb2a9b0cfe58df461e40eca474 ]
    
    A use-after-free crash can occur after an ELS LOGO is aborted.
    
    Specifically, a nodelist structure is freed and then
    ndlp->vport->cfg_log_verbose is dereferenced in lpfc_nlp_get() when the
    discovery state machine is mistakenly called a second time with
    NLP_EVT_DEVICE_RM argument.
    
    Rework lpfc_cmpl_els_logo() to prevent the duplicate calls to release a
    nodelist structure.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-6-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpt3sas: Fix out-of-bounds compiler warning [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Tue May 31 22:09:27 2022 +0200

    scsi: mpt3sas: Fix out-of-bounds compiler warning
    
    [ Upstream commit 120f1d95efb1cdb6fe023c84e38ba06d8f78cd03 ]
    
    I'm facing this warning when building for the parisc64 architecture:
    
    drivers/scsi/mpt3sas/mpt3sas_base.c: In function ‘_base_make_ioc_operational’:
    drivers/scsi/mpt3sas/mpt3sas_base.c:5396:40: warning: array subscript ‘Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds]
     5396 |             (le16_to_cpu(sas_iounit_pg1->SASWideMaxQueueDepth)) ?
    drivers/scsi/mpt3sas/mpt3sas_base.c:5382:26: note: referencing an object of size 20 allocated by ‘kzalloc’
     5382 |         sas_iounit_pg1 = kzalloc(sz, GFP_KERNEL);
          |                          ^~~~~~~~~~~~~~~~~~~~~~~
    
    The problem is, that only 20 bytes are allocated with kmalloc(), which is
    sufficient to hold the bytes which are needed.  Nevertheless, gcc complains
    because the whole Mpi2SasIOUnitPage1_t struct is 32 bytes in size and thus
    doesn't fit into those 20 bytes.
    
    This patch simply allocates all 32 bytes (instead of 20) and thus avoids
    the warning. There is no functional change introduced by this patch.
    
    While touching the code I cleaned up to calculation of max_wideport_qd,
    max_narrowport_qd and max_sata_qd to make it easier readable.
    
    Test successfully tested on a HP C8000 PA-RISC workstation with 64-bit
    kernel.
    
    Link: https://lore.kernel.org/r/YpZ197iZdDZSCzrT@p100
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: pmcraid: Fix missing resource cleanup in error case [+ + +]
Author: Chengguang Xu <cgxu519@mykernel.net>
Date:   Sun May 29 23:34:55 2022 +0800

    scsi: pmcraid: Fix missing resource cleanup in error case
    
    [ Upstream commit ec1e8adcbdf661c57c395bca342945f4f815add7 ]
    
    Fix missing resource cleanup (when '(--i) == 0') for error case in
    pmcraid_register_interrupt_handler().
    
    Link: https://lore.kernel.org/r/20220529153456.4183738-6-cgxu519@mykernel.net
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: vmw_pvscsi: Expand vcpuHint to 16 bits [+ + +]
Author: Wentao Wang <wwentao@vmware.com>
Date:   Thu Jun 2 08:57:00 2022 +0000

    scsi: vmw_pvscsi: Expand vcpuHint to 16 bits
    
    [ Upstream commit cf71d59c2eceadfcde0fb52e237990a0909880d7 ]
    
    vcpuHint has been expanded to 16 bit on host to enable routing to more
    CPUs. Guest side should align with the change. This change has been tested
    with hosts with 8-bit and 16-bit vcpuHint, on both platforms host side can
    get correct value.
    
    Link: https://lore.kernel.org/r/EF35F4D5-5DCC-42C5-BCC4-29DF1729B24C@vmware.com
    Signed-off-by: Wentao Wang <wwentao@vmware.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selinux: free contexts previously transferred in selinux_add_opt() [+ + +]
Author: Christian Göttsche <cgzones@googlemail.com>
Date:   Wed Jun 15 17:38:39 2022 +0200

    selinux: free contexts previously transferred in selinux_add_opt()
    
    commit cad140d00899e7a9cb6fe93b282051df589e671c upstream.
    
    `selinux_add_opt()` stopped taking ownership of the passed context since
    commit 70f4169ab421 ("selinux: parse contexts for mount options early").
    
        unreferenced object 0xffff888114dfd140 (size 64):
          comm "mount", pid 15182, jiffies 4295687028 (age 796.340s)
          hex dump (first 32 bytes):
            73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f  system_u:object_
            72 3a 74 65 73 74 5f 66 69 6c 65 73 79 73 74 65  r:test_filesyste
          backtrace:
            [<ffffffffa07dbef4>] kmemdup_nul+0x24/0x80
            [<ffffffffa0d34253>] selinux_sb_eat_lsm_opts+0x293/0x560
            [<ffffffffa0d13f08>] security_sb_eat_lsm_opts+0x58/0x80
            [<ffffffffa0af1eb2>] generic_parse_monolithic+0x82/0x180
            [<ffffffffa0a9c1a5>] do_new_mount+0x1f5/0x550
            [<ffffffffa0a9eccb>] path_mount+0x2ab/0x1570
            [<ffffffffa0aa019e>] __x64_sys_mount+0x20e/0x280
            [<ffffffffa1f47124>] do_syscall_64+0x34/0x80
            [<ffffffffa200007e>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
        unreferenced object 0xffff888108e71640 (size 64):
          comm "fsmount", pid 7607, jiffies 4295044974 (age 1601.016s)
          hex dump (first 32 bytes):
            73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f  system_u:object_
            72 3a 74 65 73 74 5f 66 69 6c 65 73 79 73 74 65  r:test_filesyste
          backtrace:
            [<ffffffff861dc2b1>] memdup_user+0x21/0x90
            [<ffffffff861dc367>] strndup_user+0x47/0xa0
            [<ffffffff864f6965>] __do_sys_fsconfig+0x485/0x9f0
            [<ffffffff87940124>] do_syscall_64+0x34/0x80
            [<ffffffff87a0007e>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Cc: stable@vger.kernel.org
    Fixes: 70f4169ab421 ("selinux: parse contexts for mount options early")
    Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: 8250: Store to lsr_save_flags after lsr read [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri May 20 13:35:41 2022 +0300

    serial: 8250: Store to lsr_save_flags after lsr read
    
    commit be03b0651ffd8bab69dfd574c6818b446c0753ce upstream.
    
    Not all LSR register flags are preserved across reads. Therefore, LSR
    readers must store the non-preserved bits into lsr_save_flags.
    
    This fix was initially mixed into feature commit f6f586102add ("serial:
    8250: Handle UART without interrupt on TEMT using em485"). However,
    that feature change had a flaw and it was reverted to make room for
    simpler approach providing the same feature. The embedded fix got
    reverted with the feature change.
    
    Re-add the lsr_save_flags fix and properly mark it's a fix.
    
    Link: https://lore.kernel.org/all/1d6c31d-d194-9e6a-ddf9-5f29af829f3@linux.intel.com/T/#m1737eef986bd20cf19593e344cebd7b0244945fc
    Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
    Cc: stable <stable@kernel.org>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@penugtronix.de>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/f4d774be-1437-a550-8334-19d8722ab98c@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
staging: r8188eu: fix rtw_alloc_hwxmits error detection for now [+ + +]
Author: Phillip Potter <phil@philpotter.co.uk>
Date:   Sat May 21 21:47:41 2022 +0100

    staging: r8188eu: fix rtw_alloc_hwxmits error detection for now
    
    [ Upstream commit 5b7419ae1d208cab1e2826d473d8dab045aa75c7 ]
    
    In _rtw_init_xmit_priv, we use the res variable to store the error
    return from the newly converted rtw_alloc_hwxmits function. Sadly, the
    calling function interprets res using _SUCCESS and _FAIL still, meaning
    we change the semantics of the variable, even in the success case.
    
    This leads to the following on boot:
    r8188eu 1-2:1.0: _rtw_init_xmit_priv failed
    
    In the long term, we should reverse these semantics, but for now, this
    fixes the driver. Also, inside rtw_alloc_hwxmits remove the if blocks,
    as HWXMIT_ENTRY is always 4.
    
    Fixes: f94b47c6bde6 ("staging: r8188eu: add check for kzalloc")
    Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
    Link: https://lore.kernel.org/r/20220521204741.921-1-phil@philpotter.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

staging: r8188eu: Fix warning of array overflow in ioctl_linux.c [+ + +]
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon May 30 20:31:03 2022 -0500

    staging: r8188eu: Fix warning of array overflow in ioctl_linux.c
    
    [ Upstream commit 96f0a54e8e65a765b3a4ad4b53751581f23279f3 ]
    
    Building with -Warray-bounds results in the following warning plus others
    related to the same problem:
    
    CC [M]  drivers/staging/r8188eu/os_dep/ioctl_linux.o
    In function ‘wpa_set_encryption’,
        inlined from ‘rtw_wx_set_enc_ext’ at drivers/staging/r8188eu/os_dep/ioctl_linux.c:1868:9:
    drivers/staging/r8188eu/os_dep/ioctl_linux.c:412:41: warning: array subscript ‘struct ndis_802_11_wep[0]’ is partly outside array bounds of ‘void[25]’ [-Warray-bounds]
      412 |                         pwep->KeyLength = wep_key_len;
          |                         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
    In file included from drivers/staging/r8188eu/os_dep/../include/osdep_service.h:19,
                     from drivers/staging/r8188eu/os_dep/ioctl_linux.c:4:
    In function ‘kmalloc’,
        inlined from ‘kzalloc’ at ./include/linux/slab.h:733:9,
        inlined from ‘wpa_set_encryption’ at drivers/staging/r8188eu/os_dep/ioctl_linux.c:408:11,
        inlined from ‘rtw_wx_set_enc_ext’ at drivers/staging/r8188eu/os_dep/ioctl_linux.c:1868:9:
    ./include/linux/slab.h:605:16: note: object of size [17, 25] allocated by ‘__kmalloc’
      605 |         return __kmalloc(size, flags);
          |                ^~~~~~~~~~~~~~~~~~~~~~
    ./include/linux/slab.h:600:24: note: object of size [17, 25] allocated by ‘kmem_cache_alloc_trace’
      600 |                 return kmem_cache_alloc_trace(
          |                        ^~~~~~~~~~~~~~~~~~~~~~~
      601 |                                 kmalloc_caches[kmalloc_type(flags)][index],
          |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      602 |                                 flags, size);
          |                                 ~~~~~~~~~~~~
    
    Although it is unlikely that anyone is still using WEP encryption, the
    size of the allocation needs to be increased just in case.
    
    Fixes commit 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver")
    
    Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Phillip Potter <phil@philpotter.co.uk>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20220531013103.2175-3-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sunrpc: set cl_max_connect when cloning an rpc_clnt [+ + +]
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Wed Jun 1 13:34:49 2022 -0400

    sunrpc: set cl_max_connect when cloning an rpc_clnt
    
    [ Upstream commit 304791255a2dc1c9be7e7c8a6cbdb31b6847b0e5 ]
    
    If the initial attempt at trunking detection using the krb5i auth flavor
    fails with -EACCES, -NFS4ERR_CLID_INUSE, or -NFS4ERR_WRONGSEC, then the
    NFS client tries again using auth_sys, cloning the rpc_clnt in the
    process.  If this second attempt at trunking detection succeeds, then
    the resulting nfs_client->cl_rpcclient winds up having cl_max_connect=0
    and subsequent attempts to add additional transport connections to the
    rpc_clnt will fail with a message similar to the following being logged:
    
    [502044.312640] SUNRPC: reached max allowed number (0) did not add
    transport to server: 192.168.122.3
    
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Fixes: dc48e0abee24 ("SUNRPC enforce creation of no more than max_connect xprts")
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: goldfish: Fix free_irq() on remove [+ + +]
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Thu Jun 9 16:17:04 2022 +0200

    tty: goldfish: Fix free_irq() on remove
    
    [ Upstream commit 499e13aac6c762e1e828172b0f0f5275651d6512 ]
    
    Pass the correct dev_id to free_irq() to fix this splat when the driver
    is unbound:
    
     WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq
     Trying to free already-free IRQ 65
     Call Trace:
      warn_slowpath_fmt
      free_irq
      goldfish_tty_remove
      platform_remove
      device_remove
      device_release_driver_internal
      device_driver_detach
      unbind_store
      drv_attr_store
      ...
    
    Fixes: 465893e18878e119 ("tty: goldfish: support platform_device with id -1")
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Link: https://lore.kernel.org/r/20220609141704.1080024-1-vincent.whitchurch@axis.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: n_gsm: Debug output allocation must use GFP_ATOMIC [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon May 23 18:50:52 2022 +0300

    tty: n_gsm: Debug output allocation must use GFP_ATOMIC
    
    commit e74024b2eccbb784824a0f9feaeaaa3b47514b79 upstream.
    
    Dan Carpenter <dan.carpenter@oracle.com> reported the following Smatch
    warning:
    
    drivers/tty/n_gsm.c:720 gsm_data_kick()
    warn: sleeping in atomic context
    
    This is because gsm_control_message() is holding a spin lock so
    gsm_hex_dump_bytes() needs to use GFP_ATOMIC instead of GFP_KERNEL.
    
    Fixes: 925ea0fa5277 ("tty: n_gsm: Fix packet data hex dump output")
    Cc: stable <stable@kernel.org>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220523155052.57129-1-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: cdnsp: Fixed setting last_trb incorrectly [+ + +]
Author: Jing Leng <jleng@ambarella.com>
Date:   Thu Jun 9 10:11:34 2022 +0800

    usb: cdnsp: Fixed setting last_trb incorrectly
    
    commit 5c7578c39c3fffe85b7d15ca1cf8cf7ac38ec0c1 upstream.
    
    When ZLP occurs in bulk transmission, currently cdnsp will set last_trb
    for the last two TRBs, it will trigger an error "ERROR Transfer event TRB
    DMA ptr not part of current TD ...".
    
    Fixes: e913aada0683 ("usb: cdnsp: Fixed issue with ZLP")
    Cc: stable <stable@kernel.org>
    Acked-by: Pawel Laszczak <pawell@cadence.com>
    Signed-off-by: Jing Leng <jleng@ambarella.com>
    Link: https://lore.kernel.org/r/20220609021134.1606-1-3090101217@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: Fix memory leak in dwc2_hcd_init [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 30 12:54:12 2022 +0400

    usb: dwc2: Fix memory leak in dwc2_hcd_init
    
    commit 3755278f078460b021cd0384562977bf2039a57a upstream.
    
    usb_create_hcd will alloc memory for hcd, and we should
    call usb_put_hcd to free it when platform_get_resource()
    fails to prevent memory leak.
    goto error2 label instead error1 to fix this.
    
    Fixes: 856e6e8e0f93 ("usb: dwc2: check return value after calling platform_get_resource()")
    Cc: stable <stable@kernel.org>
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220530085413.44068-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: Fix IN endpoint max packet size allocation [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Mon May 23 14:39:48 2022 -0700

    usb: dwc3: gadget: Fix IN endpoint max packet size allocation
    
    commit 9c1e916960c1192e746bf615e4dae25423473a64 upstream.
    
    The current logic to assign the max packet limit for IN endpoints attempts
    to take the default HW value and apply the optimal endpoint settings based
    on it.  However, if the default value reports a TxFIFO size large enough
    for only one max packet, it will divide the value and assign a smaller ep
    max packet limit.
    
    For example, if the default TxFIFO size fits 1024B, current logic will
    assign 1024/3 = 341B to ep max packet size.  If function drivers attempt to
    request for an endpoint with a wMaxPacketSize of 1024B (SS BULK max packet
    size) then it will fail, as the gadget is unable to find an endpoint which
    can fit the requested size.
    
    Functionally, if the TxFIFO has enough space to fit one max packet, it will
    be sufficient, at least when initializing the endpoints.
    
    Fixes: d94ea5319813 ("usb: dwc3: gadget: Properly set maxpacket limit")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220523213948.22142-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: pci: Restore line lost in merge conflict resolution [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Sat May 28 19:09:13 2022 +0200

    usb: dwc3: pci: Restore line lost in merge conflict resolution
    
    commit 7ddda2614d62ef7fdef7fd85f5151cdf665b22d8 upstream.
    
    Commit 582ab24e096f ("usb: dwc3: pci: Set "linux,phy_charger_detect"
    property on some Bay Trail boards") added a new swnode similar to the
    existing ones for boards where the PHY handles charger detection.
    
    Unfortunately, the "linux,sysdev_is_parent" property got lost in the
    merge conflict resolution of commit ca9400ef7f67 ("Merge 5.17-rc6 into
    usb-next"). Now dwc3_pci_intel_phy_charger_detect_properties is the
    only swnode in dwc3-pci that is missing "linux,sysdev_is_parent".
    
    It does not seem to cause any obvious functional issues, but it's
    certainly unintended so restore the line to make the properties
    consistent again.
    
    Fixes: ca9400ef7f67 ("Merge 5.17-rc6 into usb-next")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20220528170913.9240-1-stephan@gerhold.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_fs: change ep->ep safe in ffs_epfile_io() [+ + +]
Author: Linyu Yuan <quic_linyyuan@quicinc.com>
Date:   Fri Jun 10 20:17:58 2022 +0800

    usb: gadget: f_fs: change ep->ep safe in ffs_epfile_io()
    
    commit 0698f0209d8032e8869525aeb68f65ee7fde12ad upstream.
    
    In ffs_epfile_io(), when read/write data in blocking mode, it will wait
    the completion in interruptible mode, if task receive a signal, it will
    terminate the wait, at same time, if function unbind occurs,
    ffs_func_unbind() will kfree all eps, ffs_epfile_io() still try to
    dequeue request by dereferencing ep which may become invalid.
    
    Fix it by add ep spinlock and will not dereference ep if it is not valid.
    
    Cc: <stable@vger.kernel.org> # 5.15
    Reported-by: Michael Wu <michael@allwinnertech.com>
    Tested-by: Michael Wu <michael@allwinnertech.com>
    Reviewed-by: John Keeping <john@metanate.com>
    Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
    Link: https://lore.kernel.org/r/1654863478-26228-3-git-send-email-quic_linyyuan@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_fs: change ep->status safe in ffs_epfile_io() [+ + +]
Author: Linyu Yuan <quic_linyyuan@quicinc.com>
Date:   Fri Jun 10 20:17:57 2022 +0800

    usb: gadget: f_fs: change ep->status safe in ffs_epfile_io()
    
    commit fb1f16d74e263baa4ad11e31e28b68f144aa55ed upstream.
    
    If a task read/write data in blocking mode, it will wait the completion
    in ffs_epfile_io(), if function unbind occurs, ffs_func_unbind() will
    kfree ffs ep, once the task wake up, it still dereference the ffs ep to
    obtain the request status.
    
    Fix it by moving the request status to io_data which is stack-safe.
    
    Cc: <stable@vger.kernel.org> # 5.15
    Reported-by: Michael Wu <michael@allwinnertech.com>
    Tested-by: Michael Wu <michael@allwinnertech.com>
    Reviewed-by: John Keeping <john@metanate.com>
    Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
    Link: https://lore.kernel.org/r/1654863478-26228-2-git-send-email-quic_linyyuan@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 18:02:44 2022 +0400

    usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe
    
    commit 4757c9ade34178b351580133771f510b5ffcf9c8 upstream.
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    of_node_put() will check NULL pointer.
    
    Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220603140246.64529-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: u_ether: fix regression in setting fixed MAC address [+ + +]
Author: Marian Postevca <posteuca@mutex.one>
Date:   Fri Jun 3 18:34:59 2022 +0300

    usb: gadget: u_ether: fix regression in setting fixed MAC address
    
    commit b337af3a4d6147000b7ca6b3438bf5c820849b37 upstream.
    
    In systemd systems setting a fixed MAC address through
    the "dev_addr" module argument fails systematically.
    When checking the MAC address after the interface is created
    it always has the same but different MAC address to the one
    supplied as argument.
    
    This is partially caused by systemd which by default will
    set an internally generated permanent MAC address for interfaces
    that are marked as having a randomly generated address.
    
    Commit 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in
    setting MAC address in setup phase") didn't take into account
    the fact that the interface must be marked as having a set
    MAC address when it's set as module argument.
    
    Fixed by marking the interface with NET_ADDR_SET when
    the "dev_addr" module argument is supplied.
    
    Fixes: 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase")
    Cc: stable@vger.kernel.org
    Signed-off-by: Marian Postevca <posteuca@mutex.one>
    Link: https://lore.kernel.org/r/20220603153459.32722-1-posteuca@mutex.one
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: io_ti: add Agilent E5805A support [+ + +]
Author: Robert Eckelmann <longnoserob@gmail.com>
Date:   Sat May 21 23:08:08 2022 +0900

    USB: serial: io_ti: add Agilent E5805A support
    
    commit 908e698f2149c3d6a67d9ae15c75545a3f392559 upstream.
    
    Add support for Agilent E5805A (rebranded ION Edgeport/4) to io_ti.
    
    Signed-off-by: Robert Eckelmann <longnoserob@gmail.com>
    Link: https://lore.kernel.org/r/20220521230808.30931eca@octoberrain
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add support for Cinterion MV31 with new baseline [+ + +]
Author: Slark Xiao <slark_xiao@163.com>
Date:   Wed Jun 1 11:47:40 2022 +0800

    USB: serial: option: add support for Cinterion MV31 with new baseline
    
    commit 158f7585bfcea4aae0ad4128d032a80fec550df1 upstream.
    
    Adding support for Cinterion device MV31 with Qualcomm
    new baseline. Use different PIDs to separate it from
    previous base line products.
    All interfaces settings keep same as previous.
    
    Below is test evidence:
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b8 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B8 USB Mobile Broadband
    S:  SerialNumber=90418e79
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b9 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B9 USB Mobile Broadband
    S:  SerialNumber=90418e79
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    For PID 00b8, interface 3 is GNSS port which don't use serial driver.
    
    Signed-off-by: Slark Xiao <slark_xiao@163.com>
    Link: https://lore.kernel.org/r/20220601034740.5438-1-slark_xiao@163.com
    [ johan: rename defines using a "2" infix ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
virtio-mmio: fix missing put_device() when vm_cmdline_parent registration failed [+ + +]
Author: chengkaitao <pilgrimtao@gmail.com>
Date:   Thu Jun 2 08:55:42 2022 +0800

    virtio-mmio: fix missing put_device() when vm_cmdline_parent registration failed
    
    [ Upstream commit a58a7f97ba11391d2d0d408e0b24f38d86ae748e ]
    
    The reference must be released when device_register(&vm_cmdline_parent)
    failed. Add the corresponding 'put_device()' in the error handling path.
    
    Signed-off-by: chengkaitao <pilgrimtao@gmail.com>
    Message-Id: <20220602005542.16489-1-chengkaitao@didiglobal.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>

 
virtio-pci: Remove wrong address verification in vp_del_vqs() [+ + +]
Author: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Date:   Thu Apr 14 23:30:02 2022 -0300

    virtio-pci: Remove wrong address verification in vp_del_vqs()
    
    commit 7e415282b41bf0d15c6e0fe268f822d9b083f2f7 upstream.
    
    GCC 12 enhanced -Waddress when comparing array address to null [0],
    which warns:
    
        drivers/virtio/virtio_pci_common.c: In function ‘vp_del_vqs’:
        drivers/virtio/virtio_pci_common.c:257:29: warning: the comparison will always evaluate as ‘true’ for the pointer operand in ‘vp_dev->msix_affinity_masks + (sizetype)((long unsigned int)i * 256)’ must not be NULL [-Waddress]
          257 |                         if (vp_dev->msix_affinity_masks[i])
              |                             ^~~~~~
    
    In fact, the verification is comparing the result of a pointer
    arithmetic, the address "msix_affinity_masks + i", which will always
    evaluate to true.
    
    Under the hood, free_cpumask_var() calls kfree(), which is safe to pass
    NULL, not requiring non-null verification.  So remove the verification
    to make compiler happy (happy compiler, happy life).
    
    [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103
    
    Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
    Message-Id: <20220415023002.49805-1-muriloo@linux.ibm.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Christophe de Dinechin <dinechin@redhat.com>
    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/ftrace: Remove OBJECT_FILES_NON_STANDARD usage [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Fri Jun 3 08:04:44 2022 -0700

    x86/ftrace: Remove OBJECT_FILES_NON_STANDARD usage
    
    [ Upstream commit 7b6c7a877cc616bc7dc9cd39646fe454acbed48b ]
    
    The file-wide OBJECT_FILES_NON_STANDARD annotation is used with
    CONFIG_FRAME_POINTER to tell objtool to skip the entire file when frame
    pointers are enabled.  However that annotation is now deprecated because
    it doesn't work with IBT, where objtool runs on vmlinux.o instead of
    individual translation units.
    
    Instead, use more fine-grained function-specific annotations:
    
    - The 'save_mcount_regs' macro does funny things with the frame pointer.
      Use STACK_FRAME_NON_STANDARD_FP to tell objtool to ignore the
      functions using it.
    
    - The return_to_handler() "function" isn't actually a callable function.
      Instead of being called, it's returned to.  The real return address
      isn't on the stack, so unwinding is already doomed no matter which
      unwinder is used.  So just remove the STT_FUNC annotation, telling
      objtool to ignore it.  That also removes the implicit
      ANNOTATE_NOENDBR, which now needs to be made explicit.
    
    Fixes the following warning:
    
      vmlinux.o: warning: objtool: __fentry__+0x16: return with modified stack frame
    
    Fixes: ed53a0d97192 ("x86/alternative: Use .ibt_endbr_seal to seal indirect calls")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Link: https://lore.kernel.org/r/b7a7a42fe306aca37826043dac89e113a1acdbac.1654268610.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>